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 c'est le cas 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.

Cette page traite des certificats SSL et du chiffrement en transit entre un équilibreur de charge d'application ou un équilibreur de charge réseau proxy qui utilise SSL et ses clients. Pour en savoir plus sur le chiffrement en transit entre l'équilibreur de charge Cloud de Confiance et ses backends, consultez Chiffrement vers les backends.

Méthode de configuration des certificats

Pour les équilibreurs de charge d'application utilisant des proxys HTTPS cibles, le proxy cible de l'équilibreur de charge doit référencer entre un et 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 de certificat 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 de ressources de certificat SSL Compute Engine. Pour en savoir plus, consultez Utiliser des certificats SSL autogérés.

Types de clés compatibles

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 renforcée, d'excellentes performances pour les opérations de signature et une utilisation efficace de la bande passante réseau.

Voici quelques-unes des 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 nécessitent l'utilisation de clés de plus grande taille ou de types de clés particuliers, vous pouvez utiliser des 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 nettement plus petites que celles de RSA. Cette efficacité se traduit par des avantages tangibles 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 compatible.

Principaux avantages d'ECDSA :

• Performances : les opérations de signature ECDSA sont beaucoup moins gourmandes en ressources de calcul que les opérations RSA offrant un niveau de sécurité équivalent. Cela réduit la charge du processeur et la latence, ce qui est crucial 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 d'espace 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 référencer jusqu'à 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 du certificat

Le processus de sélection de certificat suivant 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 rapport aux attributs de certificat du nom commun (CN) et de l'autre nom de l'objet (SAN). Si un seul certificat correspond au nom d'hôte SNI, l'équilibreur de charge sélectionne ce certificat. Si plusieurs certificats correspondent au nom d'hôte SNI, l'équilibreur de charge les priorise dans l'ordre suivant :

      • Correspondance exacte du nom d'hôte : les correspondances exactes avec le CN ou le SAN sont prioritaires sur les correspondances avec un caractère générique.

      • Correspondance de nom d'hôte avec caractère générique : s'il n'y a pas de correspondance exacte, l'équilibreur de charge recherche une correspondance de CN ou de SAN avec caractère générique. Un caractère générique (*) ne correspond qu'au sous-domaine de premier niveau (par exemple, *.pets.example.com correspond à cats.pets.example.com plutôt qu'à *.example.com).

      • Type de clé de certificat : les certificats ECDSA sont préférés aux certificats RSA.

      • Taille de la chaîne de certificats : si plusieurs certificats ont la même spécificité de correspondance et le même algorithme de clé publique, l'équilibreur de charge donne la priorité au certificat dont la taille de la chaîne de certificats est la plus petite (en octets) afin de minimiser la bande passante réseau pendant le handshake TLS.

    • 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

    • Examinons maintenant les scénarios 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, et le certificat A et le certificat B correspondent à *.pets.example.com dans leur liste de SAN. Si les deux certificats utilisent le même algorithme de clé publique, l'équilibreur de charge sélectionne le certificat dont la taille de chaîne de certificats est la plus petite. Si les tailles de chaîne de certificats sont également identiques, l'équilibreur de charge sélectionne soit le certificat A, soit le certificat B, et vous ne pouvez pas contrôler le certificat sélectionné.

• Une fois qu'un certificat a été 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 n'est pas compatible avec 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 sur le chiffrement en transit dans Cloud de Confiance