Créer un modèle de certificat
Cette page décrit les attributs d'un modèle de certificat et explique comment créer un modèle de certificat. Pour en savoir plus sur les modèles de certificat, consultez À propos des modèles de certificat.
Rôles requis
Pour obtenir les autorisations nécessaires pour créer un modèle de certificat, demandez à votre administrateur de vous attribuer le rôle IAM Responsable des opérations du service d'autorité de certification (roles/privateca.caManager
) sur le projet, le dossier ou l'organisation.
Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.
Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.
Créer un modèle de certificat
Pour créer un modèle de certificat, utilisez l'une des méthodes suivantes :
Console
Accédez à la page Certificate Authority Service dans la console Google Cloud .
Cliquez sur l'onglet Gestionnaire de modèles, puis sur Créer un modèle.
Sélectionnez un emplacement pour le modèle de certificat à l'aide de la liste Région. Il doit s'agir du même emplacement que celui du pool d'AC que vous prévoyez d'utiliser avec le modèle de certificat.
Saisissez un identifiant unique pour le modèle de certificat dans le champ ID du modèle de certificat. Si vous le souhaitez, fournissez une description du modèle de certificat.
Cliquez sur Suivant.
Si vous souhaitez configurer des valeurs x.509 par défaut pour les certificats qui utilisent ce modèle, cliquez sur le bouton à bascule Inclure les valeurs prédéfinies dans les certificats émis à l'aide de ce modèle de certificat. Cliquez ensuite sur Configurer des valeurs prédéfinies.
Configurez les valeurs prédéfinies à l'aide des informations suivantes :
Définir l'utilisation de base des clés
Ce paramètre fait référence au champ
Key Usage
d'un certificat numérique. Elle spécifie comment la clé privée du certificat peut être utilisée, par exemple pour le chiffrement de clé, le chiffrement de données, la signature de certificat et la signature de LCR. Pour en savoir plus, consultez Utilisation des clés.- Pour sélectionner les utilisations de base des clés, cliquez sur le bouton Spécifier l'utilisation de base des clés pour les certificats émis à partir de ce pool de CA, puis sélectionnez l'une des options listées.
- Cliquez sur Suivant.
Définir l'utilisation étendue de la clé
Ce paramètre fait référence au champ
Extended Key Usage (EKU)
d'un certificat numérique. Il fournit des restrictions plus spécifiques et plus précises sur la façon dont la clé peut être utilisée, par exemple pour l'authentification du serveur, l'authentification du client, la signature de code, la protection des e-mails, etc. Pour en savoir plus, consultez Utilisation étendue des clés.Les utilisations étendues des clés sont définies à l'aide d'identifiants d'objet (OID). Si vous ne configurez pas les utilisations étendues des clés, tous les scénarios d'utilisation des clés sont autorisés.
- Pour sélectionner les utilisations étendues des clés, cliquez sur le bouton Écrire les utilisations étendues des clés pour les certificats émis à partir de ce pool de CA, puis sélectionnez les options de votre choix.
- Cliquez sur Suivant.
Définir des identifiants de règle
L'extension des règles de certificat dans le certificat exprime les règles suivies par le pool d'autorités de certification émetteur. Cette extension peut inclure des informations sur la façon dont les identités sont validées avant l'émission des certificats, sur la façon dont les certificats sont révoqués et sur la façon dont l'intégrité du pool d'autorités de certification est assurée. Cette extension vous aide à valider les certificats émis par le pool d'autorités de certification et à voir comment ils sont utilisés.
Pour en savoir plus, consultez Règles relatives aux certificats.
Pour spécifier la règle qui définit l'utilisation du certificat, procédez comme suit :
- Facultatif : Ajoutez l'identifiant de la règle dans le champ Identifiants de règles.
- Cliquez sur Suivant.
Ajouter des serveurs OCSP (Online Certificate Status Protocol) pour l'extension AIA (Authority Information Access)
L'extension AIA d'un certificat fournit les informations suivantes :
- Adresse des serveurs OCSP à partir desquels vous pouvez vérifier l'état de révocation du certificat.
- Méthode d'accès pour l'émetteur du certificat.
Pour en savoir plus, consultez Authority Information Access.
L'ajout de serveurs OCSP est facultatif. Pour ajouter les serveurs OCSP qui apparaissent dans le champ d'extension AIA des certificats, procédez comme suit :
- Cliquez sur Ajouter un élément.
- Dans le champ URL du serveur, ajoutez l'URL du serveur OCSP.
- Cliquez sur OK.
- Cliquez sur Suivant.
Options de l'autorité de certification
Le champ Options d'autorité de certification d'un modèle de certificat définit la manière dont le certificat obtenu peut être utilisé dans une hiérarchie d'autorité de certification. Il détermine essentiellement si un certificat peut être utilisé pour signer d'autres certificats et, le cas échéant, les restrictions applicables aux certificats qu'il émet.
parmi les options suivantes :
Incluez les configurations pour décrire les extensions CA X.509 : spécifiez les paramètres d'un modèle de certificat qui contrôlent les extensions X.509.
Limitez l'utilisation des certificats émis aux autorités de certification : cette option n'apparaît que si vous cochez la case mentionnée à l'étape précédente. Cette valeur booléenne indique si le certificat est un certificat CA. Si la valeur est définie sur
true
, le certificat peut être utilisé pour signer d'autres certificats. Si la valeur estfalse
, il s'agit d'un certificat d'entité de fin qui ne peut pas signer d'autres certificats. Si vous cliquez sur ce bouton bascule, vous êtes invité à définir des contraintes de nom pour l'extension des certificats CA.Incluez les configurations pour décrire la restriction de longueur du chemin des extensions X.509 : Spécifiez les paramètres qui contrôlent la longueur d'une chaîne de certificats à partir d'un certificat particulier.Ils indiquent le nombre maximal d'AC pouvant être chaînées à ce certificat d'AC. 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 la valeur est définie sur1
, la chaîne sous ce certificat CA ne peut inclure qu'une seule CA subordonnée. Si aucune valeur n'est déclarée, le nombre d'AC subordonnées dans la chaîne sous cette AC est illimité.- Cliquez sur Suivant.
Configurer des extensions supplémentaires
Facultatif : Vous pouvez configurer des extensions personnalisées supplémentaires à inclure dans les certificats émis par le pool d'autorités de certification. Procédez comme suit :
- Cliquez sur Ajouter un élément.
- Dans le champ Identifiant d'objet, ajoutez un identifiant d'objet valide au format numérique séparé par des points.
- Dans le champ Valeur, ajoutez la valeur encodée en base64 pour l'identifiant.
- Si l'extension est essentielle, sélectionnez L'extension est essentielle.
Pour enregistrer toutes les valeurs prédéfinies, cliquez sur OK.
Ensuite, accédez à la section Configurer les contraintes d'extension. Sélectionnez l'une des options suivantes :
- Copier toutes les extensions des demandes de certificat dans le certificat
- Supprimer toutes les extensions des demandes de certificat
- Copier des extensions spécifiques des demandes de certificat dans le certificat
- Si vous choisissez de copier des extensions spécifiques, vous pouvez effectuer les opérations suivantes :
- Cliquez sur le champ Extensions de certificat connues, puis décochez les extensions inutiles dans la liste.
- Dans le champ Extensions personnalisées, ajoutez les identifiants d'objet des extensions que vous souhaitez inclure dans les certificats émis par le pool d'autorités de certification.
Cliquez sur Suivant, puis accédez à la section Configurer les contraintes d'identité. Pour configurer des contraintes sur le sujet et les SAN dans les certificats émis par le pool d'autorités de certification, sélectionnez une ou plusieurs des options suivantes :
- Copier l'objet des demandes dans le certificat
- Copier les autres noms d'objet (SAN, subject alternative names) des demandes de certificat dans le certificat
Cliquez sur Suivant, puis sur OK.
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 SAN (Subject Alternative Name) 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 tous les sujets spécifiés par l'appelant de la demande de certificat.
L'indicateur --identity-cel-expression
accepte 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 demande doit être autorisée. Pour savoir comment utiliser une expression CEL (Common Expression Language) pour un modèle de certificat, consultez Utiliser CEL pour les modèles de certificat.
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. Elles ont priorité sur toutes 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é.
Si l'indicateur --copy-extensions-by-oid
est défini, des OID spécifiques sont copiés de la demande de certificat dans le certificat signé.
Si l'indicateur --copy-known-extensions
est défini, des extensions spécifiques sont copiées de la demande de certificat dans le certificat signé. Ces extensions connues peuvent être les suivantes : base-key-usage
, extended-key-usage
, ca-options
, policy-ids
ou aia-ocsp-servers
.
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.
Voici un exemple de configuration de 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 omises ou définies par défaut sur false
.
Les extensions suivantes sont omises si aucune valeur n'est spécifiée :
keyUsage
policyIds
additionalExtensions
- Champ
maxIssuerPathLength
dans l'extensioncaOptions
Les extensions suivantes sont définies sur false
par défaut si aucune valeur n'est spécifiée :
- Champ
isCa
dans l'extensioncaOptions
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 les 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 :
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
Pour n'autoriser que les certificats avec des SAN de type
DNS
, exécutez la commandegcloud
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 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 afin de s'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), suivez les instructions ci-dessous :
Créez un fichier nommé
leaf_mtls_values.yaml
et ajoutez-y la configuration TLS mutuelle de l'entité finale suivante.leaf_mtls_values.yaml
keyUsage: baseKeyUsage: digitalSignature: true keyEncipherment: true extendedKeyUsage: serverAuth: true clientAuth: true caOptions: isCa: false
Pour n'autoriser que les certificats avec des SAN URI SPIFFE, utilisez 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 des expressions CEL afin de s'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'attribuer le rôle "Utilisateur du modèle de certificat de CA Service" aux membres de l'organisation susceptibles d'utiliser ce modèle de certificat.
Pour accorder le rôle Utilisateur du modèle de certificat du service CA (roles/privateca.templateUser
) à tous les utilisateurs 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 CA Service et les autorisations associées, consultez Contrôle des accès avec IAM.
Étapes suivantes
- En savoir plus sur le Common Expression Language
- Découvrez comment utiliser Common Expression Language.
- En savoir plus sur les profils de certificat