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:
<ph type="x-smartling-placeholder">
Le gestionnaire de certificats est compatible avec les proxys HTTPS cibles et les proxys SSL cibles. Pour plus sur les différences entre ces types de proxy, consultez Utiliser des proxys cibles
Pour en savoir plus sur les types de certificats concernés par 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 renouveler votre abonnement.
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 du processus standard d'émission de certificats adopté par toutes les autorités de certification publiquement approuvées, et s'applique aux certificats gérés par Google et des 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 pas dans les journaux de transparence des certificats.
Pour en savoir plus, consultez Transparence des certificats.
Pour apprendre à déployer un certificat avec le gestionnaire de certificats, consultez la page Présentation du déploiement.
Certificats gérés par Google
Gérer les certificats TLS (SSL) gérés par Google pour vos sites Web et vos 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 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 est compatible avec RSA Certificats 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 peut pas obtenir de certificat auprès de l'autorité de certification Google pour un domaine particulier, Le gestionnaire de certificats fait appel à l’autorité de certification Let’s Encrypt. Pour Par exemple, l'autorité de certification Google peut refuser de délivrer un certificat pour le domaine. votre enregistrement d'autorisation d'autorité de certification interdit explicitement à l'autorité de certification Google d'émettre de certificats pour ce domaine.
L'authentification côté client uniquement n'est pas disponible.
Pour obtenir des instructions sur la façon de limiter les autorités de certification pouvant émettre des certificats pour vos domaines, consultez 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 des autorités de certification publiques approuvées par Google pour émettre vos certificats, vous pouvez configurer le gestionnaire de certificats afin 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 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 et 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 fait 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 certificat 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, la charge diffuse le certificat principal. Pour plus d'informations, 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. Vous pouvez définir différents jeux de certificats pour différents noms de domaine, comme des domaines ou des sous-domaines. Par exemple, vous pouvez importer un ECDSA et une ARR. certificat et les mapper au 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 aucune étape de configuration supplémentaire ni aucune modification de votre DNS configuration. | Vous devez créer une autorisation DNS et ajouter l'autorisation à 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 de tous les domaines desservis par certificat. Ne fonctionne pas avec les autres configurations. | Elle fonctionne avec des configurations très complexes, telles que des ports autres que 443 et CDN devant le proxy cible. |
| Vitesse de provisionnement | Vous ne pouvez provisionner des certificats qu'après avoir entièrement configuré et qui diffuse 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 valide la propriété du domaine à l'aide de chaque méthode, consultez 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 pour utiliser un pool d'autorités de certification à partir de votre propre instance Certificate Authority Service d'émettre des certificats gérés par Google plutôt que l'AC de Google ou l'AC Let's Encrypt. Il vous permet pour spécifier un certain nombre de paramètres régissant l'émission et l'expiration des certificats, ainsi que 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. 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 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 un certificat intermédiaire entités.
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
Une ancre de confiance représente un seul certificat racine à utiliser dans le protocole TLS mutuel d'authentification. 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 votre configuration PKI. Tous les certificats intermédiaires spécifiés d'une configuration de confiance sont inclus dans l'évaluation de la confiance pour chaque demande de connexion en plus de la liste des certificats intermédiaires spécifié dans la requête elle-même.
Certificats nécessitant une liste d'autorisation
Si vous avez besoin d'utiliser un certificat autosigné, vous pouvez également
est arrivée à expiration, n'est pas valide, ou si vous n'avez pas accès au répertoire racine
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
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 initie 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 dont dispose l'équilibreur de charge sont les suivantes:
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: 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.
- 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 les éléments suivants:
- Type de certificat : Si le client qui se connecte est compatible avec le protocole ECDSA, les certificats RSA, l'équilibreur de charge les priorise par rapport aux certificats RSA. Si le 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 à la plus grande.
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 le champ
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 avec des caractères génériques ne correspondent qu'à un seul niveau de sous-domaine. Pour
exemple, une demande de connexion pour
host1.myorg.example.comsélectionne un certificat entrée de carte 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 ê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 au gestionnaire de certificats CA publique vers le projet Google Cloud cible à l'aide d'une liaison de compte externe. Pour ce faire, vous devez enregistrer chaque 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 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. L'Public CA autorise les noms de domaine une fois que vous avez prouvé votre des domaines cibles.
Une fois que vous avez obtenu les autorisations requises, vous pouvez demander des certificats qui ne sont valides que pour une durée déterminée. Passé ce délai, vous devez revalider 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.
Question d'authentification ALPN (TLS-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 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'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 la solution pour le défi
La logique d'authentification des CA publiques est la suivante:
- L'Public CA fournit un jeton aléatoire.
- Le client rend le jeton disponible à un emplacement bien défini. La l'emplacement dépend du défi.
- Le client indique à Public CA qu'il a préparé le d'authentification.
- L'Public CA vérifie si le jeton est présent au niveau location 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 n'avez besoin d'en résoudre qu'un seul par nom de domaine.