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 certificats

Certificate Authority Service fournit des modèles réutilisables et paramétrés que vous pouvez utiliser pour les scénarios d'émission de certificats courants. 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. Expression CEL (Common Expression Language) évaluée par rapport à l'objet et aux SAN demandés dans toutes les requêtes de certificat qui utilisent le modèle. Pour en savoir plus sur l'utilisation du langage CEL, consultez Utiliser le langage CEL.
2. Une liste d'autorisation indiquant si l'objet ou l'autre nom de l'objet peut être copié de la requête de l'utilisateur final vers le certificat émis.
3. Une liste d'autorisation facultative spécifiant les extensions X.509, le cas échéant, qui peuvent être copiées à partir de la requête de l'utilisateur final vers le certificat émis.
4. Ensemble facultatif de valeurs d'extension X.509 ajoutées à tous les certificats émis qui utilisent le modèle.

Un modèle de certificat peut essentiellement devenir un framework d'émission de certificats vertical à part entière. 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 le mTLS ou la signature de code. Les valeurs possibles sont les suivantes:

• Utilisations de clé: spécifie l'utilisation de base de la clé pour un certificat conformément à la section 4.2.1.12 de la RFC 5280.
• Utilisations de clé étendues: spécifie les utilisations de clé étendues d'un certificat conformément à la section 4.2.1.3 de la 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é de fin.
• Longueur maximale du chemin d'accès de l'émetteur: dans le cas d'une autorité de certification, ce paramètre spécifie le nombre maximal d'autorités de certification pouvant être associées à ce certificat d'autorité de certification. Si la longueur maximale du chemin d'accès de l'émetteur est définie sur 0, l'autorité de certification ne peut émettre que des certificats d'entité de fin. Si elle est définie sur 1, la chaîne sous ce certificat d'autorité de certification 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 sous cette autorité de certification est illimité.
• Serveurs OCSP AIA: fait référence aux serveurs OCSP de l'extension AIA (Authority Information Access) d'un certificat, comme décrit dans la section 4.2.2.1 de la 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 d'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 de l'extension caOptions

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

• Champ isCa de l'extension caOptions

Créer un modèle de certificat

Pour créer un modèle de certificat, exécutez 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'indicateur --copy-sans permet de copier l'extension de nom d'objet de remplacement (SAN) de la demande de certificat dans le certificat signé. Vous pouvez également spécifier --no-copy-sans pour supprimer les SAN spécifiés par l'appelant de la demande de certificat.

L'indicateur --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 la réflexion d'identité, 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'indicateur --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 savoir comment utiliser une expression en langage CEL (Common Expression Language) pour un modèle de certificat, consultez Utiliser le langage CEL pour les modèles de certificats.

L'indicateur --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 modifiez une partie des valeurs X.509 prédéfinies, la mise à jour remplace l'ensemble des valeurs X.509 prédéfinies.

Si l'indicateur --copy-all-requested-extensions est défini, 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 :L'indicateur --copy-all-requested-extensions de la balise est mutuellement exclusif des indicateurs --copy-known-extensions et --copy-extensions-by-oid.

Supprimez l'indicateur --copy-all-requested-extensions pour ignorer toutes les extensions X.509 dans 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 et des modèles de certificat, vous ne pourrez pas créer de ressource de ce type portant le même nom dans le même projet et au même emplacement.

Créer un modèle de certificat pour des 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 n'importe quel domaine

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é finale suivante:

   leaf_server_tls_values.yaml

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

2. Pour n'autoriser que 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 gcloud privateca templates create.

Certificats TLS du serveur DNS avec des domaines de test uniquement

Pour créer un modèle de certificat permettant d'émettre des certificats TLS de serveur avec des SAN DNS 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-y la configuration TLS mutuelle d'entité finale suivante.

   leaf_mtls_values.yaml

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

2. Pour n'autoriser que les certificats avec des SAN URI SPIFFE, exécutez 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 spécifique, 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 du modèle de certificat du service CA (roles/privateca.templateUser). Nous recommandons aux auteurs d'un modèle de certificat d'accorder le rôle "Utilisateur du modèle de certificat du service CA" aux membres de l'organisation susceptibles d'utiliser ce modèle de certificat.

Pour attribuer le rôle "Utilisateur du 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 certificats