Le gestionnaire de certificats utilise un mécanisme de mappage flexible qui vous permet de contrôler avec précision les certificats que vous pouvez attribuer et 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 certificat
- Autorisations de domaine
Le schéma suivant illustre les relations entre ces entités pour un proxy cible standard 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 proxys, consultez la page Utiliser des proxys cibles.
À l'aide du gestionnaire de certificats, vous pouvez joindre des certificats de différentes manières:
- Si vous déployez des certificats sur des équilibreurs de charge d'application externes globaux, utilisez des mappages de certificats associés aux proxys cibles et aux entrées de mappage de certificats. Pour en savoir plus, consultez Déployer un certificat autogéré global.
- Si vous déployez des certificats sur des équilibreurs de charge d'application externes régionaux, des équilibreurs de charge d'application internes régionaux ou des passerelles proxy Web sécurisé, associez-les directement aux proxys cibles ou aux passerelles proxy Web sécurisé. Pour en savoir plus, consultez Déployer un certificat autogéré régional.
- Si vous déployez des certificats sur des équilibreurs de charge d'application internes interrégionaux, associez les certificats avec le champ d'application
ALL_REGIONSdirectement aux proxys cibles. Les équilibreurs de charge d'application internes interrégionaux ne sont pas compatibles avec les certificats gérés par Google avec autorisation de l'équilibreur de charge. Toutefois, ils sont compatibles avec l'autorisation DNS et l'autorisation Certificate Authority Service.
Certificats
Par défaut, un certificat représente un seul certificat X.509 Transport Layer Security (TLS) (SSL) é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 des 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 approuvées publiquement et 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 vos applications peut être une tâche complexe et fastidieuse, 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 plate-forme centralisée. Vous pouvez déléguer la responsabilité de l'émission et du renouvellement des certificats au gestionnaire de certificats. Vous pouvez ainsi 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 un équilibreur de charge ou sur le DNS. Le gestionnaire de certificats est compatible avec les ARR 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 bascule 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 d'autorité de certification l'empêche explicitement 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 pouvant émettre votre certificat géré par Google.
Notez que les certificats régionaux gérés par Google (Preview) n'acceptent que les autorisations basées sur le DNS et obtiennent des certificats auprès de l'autorité de certification de 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 de sorte qu'il utilise un pool d'autorités de certification de Certificate Authority Service en tant qu'émetteur de certificats. 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 des 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 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 pour établir des connexions client. Vous pouvez associer un mappage de certificat à plusieurs proxys cibles en vue de sa réutilisation 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 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 des certificats.
Entrées de mappage de certificat
Une entrée de mappage de certificat 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 sur le 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 | 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 des ports autres que 443 et des 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 qu'il 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 section 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 Let's Encrypt. Elle 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. Elle est utilisée dans des scénarios d'authentification TLS mutuelle. Il encapsule un seul store de confiance, qui 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 page 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 des secrets de confiance dans le gestionnaire de certificats à utiliser dans les 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 certificat racine unique à utiliser dans des 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 par un certificat intermédiaire référencé dans le magasin de confiance d'encapsulation destiné à être utilisé dans des 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és dans la requête elle-même.
Certificats ajoutés à la liste d'autorisation
Un certificat sur liste d'autorisation représente tout certificat pouvant être encapsulé dans la configuration de confiance afin qu'il soit toujours considéré comme valide. Un certificat figurant sur la liste d'autorisation est toujours considéré comme valide tant qu'il peut être analysé, qu'une preuve de possession d'une clé privée est établie et que les contraintes du champ SAN du certificat sont remplies. Les certificats expirés sont également considérés comme valides lorsqu'ils sont ajoutés à la liste d'autorisation. Vous n'avez pas besoin d'un magasin de confiance lorsque vous utilisez des certificats ajoutés à la liste d'autorisation.
Logique de sélection des certificats
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 certificats configurés. Les facteurs qui déterminent le certificat sélectionné par l'équilibreur de charge sont les suivants:
Correspondance exacte du nom d'hôte: si le client fournit un nom d'hôte qui correspond exactement à une entrée du mappage de certificat provisionné, l'équilibreur de charge sélectionne le certificat correspondant.
Correspondance du nom d'hôte générique: si le nom d'hôte du client ne correspond à aucune entrée, mais correspond à 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 générique configurée en tant que
*.myorg.example.comcouvre les sous-domaines de premier niveau sous le 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ée 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 trouve pas 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 ne fournit pas de nom d'hôte du tout.
- Une entrée de mappage de certificat principal correspondante 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 de connexion est compatible avec les certificats ECDSA plus sécurisés, l'équilibreur de charge les priorise plutôt que les 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 avec 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 CA Service sont compatibles avec les noms de domaine génériques. Les certificats gérés par Google avec autorisation pour l'équilibreur de charge n'acceptent pas les noms de domaine avec des caractères génériques.
- Une correspondance exacte a priorité 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 requête de connexion envoyée àwww.myorg.example.comsélectionne toujours l'entrée dewww.myorg.example.com, même si une entrée pour*.myorg.example.comexiste également. - Les noms de domaine génériques ne peuvent être associés 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 certificat 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 de certificats qui utilise le protocole ACME. Votre client ACME doit accepter la liaison de compte externe (EAB) pour fonctionner avec une autorité de certification publique.
Liaison de compte externe (EAB) Vous devez lier chaque compte ACME que vous utilisez avec l'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 lié au projet Google Cloud correspondant. Pour en savoir plus, consultez la section Liaison de compte externe.
Défis de Public CA
Lorsque vous utilisez Public CA pour demander un certificat, le gestionnaire de certificats vous demande de prouver que vous contrôlez les domaines répertoriés dans ce certificat. Vous pouvez prouver que votre domaine vous appartient en résolvant 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 qui ne sont valides que 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 répondent aux types de défis suivants:
Question HTTP : Cette difficulté implique la création d'un fichier à un emplacement bien connu d'un serveur HTTP (port 80) pour permettre à lPublic CA de le récupérer et de le vérifier. Pour en savoir plus, consultez la section Question HTTP.
Défi AALPN (TLS-Application Layer Protocol Operator). 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 la section Extension de défi ACME TLS-ALPN.
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 défi 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 le défi 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 que l'inclusion de myorg.example.com dans le certificat, et vous ne pouvez pas valider *.myorg.example.com à l'aide des questions d'authentification autres que DNS.
Défier la logique de la solution
La logique d'authentification publique de l'autorité de certification est la suivante:
- Public CA fournit un jeton aléatoire.
- Le client rend le jeton disponible à un emplacement bien défini. L'emplacement dépend du défi.
- Le client indique à lPublic 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.