Questions fréquentes

Qu'est-ce que Certificate Authority Service ?

Certificate Authority Service est un service Google Cloud disponibilité élevée et évolutif qui permet aux clients de simplifier, d'automatiser et de personnaliser le déploiement, la gestion et la sécurité des autorités de certification privées tout en gardant le contrôle de leurs clés privées.

Quels sont les cas d'utilisation courants du service d'autorité de certification ?

Vous trouverez ci-dessous quelques cas d'utilisation courants de Certificate Authority Service.

  • Identités de charge de travail: utilisez les API pour obtenir des certificats pour vos applications, ou pour utiliser des certificats dans des applications, des conteneurs, des systèmes et d'autres ressources.
  • Scénarios destinés aux entreprises: utilisez des certificats pour le VPN, Chrome Enterprise Premium, la signature de documents, l'accès au Wi-Fi, la messagerie, les cartes à puce, etc.
  • Émission et gestion centralisées des certificats: configurez GKE Enterprise Service Mesh pour utiliser CA Service.
  • Identité des appareils IoT et mobiles : émettez des certificats TLS en tant qu'identité pour les points de terminaison.
  • le canal CI/CD, l'autorisation binaire, Istio et Kubernetes.

Quelles normes de conformité sont acceptées par CA Service ?

Pour en savoir plus, consultez Sécurité et conformité.

Dans quels emplacements pouvons-nous créer des ressources du service d'autorité de certification ?

Les ressources du service CA peuvent être créées dans l'un des nombreux emplacements. Pour obtenir la liste complète des emplacements, consultez Emplacements.

Le service CA est-il compatible avec une PKI globale sous une seule racine ?

Oui, à condition que l'autorité de certification racine réside dans une seule région. Toutefois, vous pouvez créer plusieurs autorités de certification émettrices dans différentes régions qui se rattachent à la même racine.

Les étiquettes sont-elles compatibles avec les autorités de certification ?

Oui, vous pouvez associer des étiquettes aux pools d'autorités de certification et aux autorités de certification lors des opérations de création et de mise à jour.

Pour en savoir plus sur la mise à jour des étiquettes sur un pool d'autorités de certification, consultez la section Mettre à jour les étiquettes d'un pool d'autorités de certification.

Pour en savoir plus sur la mise à jour des étiquettes sur une autorité de certification, consultez Mettre à jour les étiquettes sur une autorité de certification.

Est-il possible d'utiliser Cloud Monitoring pour suivre la création et l'expiration des certificats ? Est-il possible de générer des événements Pub/Sub pour eux ?

Oui, vous pouvez surveiller tous ces événements. Le service CA n'est pas compatible nativement avec Pub/Sub, mais vous pouvez le configurer à l'aide de Cloud Monitoring. Pour en savoir plus, consultez Utiliser la surveillance cloud avec le service CA.

Combien de temps les autorités de certification non activées sont-elles conservées ?

Les autorités de certification subordonnées sont créées à l'état AWAITING_USER_ACTIVATION et sont définies sur l'état STAGED après activation. Si une autorité de certification subordonnée est toujours à l'état AWAITING_USER_ACTIVATION 30 jours après sa création, elle est supprimée.

Pour en savoir plus sur les différents états d'une autorité de certification au cours de son cycle de vie, consultez la section États des autorités de certification.

Quels contrôles d'accès le service CA prend-il en charge pour l'émission de certificats ?

Le service CA prend en charge la définition de stratégies IAM sur un pool d'autorités de certification afin de contrôler qui peut émettre des certificats. Un administrateur d'autorités de certification peut associer une stratégie d'émission à un pool d'autorités de certification. Cette règle d'émission définit des restrictions sur le type de certificats que les autorités de certification d'un pool d'autorités de certification peuvent émettre. Ces restrictions incluent, entre autres, la limitation du nom de domaine, des extensions et de la période de validité des certificats.

Pour en savoir plus sur la configuration d'une stratégie d'émission sur un pool d'autorités de certification, consultez Utiliser une stratégie d'émission.

Pour savoir comment configurer les stratégies IAM nécessaires à la création et à la gestion des ressources du service de certification, consultez la section Configurer des stratégies IAM.

Le service CA accepte-t-il les clés Cloud KMS multirégionales ?

Non. CA Service n'est pas compatible avec les clés Cloud KMS multirégionales.

CA Service régulera-t-il mes requêtes ? Quels sont les RPS cibles pour le service CA ?

Oui, il existe un mécanisme de limitation pour le service CA. Pour en savoir plus, consultez la page Quotas et limites.

Le service CA est-il compatible avec VPC Service Controls ?

Oui, le service CA est compatible avec VPC Service Controls. Pour en savoir plus, consultez la section Produits compatibles et limites > Certificate Authority Service et Sécurité et conformité.

Comment les clés publiques encodées au format PEM sont-elles censées être utilisées avec les API REST ?

Les clés publiques encodées au format PEM ne peuvent être utilisées avec les API REST qu'après avoir été encodées en base64.

Est-il toujours possible d'utiliser les API de l'étape d'aperçu après que CA Service a annoncé la disponibilité générale (DG) ?

Oui, les API en version preview peuvent toujours être utilisées pendant une courte période après l'annonce de la disponibilité générale du service CA. Cette période n'est destinée qu'à permettre aux clients de passer facilement aux dernières API. Elle sera de courte durée et l'assistance sera limitée. Nous recommandons aux clients de migrer vers les API GA dès qu'elles sont disponibles.

Comment accéder aux ressources créées pendant la période preview une fois que CA Service a annoncé la disponibilité générale (DG) ?

Vous ne pouvez pas afficher ni gérer les ressources créées pendant la période de preview à l'aide de la console Google Cloud. Pour gérer les ressources créées pendant la phase preview, utilisez les API Preview ou les commandes gcloud preview. Les API en preview sont accessibles via le point de terminaison https://privateca.googleapis.com/v1beta1/. Les commandes d'aperçu gcloud sont accessibles via gcloud privateca beta. Pour en savoir plus sur les commandes gcloud privateca beta, consultez la page sur gcloud privateca beta.

Une AC subordonnée peut-elle être créée avec le même objet et la même clé qu'une autre AC de sa chaîne ?

Non, une AC subordonnée ne peut pas avoir le même objet et la même clé que l'AC racine ou toute autre AC de sa chaîne. Le document RFC 4158 recommande de ne pas répéter les noms de sujet et les paires de clés publiques dans les chemins.

Les clés Cloud KMS gérées par le client sont-elles identiques aux clés CMEK ?

Non, le service Cloud KMS Cloud KMS clés prises en charge dans Certificate Authority Service ne sont pas les mêmes que les clés de chiffrement gérées par le client (CMEK) gérés à l'aide de Cloud KMS. Dans CA Service, vous pouvez créer vos propres clés Cloud KMS gérées par le client (également appelées clés BYO) pour les autorités de certification de niveau Enterprise. Ces clés sont utilisées comme clé de signature de l'autorité de certification, contrairement aux clés de chiffrement telles que la CSEK, qui sont utilisées pour chiffrer les données au repos dans les services Google Cloud compatibles. Le service CA n'est pas compatible avec les CMEK.

Les noms de ressources peuvent-ils être réutilisés après la suppression ?

Non. Les noms de ressources tels que les noms des pools d'autorités de certification, des autorités de certification et des modèles de certificat ne peuvent pas être réutilisés dans une nouvelle ressource après la ressource d'origine. est supprimé. Par exemple, si vous créez un pool d'autorités de certification appelé projects/Charlie/locations/Location-1/caPools/my-pool, puis supprimez l'autorité de certification vous ne pouvez pas créer un autre pool d'autorités de certification appelé my-pool dans le projet Charlie et l'emplacement Location-1.

Étape suivante