Le gestionnaire de certificats utilise un mécanisme de mappage flexible qui vous offre un contrôle précis sur les certificats que vous pouvez attribuer et sur la manière de les diffuser pour chaque nom de domaine de votre environnement. Le mécanisme comprend les entités suivantes:
- Certificats
- Mappages de certificats
- Entrées de mappage de certificats
- Autorisations de domaine
Le schéma suivant illustre les relations entre ces entités pour un proxy cible type spécifié dans une règle de transfert d'équilibreur de charge:
Le gestionnaire de certificats est compatible avec les proxys HTTPS cibles et les proxys SSL cibles. Pour en savoir plus sur les différences entre ces types de proxy, consultez la section Utiliser des proxys cibles.
Pour en savoir plus sur les types de certificats compatibles avec le Gestionnaire de certificats, consultez la section Présentation du déploiement.
Certificats
Par défaut, un certificat représente un certificat SSL (Transport Layer Security) X.509 unique émis pour des noms de domaine ou des caractères génériques de domaine spécifiques.
Le gestionnaire de certificats accepte les types de certificats suivants:
- Les certificats gérés par Google sont des certificats que Google Cloud obtient et gère pour vous.
- Les certificats autogérés sont des certificats que vous obtenez, provisionnez et renouvelez vous-même.
Lorsque vous émettez un certificat à l'aide d'une autorité de certification approuvée publiquement, celle-ci publie des informations sur le domaine associé dans les journaux de transparence des certificats, qui sont accessibles publiquement. Cela fait partie du processus standard d'émission de certificats adopté par toutes les autorités de certification publiquement approuvées. Il s'applique à la fois aux certificats gérés par Google et aux certificats autogérés. Toutefois, si vous utilisez Certificate Authority Service pour émettre votre certificat géré par Google, le gestionnaire de certificats ne publie aucune information dans les journaux de transparence des certificats.
Pour en savoir plus, consultez la page Transparence des certificats.
Pour savoir comment déployer un certificat avec le gestionnaire de certificats, consultez la section Présentation du déploiement.
Certificats gérés par Google
La gestion des certificats TLS (SSL) gérés par Google pour vos sites Web et applications peut s'avérer complexe et chronophage, qui nécessite souvent une configuration manuelle et une maintenance régulière. Le gestionnaire de certificats est un service conçu pour vous aider à rationaliser ce processus en fournissant une plate-forme centralisée. Vous pouvez déléguer la responsabilité de l'émission et du renouvellement des certificats au gestionnaire de certificats, ce qui vous permet de consacrer plus de temps à d'autres tâches critiques.
Vous pouvez valider la propriété du domaine concerné à l'aide d'une autorisation basée sur l'équilibreur de charge ou sur une autorisation DNS. Le gestionnaire de certificats accepte les certificats RSA gérés par Google.
Par défaut, l'autorité de certification Google émet des certificats gérés par Google. Lorsqu'un nouveau certificat géré par Google est émis ou renouvelé, il utilise une clé privée qui vient d'être générée. Si vous ne pouvez pas obtenir de certificat auprès de l'autorité de certification Google pour un domaine particulier, le gestionnaire de certificats rebascule sur l'autorité de certification Let's Encrypt. Par exemple, l'autorité de certification Google peut refuser d'émettre un certificat pour le domaine, ou votre enregistrement d'autorisation de l'autorité de certification interdit explicitement à l'autorité de certification Google d'émettre des certificats pour ce domaine.
L'authentification côté client uniquement n'est pas disponible.
Pour savoir comment limiter les autorités de certification pouvant émettre des certificats pour vos domaines, consultez la section Spécifier les autorités de certification pouvant émettre votre certificat géré par Google.
Notez que les certificats régionaux gérés par Google (version preview) ne sont compatibles qu'avec les autorisations DNS et qu'ils obtiennent des certificats auprès de l'autorité de certification Google.
Certificats gérés par Google émis par Certificate Authority Service
Si vous souhaitez utiliser votre propre chaîne de confiance plutôt que de dépendre d'autorités de certification publiques approuvées par Google pour émettre vos certificats, vous pouvez configurer le gestionnaire de certificats de sorte qu'il utilise un pool d'autorités de certification de Certificate Authority Service en tant qu'émetteur de certificat. Pour en savoir plus sur les pools d'autorités de certification, consultez la page Créer des pools d'autorités de certification.
Certificats autogérés
Si les exigences de votre entreprise ne vous permettent pas d'utiliser les certificats gérés par Google, vous pouvez importer des certificats émis par des autorités de certification externes avec les clés associées. Vous êtes responsable de l'émission et du renouvellement manuels des certificats autogérés.
Le gestionnaire de certificats vous permet également de déployer des certificats régionaux autogérés sur des proxys proxy Web sécurisé et des équilibreurs de charge régionaux.
Mappages de certificats
Un mappage de certificat référence une ou plusieurs entrées de mappage de certificat qui attribuent des certificats spécifiques à des noms d'hôte spécifiques. Les entrées de mappage de certificats définissent également la logique de sélection que l'équilibreur de charge suit lors de l'établissement des connexions client. Vous pouvez associer un mappage de certificat à plusieurs proxys cibles afin de le réutiliser sur plusieurs équilibreurs de charge.
Si un client demande un nom d'hôte spécifié dans un mappage de certificats, l'équilibreur de charge diffuse les certificats mappés avec ce nom d'hôte. Sinon, l'équilibreur de charge diffuse le certificat principal. Pour en savoir plus, consultez la section Logique de sélection des certificats.
Entrées de mappage de certificats
Une entrée de mappage de certificats est une liste de certificats diffusés pour un nom de domaine spécifique. Vous pouvez définir différents ensembles de certificats pour différents noms de domaine, tels que des domaines ou des sous-domaines. Par exemple, vous pouvez importer un certificat ECDSA et un certificat RSA, puis les mapper au même nom de domaine. Lorsqu'un client se connecte à ce nom de domaine, l'équilibreur de charge négocie le type de certificat à diffuser auprès du client lors du handshake.
Autorisations de domaine
Le gestionnaire de certificats vous permet de prouver que vous êtes le propriétaire des domaines pour lesquels vous souhaitez émettre des certificats gérés par Google, comme décrit dans le tableau suivant.
| Autorisation d'équilibreur de charge | Autorisation DNS | |
|---|---|---|
| Complexité de la configuration | Elle ne nécessite pas d'étapes de configuration supplémentaires ni de modifications de votre configuration DNS. | Vous devez créer une autorisation DNS et ajouter l'enregistrement CNAME correspondant à votre configuration DNS. |
| Sécurité du réseau | L'équilibreur de charge doit être entièrement accessible depuis Internet sur le port 443, y compris la configuration DNS pour tous les domaines diffusés par le certificat. Ne fonctionne pas avec les autres configurations. | Fonctionne avec des configurations très complexes, telles que les ports autres que le port 443 et les couches CDN devant le proxy cible. |
| Vitesse de provisionnement | Vous ne pouvez provisionner des certificats qu'une fois que l'équilibreur de charge a été entièrement configuré et diffuse le trafic réseau. | Vous pouvez provisionner des certificats à l'avance, avant que le proxy cible ne soit prêt à diffuser le trafic réseau. |
Pour comprendre comment le gestionnaire de certificats vérifie la propriété du domaine à l'aide de chaque méthode, consultez la page Autorisations de domaine pour les certificats gérés par Google.
Configurations d'émission de certificats
Une configuration d'émission de certificats est une ressource qui permet au gestionnaire de certificats d'utiliser un pool d'autorités de certification de votre propre instance Certificate Authority Service pour émettre des certificats gérés par Google à la place de l'autorité de certification Google ou de l'autorité de certification Let's Encrypt. Il vous permet de spécifier un certain nombre de paramètres régissant l'émission et l'expiration des certificats, ainsi que de sélectionner l'algorithme de clé pour les certificats émis de cette manière.
Configurations de confiance
Une configuration de confiance est une ressource qui représente votre configuration d'infrastructure à clé publique (PKI) dans le gestionnaire de certificats. Elle est utilisée dans les scénarios d'authentification TLS mutuelle. Il encapsule un seul magasin de confiance, qui à son tour encapsule une ancre de confiance et, éventuellement, un ou plusieurs certificats intermédiaires.
Pour en savoir plus sur l'authentification TLS mutuelle, consultez la page Authentification TLS mutuelle dans la documentation Cloud Load Balancing.
Une ressource de configuration de confiance encapsule un magasin de confiance, une ancre de confiance et des entités de certificat intermédiaires.
Magasins de confiance
Un magasin de confiance représente la configuration du secret de confiance dans le gestionnaire de certificats. Il doit être utilisé dans des scénarios d'authentification TLS mutuelle. Il encapsule une ancre de confiance unique et, éventuellement, un ou plusieurs certificats intermédiaires.
Ancres de confiance
Une ancre de confiance représente un certificat racine unique à utiliser dans les scénarios d'authentification TLS mutuelle. Il est encapsulé dans un magasin de confiance.
Certificats intermédiaires
Un certificat intermédiaire représente un certificat intermédiaire unique signé par un certificat racine ou un certificat intermédiaire référencé dans le magasin de confiance d'encapsulation, à utiliser dans les scénarios d'authentification TLS mutuelle.
Un ou plusieurs certificats intermédiaires peuvent être encapsulés dans un magasin de confiance, en fonction de votre configuration PKI. Tous les certificats intermédiaires spécifiés dans une configuration de confiance sont inclus dans l'évaluation de la confiance pour chaque requête de connexion, en plus de la liste des certificats intermédiaires spécifiée dans la requête elle-même.
Certificats nécessitant une liste d'autorisation
Si vous devez utiliser un certificat autosigné, qui a expiré ou qui n'est pas valide, ou si vous n'avez pas accès aux certificats racine et intermédiaires, vous pouvez l'ajouter à la configuration de confiance dans le champ allowlistedCertificates. Vous n'avez pas besoin d'un magasin de confiance pour ajouter un certificat à une liste d'autorisation.
L'ajout d'un certificat à la liste d'autorisation signifie qu'il est toujours considéré comme valide tant qu'il peut être analysé, qu'une preuve de possession de la clé privée est établie et que les contraintes du champ SAN du certificat sont remplies.
Logique de sélection du certificat
De manière générale, l'équilibreur de charge sélectionne un certificat comme suit:
- Un client initie un handshake. Au cours de cette étape, il fournit à l'équilibreur de charge une liste d'algorithmes cryptographiques qu'il peut utiliser pour effectuer le handshake et, éventuellement, un nom d'hôte.
L'équilibreur de charge sélectionne un certificat pour effectuer le handshake sécurisé en fonction du nom d'hôte fourni par le client et des entrées de mappage de certificat configuré. Les facteurs qui déterminent le certificat sélectionné par l'équilibreur de charge sont les suivants:
Correspondance exacte de nom d'hôte: si le client fournit un nom d'hôte qui correspond exactement à une entrée du mappage de certificats provisionnés, l'équilibreur de charge sélectionne le certificat correspondant.
Correspondance de nom d'hôte avec caractères génériques: si le nom d'hôte du client ne correspond à aucune entrée, mais à un nom d'hôte générique dans une entrée de mappage de certificats, l'équilibreur de charge sélectionne le certificat correspondant à partir de cette entrée. Par exemple, une entrée de caractère générique configurée en tant que
*.myorg.example.comcouvre les sous-domaines de premier niveau du domainemyorg.example.com.Aucune correspondance de nom d'hôte et entrée de mappage de certificat principal préconfigurée : l'équilibreur de charge sélectionne une entrée de mappage de certificat principal préconfiguré en l'absence de correspondance de nom d'hôte ou d'entrée de mappage de certificat provisionné correspondante.
Échec du handshake: le handshake échoue si l'équilibreur de charge ne parvient pas à trouver de certificat correspondant pour les raisons suivantes:
- Le client fournit un nom d'hôte qui ne correspond à aucun nom d'hôte exact ou générique spécifié dans toutes les entrées de mappage de certificats provisionnés, ou qui ne fournit aucun nom d'hôte.
- Une entrée de mappage de certificat principal correspondant est introuvable, ou si vous n'avez pas configuré d'entrée de mappage de certificat principal.
Priorité des certificats
L'équilibreur de charge sélectionne un certificat dans une entrée de mappage de certificats en fonction des éléments suivants:
- Type de certificat : Si le client qui se connecte est compatible avec les certificats ECDSA plus sécurisés, l'équilibreur de charge les donne en priorité aux certificats RSA. Si le client n'indique pas la compatibilité avec les certificats ECDSA, l'équilibreur de charge diffuse un certificat RSA à la place.
- Taille du certificat. L'équilibreur de charge donne la priorité aux certificats du plus petit au plus grand.
Noms de domaine avec des caractères génériques
Les règles suivantes s'appliquent aux noms de domaine utilisant des caractères génériques:
- Seuls les certificats gérés par Google avec une autorisation DNS et les certificats gérés par Google avec Certificate Authority Service acceptent les noms de domaine avec des caractères génériques. Les certificats gérés par Google avec autorisation d'équilibreur de charge ne sont pas compatibles avec les noms de domaine comportant des caractères génériques.
- Une correspondance exacte est prioritaire sur un caractère générique lorsque les deux sont définis dans l'entrée. Par exemple, si vous avez configuré des entrées de mappage de certificats pour
www.myorg.example.comet*.myorg.example.com, une demande de connexion surwww.myorg.example.comsélectionne toujours l'entrée pourwww.myorg.example.com, même s'il existe également une entrée pour*.myorg.example.com. - Les noms de domaine avec des caractères génériques ne correspondent qu'à un seul niveau de sous-domaine. Par exemple, une demande de connexion pour
host1.myorg.example.comsélectionne une entrée de mappage de certificats pour*.myorg.example.com, mais pas pourhost1.hosts.myorg.example.com.
Public CA
Pour utiliser la fonctionnalité d'autorité de certification publique du gestionnaire de certificats, vous devez connaître les concepts suivants:
client ACME. Un client ACME (Automatic Certificate Management Environment) est un client de gestion des certificats qui utilise le protocole ACME. Votre client ACME doit être compatible avec la liaison de compte externe (EAB) pour fonctionner avec une CA publique.
Liaison de compte externe (EAB). Vous devez lier chaque compte ACME que vous utilisez avec une autorité de certification publique du gestionnaire de certificats au projet Google Cloud cible à l'aide d'une liaison de compte externe. Pour ce faire, vous devez enregistrer chaque compte ACME à l'aide d'un secret associé au projet Google Cloud correspondant. Pour en savoir plus, consultez la section Liaison de compte externe.
Défis d'Public CA
Lorsque vous utilisez Public CA pour demander un certificat, le gestionnaire de certificats vous demande de prouver votre contrôle sur les domaines répertoriés dans ce certificat. Vous pouvez prouver votre contrôle du domaine en relevant des défis. Public CA autorise les noms de domaine une fois que vous avez prouvé que vous contrôlez les domaines cibles.
Une fois que vous avez obtenu les autorisations requises, vous pouvez demander des certificats valides uniquement pendant une durée spécifique. Passé ce délai, vous devez revalider le nom de domaine en résolvant l'un des trois types d'authentification pour continuer à demander des certificats.
Types de questions d'authentification
Public CA accepte les types de questions suivants:
Défi HTTP : Cette difficulté consiste à créer un fichier à un emplacement bien connu sur un serveur HTTP (port 80) afin que Public CA puisse le récupérer et le vérifier. Pour en savoir plus, consultez la section Question d'authentification HTTP.
Question d'authentification ALPN (TLS-Application Layer Protocol Negotiation). Nécessite qu'un serveur fournisse un certificat spécifique lors d'une négociation TLS sur le port 443 afin de prouver le contrôle d'un domaine. Pour en savoir plus, consultez Extension de défi TLS-ALPN ACME.
Défi DNS. Nécessite l’ajout d’un enregistrement DNS spécifique à un emplacement défini pour prouver le contrôle d’un domaine. Pour en savoir plus, consultez la section Défi DNS.
Si vous utilisez le test HTTP ou TLS-ALPN pour valider un nom de domaine, le client ne peut demander que les noms de domaine validés à inclure dans un certificat. Si vous utilisez la question d'authentification DNS, le client peut également demander à inclure les sous-domaines de ce nom de domaine dans un certificat.
Par exemple, si vous validez *.myorg.example.com à l'aide du défi DNS, subdomain1.myorg.example.com et subdomain2.myorg.example.com sont automatiquement couverts par le certificat générique. Toutefois, si vous validez myorg.example.com à l'aide d'un test HTTP ou TLS-ALPN, le client ne peut demander qu'à inclure myorg.example.com dans le certificat, et vous ne pouvez pas valider *.myorg.example.com à l'aide des questions d'authentification non DNS.
Logique de la solution pour le défi
La logique d'authentification des CA publiques est la suivante:
- Public CA fournit un jeton aléatoire.
- Le client rend le jeton disponible à un emplacement bien défini. Le lieu dépend du défi.
- Le client indique à Public CA qu'il a préparé le défi.
- L'Public CA vérifie si le jeton présent à l'emplacement attendu correspond à la valeur attendue.
Le nom de domaine est autorisé une fois ce processus terminé. Le client peut demander un certificat contenant ce nom de domaine. Vous ne devez résoudre qu'un seul défi par nom de domaine.