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 ou plusieurs certificats SSL Compute Engine (entre 1 et 15). 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.

Équilibreur de charge Méthode de configuration du certificat : les références du proxy cible...
Certificats SSL Compute Engine Un mappage de certificat Certificate Manager Directement dans le gestionnaire de certificats
Équilibreurs de charge d'application (proxys HTTPS cibles)
Équilibreur de charge d'application externe régional Compatible avec les certificats régionaux
Autogéré
Géré par Google 		Géré par l'utilisateur
Géré par Google
Équilibreur de charge d'application interne régional Compatible avec les certificats régionaux
Autogéré
Géré par Google 		Géré par l'utilisateur
Géré par Google

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

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