Vous pouvez utiliser Public Certificate Authority pour provisionner et déployer des certificats X.509 largement approuvés après avoir validé que le demandeur de certificat contrôle les domaines. L'Public CA vous permet de demander directement et par programmation des certificats TLS publiquement approuvés qui se trouvent déjà à la racine des magasins de confiance utilisés par les principaux navigateurs, systèmes d'exploitation et applications. Vous pouvez utiliser ces certificats TLS pour authentifier et chiffrer le trafic Internet.
L'Public CA vous permet de gérer des cas d'utilisation à volume élevé que d'autres autorités de certification n'ont pas pu prendre en charge. Si vous êtes un Google Cloud client, vous pouvez demander des certificats TLS pour vos domaines directement auprès de l'autorité de certification publique.
La plupart des problèmes liés aux certificats sont dus à une erreur humaine ou à un oubli. Nous vous recommandons donc d'automatiser les cycles de vie des certificats. L'Public CA utilise le protocole ACME (Automatic Certificate Management Environment) pour le provisionnement, le renouvellement et la révocation automatisés des certificats. La gestion automatisée des certificats réduit les temps d'arrêt que les certificats expirés peuvent entraîner et minimise les coûts opérationnels.
L'Public CA provisionne des certificats TLS pour plusieurs Google Cloud services, tels qu'App Engine, Cloud Shell, Google Kubernetes Engine et Cloud Load Balancing.
Qui doit utiliser Public CA ?
Vous pouvez utiliser Public CA pour les raisons suivantes :
- Si vous recherchez un fournisseur TLS offrant une ubiquité, une évolutivité, une sécurité et une fiabilité élevées.
- Si vous souhaitez obtenir la plupart, voire tous les certificats TLS pour votre infrastructure, y compris les charges de travail sur site et les configurations multi-fournisseurs cloud, auprès d'un seul fournisseur cloud.
- Si vous avez besoin de contrôler et de personnaliser la gestion des certificats TLS en fonction des exigences de votre infrastructure.
- Si vous souhaitez automatiser la gestion des certificats TLS, mais que vous ne pouvez pas utiliser de certificats gérés dans des Google Cloud services, tels que GKE ou Cloud Load Balancing.
Nous vous recommandons d'utiliser des certificats publiquement approuvés uniquement lorsque vos exigences commerciales ne permettent pas d'autre option. Compte tenu du coût et de la complexité historiques de la maintenance des hiérarchies d'infrastructure à clé publique (PKI), de nombreuses entreprises utilisent des hiérarchies PKI publiques, même lorsqu'une hiérarchie privée est plus judicieuse.
La maintenance des hiérarchies publiques et privées est devenue beaucoup plus simple grâce à plusieurs Google Cloud offres. Nous vous recommandons de choisir soigneusement le type de PKI adapté à votre cas d'utilisation.
Pour les exigences de certificat non public, Google Cloud propose deux solutions faciles à gérer :
Anthos Service Mesh : Cloud Service Mesh inclut le provisionnement de certificats mTLS entièrement automatisé pour les charges de travail exécutées dans GKE Enterprise à l'aide de l'autorité de certification Cloud Service Mesh.
Certificate Authority Service: Certificate Authority Service vous permet de déployer, de gérer et de sécuriser efficacement des autorités de certification privées personnalisées sans gérer l'infrastructure.
Avantages de Public CA
L'Public CA offre les avantages suivants :
Automatisation : les navigateurs Internet visant à chiffrer entièrement le trafic et à réduire les périodes de validité des certificats, il existe un risque d'utiliser des certificats TLS expirés. L'expiration des certificats peut entraîner des erreurs de site Web et des pannes de service. L'Public CA évite le problème d'expiration des certificats en vous permettant de configurer votre serveur HTTPS pour qu'il obtienne et renouvelle automatiquement les certificats TLS nécessaires à partir de notre point de terminaison ACME.
Conformité : Public CA fait l'objet d'audits indépendants réguliers et rigoureux des contrôles de sécurité, de confidentialité et de conformité. Les sceaux Webtrust accordés à la suite de ces audits annuels témoignent de la conformité de Public CA à toutes les normes sectorielles pertinentes.
Sécurité : l'architecture et les opérations de Public CA sont conçues selon les normes de sécurité les plus élevées. Des évaluations indépendantes sont régulièrement effectuées pour confirmer la sécurité de l'infrastructure sous-jacente. L'Public CA respecte ou dépasse tous les contrôles, pratiques opérationnelles et mesures de sécurité mentionnés dans le livre blanc sur la sécurité de Google.
L'accent mis par Public CA sur la sécurité s'étend à des fonctionnalités telles que la validation de domaine multi-perspective. L'infrastructure de Public CA est distribuée à l'échelle mondiale. Par conséquent, Public CA nécessite un degré élevé d'accord entre des perspectives géographiquement diverses, ce qui offre une protection contre le détournement du protocole BGP (Border Gateway Protocol) et les attaques de détournement du serveur DNS (Domain Name Server).
Fiabilité : l'utilisation de l'infrastructure technique éprouvée de Google fait de Public CA un service disponibilité élevée et évolutif.
Ubiquité : la forte ubiquité des navigateurs de Google Trust Services permet de s'assurer que les services utilisant des certificats émis par Public CA fonctionnent sur la plus large gamme possible d'appareils et de systèmes d'exploitation.
Solutions TLS simplifiées pour les configurations hybrides : Public CA vous permet de créer une solution de certificat TLS personnalisée qui utilise la même autorité de certification pour différents scénarios et cas d'utilisation. L'Public CA est efficace dans les cas d'utilisation où les charges de travail sont exécutées sur site ou dans un environnement multi-fournisseurs cloud.
Évolutivité : les certificats ont souvent été coûteux à obtenir, difficiles à provisionner et à gérer. En offrant un accès à de grands volumes de certificats, Public CA vous permet d'utiliser et de gérer des certificats de manière auparavant considérée comme irréalisable.
Utiliser l'autorité de certification publique avec le gestionnaire de certificats
Pour utiliser la fonctionnalité de Public CA 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 l'autorité de certification publique.
Liaison de compte externe (EAB). Vous devez lier chaque compte ACME que vous utilisez avec Public CA du gestionnaire de certificats au projet cible Google Cloud à l'aide de la liaison de compte externe. Pour ce faire, vous devez enregistrer chaque compte ACME à l'aide d'un secret associé au Google Cloud projet 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 listés dans ce certificat. Vous pouvez prouver le contrôle du domaine en résolvant des défis. L'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 pour une durée spécifique. Après cette durée, 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 défis
L'Public CA est compatible avec les types de défis suivants :
Défi HTTP. Ce défi consiste à créer un fichier à un emplacement connu sur un serveur HTTP (port 80) pour que Public CA puisse le récupérer et le valider. Pour en savoir plus, consultez la section Défi HTTP.
Défi ALPN (Application Layer Protocol Negotiation) TLS. Nécessite qu'un serveur fournisse un certificat spécifique lors d'une négociation TLS sur le port 443 pour 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 le défi TLS-ALPN pour valider un nom de domaine, le client ne peut demander que l'inclusion des noms de domaine validés dans un certificat. Si vous utilisez le défi DNS, le client peut également demander l'inclusion de 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 défi 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 défis non DNS.
Logique de solution aux défis
La logique de défi de l'autorité de certification publique est la suivante :
- L'Public CA fournit un jeton aléatoire.
- Le client met le jeton à disposition à un emplacement bien défini. L'emplacement 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.