Créer un modèle de certificat

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

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 des 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 à 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 CEL, consultez Utiliser CEL.
2. Liste d'autorisation spécifiant si l'objet ou l'autre nom d'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 qui, le cas échéant, peuvent être copiées 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 véritable framework d'émission de certificats verticaux à 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 utilisent ce modèle. Ils permettent de créer des scénarios courants d'émission de certificats, tels que mTLS ou la signature de code. Les valeurs sont les suivantes:

• Key usages (Utilisations de 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 des clés: spécifie l'utilisation étendue des clés 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 d'accès de l'émetteur: dans le cas d'une autorité de certification, il spécifie le nombre maximal d'autorités de certification pouvant être associées à 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é finale. S'il est défini sur 1, 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 en dessous de cette autorité de certification est illimité.
• Serveurs OCSP AIA: fait référence aux serveurs OCSP dans l'extension 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 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 non spécifiées dans le fichier YAML sont soit omises, soit définies par défaut sur false.

Si aucune valeur n'est spécifiée, les extensions suivantes sont omises:

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

Si aucune valeur n'est spécifiée, les extensions suivantes sont définies par défaut sur false:

• Champ isCa dans 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 décrivant 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 de la demande de certificat tous les objets spécifiés par l'appelant.

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

L'option --identity-cel-expression utilise une expression CEL qui est évaluée par rapport à l'objet et au nom alternatif de l'objet du certificat avant son émission, et renvoie une valeur booléenne indiquant si la requête doit être autorisée. Pour plus d'informations 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 sont prioritaires sur les extensions autorisées dans la demande de certificat. Si vous modifiez une partie des valeurs X.509 prédéfinies, la modification 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 les 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 ou aia-ocsp-servers.

Remarque :L'option de balise --copy-all-requested-extensions s'exclut mutuellement des options --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 le même emplacement.

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

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

Certificats TLS du serveur DNS pour tous les domaines

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

1. Créez un fichier nommé leaf_server_tls_values.yaml et ajoutez-y la configuration TLS du serveur d'entités de fin 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 gcloud privatecamodels create.

Certificats TLS du serveur DNS avec uniquement des domaines de test

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, utilisez 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 des expressions CEL pour garantir que les noms DNS commencent ou se terminent par une chaîne particulière, consultez les exemples d'expressions CEL.

Certificats Workload Identity

Pour créer un modèle de certificat afin 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 autoriser uniquement les certificats avec des URI SAN 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 la page gcloud privatecamodels create.

Pour en savoir plus sur l'utilisation des expressions CEL pour garantir que les noms DNS commencent ou se terminent par une chaîne particulière, consultez les 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 d'autorité de certification aux membres de l'organisation susceptibles d'utiliser ce modèle de certificat.

Pour accorder le rôle roles/privateca.templateUser (Utilisateur du modèle de certificat du service CA) à 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 la section gcloud privateca templates add-iam-policy-binding.

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

Étapes suivantes

• Apprenez-en plus sur Common Expression Language.
• Découvrez comment utiliser le langage courant d'expression.
• En savoir plus sur les profils de certificat