Le gestionnaire de certificats utilise un mécanisme de mappage flexible qui vous permet de contrôler précisément les certificats que vous pouvez attribuer et comment les diffuser pour chaque nom de domaine de votre environnement. Le mécanisme inclut 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 et 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 seul protocole X.509 Transport Layer Security un certificat TLS (SSL) délivré pour des noms de domaine ou des domaines spécifiques ; et utiliser des caractères génériques.
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, l'autorité de certification publie des informations sur le domaine associé aux journaux de transparence des certificats, qui sont accessibles publiquement. Cela fait partie de l'émission standard des certificats adopté par toutes les autorités de certification publiquement approuvées et s'applique Certificats gérés par Google et certificats autogérés. Toutefois, si vous utilisez le service 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 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 être une tâche complexe et chronophage, qui implique 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 plateforme centralisée. Vous pouvez déléguer la responsabilité de la délivrance et du renouvellement des certificats au Gestionnaire de certificats, ce qui vous permet de vous concentrer sur d'autres tâches critiques.
Vous pouvez valider la propriété du domaine concerné à l'aide d'une méthode basée sur un équilibreur de charge ou Autorisation basée sur DNS Le gestionnaire de certificats est compatible avec 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 générée récemment. Si vous ne parvenez pas à obtenir un certificat auprès de l'autorité de certification Google pour un domaine donné, le Gestionnaire de certificats utilise 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 d'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 prise en charge.
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 qui peuvent émettre un certificat géré par Google.
Notez que les certificats régionaux gérés par Google n'acceptent que l'autorisation basée sur le DNS et 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 des ressources d'autorités de certification publiques pour émettre vos certificats, vous pouvez configurer le gestionnaire de certificats d'utiliser un pool d'autorités de certification du Certificate Authority Service en tant qu'émetteur de certificat. Pour en savoir plus sur les pools d'autorités de certification, consultez 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 des clés de chiffrement vous pouvez importer des certificats émis par des autorités de certification externes 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 autogérés Proxys proxy Web sécurisé et proxys régionaux HTTP(S) externes.
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 du client connexions externes. Vous pouvez associer un mappage de certificat à plusieurs proxys cibles pour la réutilisation sur plusieurs équilibreurs de charge.
Si un client demande un nom d'hôte spécifié dans un mappage de certificat, la charge l'équilibreur de charge diffuse les certificats mappés sur 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 de 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. 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 sur le même nom de domaine. Lorsqu'un client se connecte à l'équilibreur de charge négocie le type de certificat le client lors de la poignée de main.
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 tableau.
| Autorisation d'équilibreur de charge | Autorisation DNS | |
|---|---|---|
| Complexité de la configuration | 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 complexes, telles que des ports autres que 443 et des couches CDN devant le proxy cible. |
| Vitesse de provisionnement | Vous ne pouvez provisionner des certificats qu'après avoir entièrement configuré l'équilibreur de charge et qu'il traite le trafic réseau. | Vous pouvez provisionner des certificats à l'avance, avant que le proxy cible prêts à 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 section Autorisations de domaine pour les certificats gérés par Google.
Configuration 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 à partir de votre propre instance de Certificate Authority Service pour émettre des certificats gérés par Google au lieu 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 qui régissent 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 pour une utilisation dans des scénarios d'authentification TLS mutuelle. Cette configuration de confiance encapsule un seul store de confiance, lequel encapsule à son tour une ancre de confiance et, éventuellement, un ou plusieurs certificats intermédiaires.
Pour en savoir plus sur l'authentification TLS mutuelle, consultez la section Authentification TLS mutuelle dans la documentation Cloud Load Balancing.
Une ressource de configuration de confiance encapsule les entités de magasin de confiance, d'ancre de confiance et de certificat intermédiaire.
Magasins de confiance
Un magasin de confiance représente la configuration du secret de confiance dans le gestionnaire de certificats à utiliser dans des scénarios d'authentification TLS mutuelle. Il encapsule une seule ancre de confiance et, éventuellement, un ou plusieurs certificats intermédiaires.
Ancres de confiance
Un ancrage de confiance représente un seul certificat racine à 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 seul certificat intermédiaire signé par un certificat racine ou un certificat intermédiaire référencé dans le Encapsuler un magasin de confiance à utiliser dans l'authentification TLS mutuelle différents scénarios.
Un ou plusieurs certificats intermédiaires peuvent être encapsulés dans un magasin de confiance, en fonction de la configuration de votre 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és dans la requête elle-même.
Certificats nécessitant une liste d'autorisation
Si vous devez utiliser un certificat autosigné, expiré ou non valide, ou si vous n'avez pas accès aux certificats racine et intermédiaires, vous pouvez ajouter ce certificat à la configuration de confiance dans le champ allowlistedCertificates. Vous n'avez pas besoin d'un magasin de confiance pour ajouter un
le certificat à une liste d'autorisation.
Lorsque vous ajoutez un certificat à la liste d'autorisation, il est toujours considérée comme valide tant que le certificat peut être analysé, preuve de clé privée la possession est établie et les contraintes sur le 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 lance un handshake. Au cours de cette étape, il fournit à l'équilibreur de charge avec une liste d’algorithmes cryptographiques qu’il peut utiliser pour effectuer la poignée de main, et, éventuellement, un nom d'hôte.
L'équilibreur de charge sélectionne un certificat pour effectuer le handshake sécurisé en fonction sur le nom d'hôte fourni par le client et sur le mappage de certificats configuré les entrées correspondantes. 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 avec un nom d'hôte générique : 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 certificat, 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: En l'absence de correspondance de nom d'hôte ou d'entrée correspondante de mappage de certificat provisionné, l'équilibreur de charge sélectionne une entrée de mappage de certificat principal préconfiguré.
É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.
- Aucune entrée de mappage de certificat principal ne correspond ou 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 les éléments suivants:
- Type de certificat : Si le client qui se connecte accepte les certificats ECDSA plus sécurisés, l'équilibreur de charge les priorise par rapport aux certificats RSA. Si le client n'indique pas la prise en charge des certificats ECDSA, l'équilibreur de charge diffuse un certificat RSA à la place.
- Taille du certificat. L'équilibreur de charge donne la priorité aux certificats de la taille la plus petite à la plus grande.
Noms de domaine avec 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 autorisation DNS et les certificats gérés par Google avec service CA sont compatibles avec les noms de domaine 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 connexionwww.myorg.example.comsélectionne toujours l'entrée pourwww.myorg.example.com, même si une une entrée pour*.myorg.example.comexiste également. - Les noms de domaine génériques ne correspondent qu'à un seul niveau de sous-domaine. Par exemple, une requête 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é CA publique du gestionnaire de certificats, vous devez connaître avec les concepts suivants:
Client ACME Un client ACME (Automatic Certificate Management Environment) est un client qui utilise le protocole ACME. Votre client ACME doit prendre en charge la liaison de compte externe (EAB) pour fonctionner avec une autorité de certification publique.
Liaison de compte externe (EAB) Vous devez associer chaque compte ACME que vous utilisez avec l'autorité de certification publique du Gestionnaire de certificats au projet Google Cloud cible à l'aide de l'association de compte externe. Pour ce faire, vous devez enregistrer chaque compte ACME à l'aide d'un secret associé à son projet Google Cloud correspondant. Pour en savoir plus, consultez la page Compte externe de liaison.
Défis liés aux autorités de certification publiques
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 que vous contrôlez le domaine en résolvant des défis. L'autorité de certification publique 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 qui ne sont valides que pendant une durée spécifique. Passé ce délai, vous devez valider à nouveau le nom de domaine en résolvant l'un des trois types de défis pour continuer à demander des certificats.
Types de questions d'authentification
L'Public CA accepte les types de questions suivants:
Défi HTTP : Ce défi consiste à créer un fichier à un niveau emplacement sur un serveur HTTP (port 80) pour que Public CA puisse récupérer et vérifier. Pour en savoir plus, consultez la section Question d'authentification HTTP.
Défi TLS-ALPN (Application Layer Protocol Negotiation) Nécessite un pour fournir un certificat spécifique lors d'une négociation TLS sur le port 443 pour prouver que vous avez le contrôle d’un domaine. Pour en savoir plus, consultez Extension du 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 nom de domaine, le client ne peut demander que le domaine validé noms à inclure dans un certificat. Si vous utilisez le défi DNS, client peut également demander à ce que les sous-domaines de ce nom de domaine soient inclus dans un certificat.
Par exemple, si vous validez *.myorg.example.com à l'aide de la requête 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'une requête HTTP ou
Question d'authentification TLS-ALPN à laquelle le client peut uniquement demander d'inclure myorg.example.com
le certificat, et vous ne pouvez pas valider *.myorg.example.com à l'aide de questions d'authentification non DNS.
Logique de solution de défi
La logique d'authentification à une CA publique est la suivante:
- L'autorité de certification publique fournit un jeton aléatoire.
- Le client met le jeton à disposition à un emplacement bien défini. La l'emplacement dépend du défi.
- Le client indique à l'autorité de certification publique qu'il a préparé le défi.
- L'autorité de certification publique vérifie si le jeton présent à l'emplacement prévu correspond à la valeur attendue.
Le nom de domaine est autorisé une fois ce processus terminé. Le client peut demander un certificat avec ce nom de domaine. Vous ne devez résoudre qu'un seul défi par nom de domaine.