Créer un modèle de certificat

Cette page décrit les attributs d'un modèle de certificat et explique comment en créer un.

Présentation des modèles de certificat

Certificate Authority Service fournit des modèles réutilisables et paramétrés que vous pouvez utiliser pour les scénarios courants d'émission de certificats. Un modèle de certificat représente un schéma d'émission de certificats relativement statique et bien défini au sein d'une organisation. La ressource CertificateTemplate inclut les éléments suivants :

1. Une expression CEL (Common Expression Language) évaluée par rapport au sujet et aux SAN demandés dans toutes les demandes de certificat qui utilisent le modèle Pour en savoir plus sur l'utilisation du langage CEL, consultez la page Utiliser le langage CEL.
2. Liste d'autorisation indiquant si le nom de l'objet ou de l'autre nom de l'objet peut être copié depuis la requête de l'utilisateur final vers le certificat émis.
3. Liste d'autorisation facultative spécifiant les extensions X.509, le cas échéant, qui peuvent être copiées de la demande de l'utilisateur final vers le certificat émis.
4. Ensemble facultatif de valeurs d'extension X.509 qui sont ajoutées à tous les certificats émis qui utilisent le modèle.

Un modèle de certificat peut essentiellement devenir un cadre à part entière pour l'émission de certificats dans le secteur vertical. Pour en savoir plus, consultez la définition complète du message CertificateTemplate.

Valeurs prédéfinies dans un modèle de certificat

Les valeurs prédéfinies d'un modèle de certificat sont ajoutées à tous les certificats qui l'utilisent. Ils permettent de créer des scénarios d'émission de certificats courants, tels que mTLS ou la signature de code. Les valeurs sont les suivantes:

• Utilisations des clés: spécifie l'utilisation de base des clés pour un certificat, conformément à la section 4.2.1.12 du document RFC 5280.
• Utilisations étendues de clés: spécifie l'utilisation étendue de la clé pour un certificat, conformément à la section 4.2.1.3 du document RFC 5280.
• Si le certificat est une autorité de certification: indique si le certificat peut émettre des certificats supplémentaires ou s'il s'agit d'un certificat d'entité finale.
• Longueur maximale du chemin de l'émetteur: dans le cas d'une autorité de certification, cette option permet de spécifier le nombre maximal d'autorités de certification pouvant être enchaînées jusqu'à ce certificat CA. Si la longueur maximale du chemin de l'émetteur est définie sur 0, l'autorité de certification ne peut émettre que des certificats d'entité de fin. Si la valeur est définie sur 1, alors la chaîne située sous ce certificat CA ne peut inclure qu'une seule autorité de certification subordonnée. Si aucune valeur n'est déclarée, le nombre d'autorités de certification subordonnées dans la chaîne située sous cette autorité de certification est illimité.
• Serveurs OCSP AIA: fait référence aux serveurs OCSP dans l'extension d'accès aux informations d'autorité (AIA, Authority Information Access) d'un certificat, comme décrit dans la section 4.2.2.1 du document RFC 5280.
• Extensions X.509 supplémentaires: décrit les extensions X.509 personnalisées.

L'exemple de code suivant mentionne tous les champs prédéfinis dans un modèle de certificat:

keyUsage:
  baseKeyUsage:
    digitalSignature: true
    keyEncipherment: true
    contentCommitment: false
    dataEncipherment: false
    keyAgreement: false
    certSign: false
    crlSign: false
    encipherOnly: false
    decipherOnly: false
  extendedKeyUsage:
    serverAuth: true
    clientAuth: false
    codeSigning: false
    emailProtection: false
    timeStamping: false
    ocspSigning: false
caOptions:
  isCa: true
  maxIssuerPathLength: 1
policyIds:
- objectIdPath:
  - 1
  - 2
  - 3
additionalExtensions:
- objectId:
    objectIdPath:
    - 1
    - 2
    - 3
  critical: false
  value: "base64 encoded extension value"

Les valeurs qui ne sont pas spécifiées dans le fichier YAML sont omises ou remplacées par la valeur par défaut false.

Les extensions suivantes sont omises si aucune valeur n'est spécifiée:

• keyUsage
• policyIds
• additionalExtensions
• Champ maxIssuerPathLength dans l'extension caOptions

Les extensions suivantes sont définies par défaut sur false si aucune valeur n'est spécifiée:

• Champ isCa dans l'extension caOptions

Créer un modèle de certificat

Pour créer un modèle de certificat, utilisez la commande gcloud suivante:

gcloud

gcloud privateca templates create TEMPLATE_ID \
  --copy-subject \
  --copy-sans \
  --identity-cel-expression <expr> \
  --predefined-values-file FILE_PATH \
  --copy-all-requested-extensions \
  --copy-extensions-by-oid <1.2.3.4,5.6.7.8> \
  --copy-known-extensions <ext1,ext2>

Remplacez les éléments suivants :

• TEMPLATE_ID: identifiant unique du modèle de certificat.
• FILE_PATH: fichier YAML qui décrit les valeurs X.509 définies par le modèle de certificat.

L'option --copy-sans permet de copier l'extension SAN (Subject Alternative Name) de la demande de certificat dans le certificat signé. Vous pouvez également spécifier --no-copy-sans pour supprimer de la demande de certificat tous les SAN spécifiés par l'appelant.

L'option --copy-subject permet de copier l'objet de la demande de certificat dans le certificat signé. Vous pouvez également spécifier --no-copy-subject pour supprimer les sujets spécifiés par l'appelant de la demande de certificat.

Remarque :Si vous souhaitez vous assurer qu'un modèle doit être utilisé avec les clés de réflexion, spécifiez les options --no-copy-subject et --no-copy-sans ensemble. Pour en savoir plus sur la réflexion d'identité, consultez la section Réflexion d'identité.

L'option --identity-cel-expression utilise une expression CEL qui est évaluée par rapport à l'objet et à l'autre nom de l'objet du certificat avant son émission, et renvoie une valeur booléenne indiquant si la requête doit être autorisée. Pour en savoir plus sur l'utilisation d'une expression CEL (Common Expression Language) pour un modèle de certificat, consultez Utiliser CEL pour les modèles de certificat.

L'option --predefined-values-file spécifie le chemin d'accès à un fichier YAML décrivant les valeurs X.509 prédéfinies définies par ce modèle. Les extensions fournies sont copiées dans toutes les demandes de certificat qui utilisent ce modèle et ont la priorité sur les extensions autorisées dans la demande de certificat. Si vous mettez à jour une partie des valeurs X.509 prédéfinies, la mise à jour remplace l'ensemble des valeurs X.509 prédéfinies.

Si l'option --copy-all-requested-extensions est définie, toutes les extensions spécifiées dans la demande de certificat sont copiées dans le certificat signé. Vous pouvez également utiliser l'indicateur --copy-extensions-by-oid pour copier des OID spécifiques de la demande de certificat dans le certificat signé, et l'indicateur --copy-known-extensions pour copier des extensions de la demande de certificat dans le certificat signé. Doit être l'un des suivants : base-key-usage, extended-key-usage, ca-options, policy-ids, aia-ocsp-servers.

Remarque :Les options de tag --copy-all-requested-extensions s'excluent mutuellement des options --copy-known-extensions et --copy-extensions-by-oid.

Supprimez l'option --copy-all-requested-extensions pour ignorer toutes les extensions X.509 de la demande de certificat, tout en conservant les valeurs prédéfinies définies dans ce modèle.

Remarque :Si vous supprimez des ressources telles que des pools d'autorités de certification, des autorités de certification modèles de certificat, vous ne pourrez pas créer de ressource ayant le même nom dans le même projet et le même emplacement.

Créer un modèle de certificat pour les scénarios courants

Cette section fournit des commandes gcloud pour créer un modèle de certificat pour des cas d'utilisation courants.

Certificats TLS du serveur DNS pour tous les domaines

Pour créer un modèle de certificat permettant d'émettre des certificats TLS de serveur autorisant n'importe quel domaine, suivez les instructions ci-dessous :

1. Créez un fichier nommé leaf_server_tls_values.yaml et ajoutez-y la configuration TLS du serveur d'entités finales suivante:

   leaf_server_tls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
   caOptions:
     isCa: false
   

2. Pour autoriser uniquement les certificats avec des SAN de type DNS, exécutez la commande gcloud suivante:

   gcloud

   gcloud privateca templates create server-tls \
     --predefined-values-file leaf_server_tls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == DNS)"
   

   Pour en savoir plus sur la commande gcloud privateca templates create, consultez la page sur la commande gcloud privatecatemplates create.

Certificats TLS du serveur DNS avec uniquement des domaines de test

Pour créer un modèle de certificat afin d'émettre des certificats TLS de serveur avec DNS Pour les SAN limités aux domaines de test, exécutez la commande gcloud suivante:

gcloud

gcloud privateca templates create server-tls \
  --predefined-values-file leaf_server_tls_values.yaml \
  --copy-sans --no-copy-subject \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"

Le contenu du fichier leaf_server_tls_values.yaml doit être identique à celui de l'exemple précédent.

Pour en savoir plus sur l'utilisation d'expressions CEL pour vous assurer que les noms DNS commencent ou se terminent par une chaîne spécifique, consultez Exemples d'expressions CEL.

Certificats d'identité de charge de travail

Pour créer un modèle de certificat permettant d'émettre des certificats TLS mutuels (mTLS), procédez comme suit :

1. Créez un fichier nommé leaf_mtls_values.yaml et ajoutez ce qui suit : une configuration TLS mutuelle d'entité de fin.

   leaf_mtls_values.yaml

   keyUsage:
     baseKeyUsage:
       digitalSignature: true
       keyEncipherment: true
     extendedKeyUsage:
       serverAuth: true
       clientAuth: true
   caOptions:
     isCa: false
   

2. Pour autoriser uniquement les certificats avec des URI SAN SPIFFE, utilisez le paramètre la commande gcloud suivante:

   gcloud

   gcloud privateca templates create workload-spiffe \
     --predefined-values-file leaf_mtls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == URI && san.value.startsWith('spiffe://'))"
   

   Pour en savoir plus sur la commande gcloud privateca templates create, consultez gcloud privateca templates create.

Pour en savoir plus sur l'utilisation d'expressions CEL pour vous assurer que les noms DNS commencent ou se terminent par une chaîne particulière, consultez Exemples d'expressions CEL.

Accorder l'accès au modèle de certificat

Vous pouvez utiliser un modèle de certificat si vous disposez du rôle Utilisateur de modèle de certificat du service CA (roles/privateca.templateUser). Nous recommandons aux auteurs d'un modèle de certificat d'attribuer le rôle Utilisateur de modèle de certificat du service CA aux membres de l'organisation susceptibles d'utiliser ce modèle de certificat.

Pour accorder le rôle Utilisateur de modèle de certificat du service CA (roles/privateca.templateUser) à tous les membres du domaine example.com, utilisez la commande gcloud suivante:

gcloud

gcloud privateca templates add-iam-policy-binding TEMPLATE_ID \
  --member "domain:example.com" \
  --role "roles/privateca.templateUser"

Remplacez les éléments suivants :

• TEMPLATE_ID: identifiant unique du modèle de certificat.

Pour en savoir plus sur la commande gcloud privateca templates add-iam-policy-binding, consultez gcloud privateca templates add-iam-policy-binding.

Pour en savoir plus sur les rôles IAM pour le service CA et les autorisations associées, consultez la page Contrôle des accès avec IAM.

Étape suivante

• En savoir plus sur le Common Expression Language
• Découvrez comment utiliser Common Expression Language.
• En savoir plus sur les profils de certificat