Présentation des certificats SSL

SSL/TLS est le protocole cryptographique le plus utilisé sur Internet. Techniquement, TLS est le successeur de SSL, bien que les termes soient parfois utilisés de manière interchangeable, comme dans ce document.

Le protocole TLS (Transport Layer Security) permet de chiffrer les informations lors de leur envoi sur un réseau afin de garantir la confidentialité entre un client et un serveur ou un équilibreur de charge. Un équilibreur de charge d'application ou un équilibreur de charge réseau proxy qui utilise SSL nécessite au moins une clé privée et un certificat SSL.

Méthode de configuration du certificat

Pour les équilibreurs de charge d'application utilisant des proxys HTTPS cibles, le proxy cible de l'équilibreur de charge doit faire référence à un à 15 certificats SSL Compute Engine. Chaque ressource de certificat SSL Compute Engine contient la clé privée, le certificat correspondant et, éventuellement, les certificats CA.

Compatibilité avec les équilibreurs de charge

Le tableau suivant indique les méthodes de configuration des certificats compatibles avec chaque équilibreur de charge.

Types de certificat

Vous pouvez créer des certificats SSL autogérés pour vos équilibreurs de charge.

Certificats SSL autogérés

Les certificats SSL autogérés sont des certificats que vous obtenez, provisionnez et renouvelez vous-même. Les certificats autogérés peuvent appartenir à l'un des types de certificat de clé publique suivants :

• Validation de domaine (DV)
• Validation de l'organisation (OV)
• Validation étendue (EV)

Vous pouvez créer des certificats SSL autogérés à l'aide des ressources de certificat SSL Compute Engine. Pour en savoir plus, consultez Utiliser des certificats SSL autogérés.

Types de clés acceptés

Les types de clés suivants sont compatibles avec les certificats SSL Compute Engine régionaux autogérés :

• RSA-2048
• RSA-3072
• RSA-4096
• ECDSA P-256
• ECDSA P-384

Utiliser des certificats avec des clés ECDSA

Cette section explique pourquoi nous recommandons ECDSA plutôt que RSA comme bonne pratique pour les clés de signature de certificat.

Quel type de clé utiliser ?

ECDSA P-256 est le type de clé recommandé pour la plupart des certificats TLS. Il offre une sécurité cryptographique élevée, d'excellentes performances pour les opérations de signature et une utilisation efficace de la bande passante du réseau.

Voici quelques raisons possibles d'utiliser d'autres types de clés de certificat :

• Si vous devez prendre en charge d'anciens clients qui ne sont pas compatibles avec les certificats ECDSA, vous pouvez fournir des certificats RSA-2048 en plus des certificats ECDSA P-256.
• Si vous avez des exigences de conformité spécifiques qui vous obligent à utiliser des tailles de clé plus importantes ou des types de clé particuliers, vous pouvez utiliser les clés ECDSA P-384, RSA-2048, RSA-3072 et RSA-4096.

Pourquoi choisir ECDSA plutôt que RSA ?

Le principal avantage d'ECDSA réside dans sa capacité à fournir un niveau de sécurité cryptographique équivalent avec des clés beaucoup plus petites que celles de RSA. Cette efficacité se traduit par des avantages concrets en termes de performances et de ressources. Une clé plus petite n'implique pas une sécurité plus faible. ECDSA est basé sur le problème du logarithme discret de la courbe elliptique, qui offre une sécurité plus forte par unité de clé et, dans certains cas, une meilleure efficacité de calcul par rapport à RSA.

Exemple :

• Une clé ECDSA de 256 bits offre un niveau de sécurité similaire à celui d'une clé RSA-3072.
• Une clé ECDSA 384 bits offre un niveau de sécurité supérieur à celui de n'importe quelle taille de clé RSA largement acceptée.

Principaux avantages d'ECDSA :

• Performances : les opérations de signature ECDSA sont beaucoup moins gourmandes en ressources de calcul que les opérations RSA pour un niveau de sécurité équivalent. Cela réduit la charge du processeur et la latence, ce qui est essentiel pour les systèmes à haut débit ou sensibles à la latence.

• Efficacité : les clés et les signatures plus petites nécessitent moins de bande passante et de stockage, ce qui est particulièrement utile pour les environnements aux ressources limitées, comme les appareils mobiles et IoT.

Plusieurs certificats SSL

Le proxy cible d'un équilibreur de charge d'application peut faire référence à un maximum de 15 certificats SSL Compute Engine. La première ressource de certificat SSL Compute Engine référencée est le certificat par défaut (principal) du proxy cible.

Pour en savoir plus, consultez les sections Proxys cibles et Certificats SSL dans la documentation sur l'équilibrage de charge.

Processus de sélection des certificats

La procédure de sélection de certificat suivante s'applique aux équilibreurs de charge dont les proxys cibles font référence à plusieurs certificats SSL Compute Engine.

Une fois qu'un client se connecte à l'équilibreur de charge, le client et l'équilibreur de charge négocient une session TLS. Lors de la négociation de la session TLS, le client envoie à l'équilibreur de charge une liste d'algorithmes de chiffrement TLS compatibles (dans ClientHello). L'équilibreur de charge sélectionne un certificat dont l'algorithme de clé publique est compatible avec le client. Le client peut également envoyer un nom d'hôte d'indication de nom de serveur (SNI) à l'équilibreur de charge lors de cette négociation. Les données de nom d'hôte SNI sont parfois utilisées pour aider l'équilibreur de charge à choisir le certificat qu'il doit envoyer au client.

• Si le proxy cible de l'équilibreur de charge ne fait référence qu'à un seul certificat, ce certificat est utilisé et la valeur du nom d'hôte SNI envoyé par le client n'est pas pertinente.

• Si le proxy cible de l'équilibreur de charge fait référence à plusieurs certificats, l'équilibreur de charge utilise le processus suivant pour sélectionner un seul certificat :

  • Si le client n'a envoyé aucun nom d'hôte SNI dans son ClientHello, l'équilibreur de charge utilise le premier certificat de sa liste de certificats.

  • Si le client envoie un nom d'hôte SNI qui ne correspond à aucun nom commun de certificat (CN) et ne correspond à aucun autre nom d'objet de certificat (SAN), l'équilibreur de charge utilise le premier certificat de sa liste de certificats.

  • Dans toutes les autres situations : l'équilibreur de charge sélectionne un certificat à l'aide du processus de correspondance suivant :

    • La correspondance se fait par suffixe le plus long par rapport aux attributs de certificat du nom commun (CN) et de l'autre nom de l'objet (SAN), avec une préférence pour les certificats ECDSA par rapport aux certificats RSA.

    • Pour illustrer la méthode de mise en correspondance, considérons un proxy cible qui référence les deux certificats suivants :

      • Certificat A

        • CN : cats.pets.example.com
        • SAN : cats.pets.example.com, *.pets.example.com, *.example.com

      • Certificat B

        • CN : dogs.pets.example.com
        • SAN : dogs.pets.example.com, *.pets.example.com, *.example.com

    • Prenons les exemples suivants :

      • Si le nom d'hôte SNI envoyé par le client est cats.pets.example.com, l'équilibreur de charge utilise le certificat A.
      • Si le nom d'hôte SNI envoyé par le client est ferrets.pets.example.com, il n'y a pas de correspondance exacte. L'équilibreur de charge sélectionne donc le certificat A ou le certificat B, car les deux incluent *.pets.example.com dans leur liste de SAN. Vous ne pouvez pas contrôler le certificat sélectionné dans cette situation.

• Une fois le certificat sélectionné, l'équilibreur de charge l'envoie au client uniquement si le certificat sélectionné utilise un algorithme de clé publique compatible avec un algorithme de chiffrement envoyé par le client dans ClientHello. La négociation TLS échoue si le client ne prend pas en charge une suite de chiffrement incluant l'algorithme de clé publique (ECDSA ou RSA) du certificat sélectionné par l'équilibreur de charge.

Étapes suivantes

• Chiffrement vers les backends

• Livre blanc Chiffrement en transit dans Trusted Cloud