Ajouter une stratégie d'émission de certificats à un pool d'autorités de certification

Cette page explique comment ajouter une règle d'émission de certificats à un pool d'autorités de certification (CA).

Une stratégie d'émission de certificats vous permet de spécifier l'objet et l'objet noms alternatifs (SAN) pouvant être inclus dans les certificats émis. Vous pouvez spécifier la stratégie d'émission de certificats lors de la création d'un pool d'autorités de certification ou vous pouvez un pool d'autorités de certification existant pour ajouter une stratégie d'émission.

Pour en savoir plus, consultez Présentation des modèles et des règles d'émission.

Attention :Les modifications apportées à la règle d'émission prennent effet immédiatement. Avant d'utiliser la stratégie d'émission en production, nous vous recommandons de tester les modifications de stratégie sur une instance de pool de certificats de test.

Avant de commencer

• Assurez-vous de disposer du rôle CA Service Operation Manager (roles/privateca.caManager) ou l'administrateur du service CA (roles/privateca.admin) rôle IAM. Pour en savoir plus sur pour accorder un rôle IAM à un compte principal, consultez Attribuer rôle.

• Créez un pool d'autorités de certification.

Ajouter un fichier de stratégie d'émission de certificats

Pour ajouter une stratégie d'émission de certificats à un pool d'autorités de certification existant, procédez comme suit:

Console

1. Accédez à la page Certificate Authority Service (Service d'autorité de certification) dans la console Google Cloud.

   Accéder à Certificate Authority Service

2. Sur la page Gestionnaire de pool d'autorités de certification, cliquez sur le nom du pool d'autorités de certification pour lequel souhaitez ajouter une stratégie d'émission de certificats.

3. Sur la page Pool de CA, cliquez sur Modifier.

Configurer les valeurs de référence

Pour configurer des valeurs de référence dans les certificats émis à partir du pool d'autorités de certification, procédez comme suit : les éléments suivants:

1. Cliquez sur le bouton d'activation.
2. Cliquez sur Configurer les valeurs de référence.

Définir l'utilisation de base des clés

Vous pouvez utiliser ce paramètre pour configurer la façon dont la clé contenue dans le certificat peut être utilisé. Les options d'utilisation des clés incluent le chiffrement, le chiffrement des données, la signature des certificats, la signature CRL, etc.

Pour en savoir plus, consultez la section Utilisation des clés.

Pour définir l'utilisation de base des clés, procédez comme suit:

1. Facultatif: Dans la fenêtre qui s'affiche, cliquez sur le bouton d'activation, si vous souhaitez spécifier l'utilisation de base des clés pour les certificats.
2. Cochez les cases correspondant aux modes d'utilisation de la clé.

3. Cliquez sur Suivant.

Définir l'utilisation étendue de la clé

Ce paramètre vous permet de sélectionner des scénarios plus précis pour lesquels la clé contenus dans le certificat peuvent être utilisés. Les options incluent l'authentification du serveur, l'authentification du client, la signature de code, la protection des e-mails, etc.

Les utilisations étendues de clés sont définies à l'aide d'identifiants d'objets (OID). Si vous ne configurer les utilisations étendues des clés, tous les scénarios d'utilisation des clés sont autorisés.

Pour en savoir plus, consultez la section Utilisation étendue des clés.

Pour définir les utilisations étendues des clés, procédez comme suit:

1. Facultatif: Pour spécifier les utilisations étendues des clés pour les certificats que le les problèmes liés au pool d'autorités de certification, cliquez sur le bouton d'activation.
2. Cochez les cases correspondant aux scénarios d'utilisation étendue des clés.
3. Cliquez sur Suivant.

Définir des identifiants de stratégie

L'extension des stratégies de certificat dans le certificat exprime les stratégies suivi par le pool d'autorités de certification émettrices. Cette extension peut inclure des informations les identités sont validées avant l'émission des certificats, comment les certificats sont et comment l'intégrité du pool d'autorités de certification est garantie. Cette extension vous aide vérifier les certificats émis par le pool d'autorités de certification et voir comment sont utilisés.

Pour en savoir plus, consultez la section Stratégies relatives aux certificats.

Pour spécifier la stratégie qui définit l'utilisation du certificat, procédez comme suit:

1. Facultatif : ajoutez l'identifiant de la règle dans le champ Identifiants de règle.
2. Cliquez sur Suivant.

Ajouter des serveurs OCSP (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 de l'émetteur du certificat.

Pour en savoir plus, consultez la section Accès aux informations des autorités.

Pour ajouter les serveurs OCSP qui apparaissent dans le champ d'extension AIA du des certificats : La procédure suivante est facultative.

1. Facultatif: Cliquez sur Ajouter un élément.
2. Dans le champ URL du serveur, ajoutez l'URL du serveur OCSP.
3. Cliquez sur OK.
4. Cliquez sur Suivant.

Configurer des extensions supplémentaires

Pour configurer des extensions personnalisées supplémentaires à inclure dans de certificats émis par le pool d'autorités de certification, procédez comme suit : La procédure suivante est facultative.

1. Cliquez sur Ajouter un élément.
2. Dans le champ Identifiant d'objet, ajoutez un identifiant d'objet valide qui se présente sous la forme de chiffres séparés par un point.
3. Dans le champ Valeur, ajoutez la valeur encodée en base64 pour l'identifiant.
4. Si l'extension est essentielle, sélectionnez L'extension est essentielle.

Pour enregistrer toutes les configurations de valeur de référence, cliquez sur OK.

Configurer les contraintes d'extension

Pour interdire l'inclusion de toutes les extensions des demandes de certificat dans les certificats émis, cliquez sur le bouton d'activation.

Après avoir cliqué sur le bouton d'activation, vous verrez s'afficher le bouton Certificat connu extensions que vous pouvez utiliser pour sélectionner les extensions de certificat. À sélectionnez les extensions de certificat, procédez comme suit:

1. Facultatif: Cliquez sur le champ Extensions de certificat connues, puis désélectionnez les extensions non requises dans le menu.
2. (Facultatif) Dans le champ Extensions personnalisées, ajoutez les identifiants d'objets. pour les extensions que vous souhaitez inclure dans les certificats que le pool d'autorités de certification les problèmes de performances.

Configurer des contraintes d'identité

Pour configurer des contraintes sur l'objet et les SAN dans les certificats émis par le pool d'autorités de certification, procédez comme suit :

1. Facultatif: Pour interdire la transmission de l'objet des demandes de certificat cliquez sur le bouton d'activation.
2. Facultatif: Pour interdire les autres noms d'objet dans les demandes de certificat ne sont pas transmises, cliquez sur le bouton d'activation.
3. Facultatif: Ajoutez une expression CEL (Common Expression Language) à placer sur les sujets des certificats. Pour en savoir plus, consultez la section Utiliser le langage CEL.
4. Cliquez sur Suivant.

Pour apprendre à configurer des paramètres supplémentaires dans la stratégie d'émission de certificats, voir IssuancePolicy.

gcloud

Pour ajouter une stratégie d'émission de certificats à un pool d'autorités de certification à l'aide de la Google Cloud CLI, vous devez créer un fichier YAML qui décrit les restrictions appliquées que le pool d'autorités de certification peut émettre. Le contenu correspond à un IssuancePolicy.

1. À l'aide de l'éditeur Cloud Shell, créez un fichier policy.yaml avec la commande les contenus suivants:

   identityConstraints:
     allowSubjectPassthrough: true
     allowSubjectAltNamesPassthrough: true
   

   Où :

   • Le champ allowSubjectPassthrough est obligatoire. Si le champ allowSubjectPassthrough est défini sur true, le champ "Objet" d'une demande de certificat est copié dans le certificat signé. Sinon, l'objet demandé est supprimé.
   • Si le champ allowSubjectAltNamesPassthrough est défini sur true, l'extension SubjectAltNames est copiée à partir d'une demande de certificat dans le certificat signé. Sinon, les SubjectAltNames demandés sont supprimés.

2. Pour mettre à jour la stratégie d'émission de certificats d'un pool d'autorités de certification à l'aide du fichier créé à l'étape précédente, exécutez la commande suivante:

   gcloud privateca pools update POOL_NAME \
     --issuance-policy FILE_PATH
   

   Remplacez les éléments suivants :

   • POOL_NAME: nom du pool d'autorités de certification.
   • FILE_PATH: chemin d'accès au fichier policy.yaml

   Pour en savoir plus sur la commande gcloud privateca pools update, consultez la page gcloud privateca pools update.

Restrictions acceptées

CA Service prend en charge les restrictions suivantes liées à la stratégie d'émission. Toi peut combiner les restrictions suivantes si nécessaire pour créer un certificat personnalisé politique d'émission.

Limiter ou forcer les valeurs X.509 autorisées

Un pool d'autorités de certification peut restreindre les valeurs X.509 autorisées dans les demandes de certificat en configurant le champ passthrough_extensions.

Un pool d'autorités de certification peut également spécifier explicitement des valeurs X.509 à ajouter à tous ses certificats émis, en écrasant les valeurs demandées, à l'aide du champ baseline_values.

Les valeurs baseline_values d'un pool d'autorités de certification permettent de spécifier les propriétés suivantes:

• Utilisation de la clé
• Options d'autorité de certification
• Serveurs OCSP AIA
• Extensions X.509 supplémentaires

Vous pouvez également utiliser ces options ensemble.

Si vous modifiez une partie du champ baseline_values, la modification remplace l'ensemble des valeurs du champ baseline_values.

• Exemple: Limitez une autorité de certification à n'émettre que des certificats d'entité de fin avec des valeurs X.509 pour l'authentification TLS mutuelle (mTLS).

  policy.yaml

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

• Exemple: Limitez une autorité de certification à n'émettre que des certificats de signature de code d'entité de fin avec une URL OCSP AIA de référence.

  policy.yaml

  baselineValues:
    caOptions:
      isCa: false
    keyUsage:
      baseKeyUsage:
        digitalSignature: true
      extendedKeyUsage:
        codeSigning: true
    aiaOcspServers:
      - "http://foo.bar/revocation"
    additionalExtensions:
    - objectId:
        objectIdPath:
          - 1
          - 2
          - 3
      critical: false
      value: "base64 encoded extension value"
  

Pour en savoir plus sur le profil de certificat pour mTLS d'entité finale, consultez mTLS d'entité finale.

Limiter les champs d'identité autorisés

Pour limiter l'identité des certificats émis via un pool d'autorités de certification, vous pouvez ajouter une expression CEL (Common Expression Language) au champ identity_constraints de la règle d'émission. Les expressions CEL permettent des restrictions arbitraires sur le nom de domaine de l'objet (y compris le nom commun) et les SAN d'un certificat.

Pour en savoir plus sur l'utilisation d'une expression CEL pour restreindre l'objet et les SAN, consultez la page Utiliser CEL.

• Exemple : Autorisez l'autorité de certification à émettre uniquement des certificats correspondant à un objet spécifié.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: true
    allowSubjectAltNamesPassthrough: false
    celExpression:
      expression: 'subject.organization == "Example LLC" && subject.country_code in ["US", "UK"]'
  

  Le champ celExpression est facultatif. Utilisez une expression CEL (Common Expression Language) pour valider l'objet X.509 et le SAN résolus avant la signature d'un certificat. Pour en savoir plus sur l'utilisation des expressions CEL, consultez la page Utiliser le langage CEL.

• Exemple: Autorisez uniquement les SAN dont le nom DNS est us.google.org ou se terminant par .google.com.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == DNS && (san.value == "us.google.org" || san.value.endsWith(".google.com")) )'
  

• Exemple: Autorisez uniquement les SAN ayant des URI https://google.com/webhp ou commençant par spiffe://example-trust-domain-1/ns/namespace1/sa/.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == URI && (san.value == "https://google.com/webhp" || san.value.startsWith("spiffe://example-trust-domain-1/ns/namespace1/sa/")) )'
  

• Exemple: Autorisez uniquement les SAN ayant une adresse e-mail [e-mail] ou se terminant par @google.org.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "[e-mail]" || san.value.endsWith("@google.org")) )'
  

• Exemple : Autorisez uniquement les SAN personnalisés disposant d'un OID spécifique et d'une valeur personnalisée.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == CUSTOM && san.oid == [1, 2, 3, 4] && san.value == "custom-data" )'
  

Limiter la durée de vie maximale des certificats émis

Pour limiter la durée de vie des certificats émis, utilisez le champ maximum_lifetime. Si la durée de vie demandée d'un certificat est supérieure à la durée de vie maximale, celle-ci est explicitement tronquée.

Remarque :Un certificat ne peut jamais survivre à l'autorité de certification émettrice. Si une demande de certificat mentionne une durée de vie qui dépasse la date not_after_time de l'autorité de certification, sa durée de vie est tronquée pour correspondre à la date not_after_time de l'autorité de certification. La durée de vie du certificat est tronquée, même si la stratégie d'émission des certificats autorise une durée de vie plus longue.

Exemple

Pour définir une durée de vie maximale de 30 jours, utilisez le fichier policy.yaml suivant:

policy.yaml

maximumLifetime: 2592000s

Limiter les modes d'émission de certificats autorisés

Vous pouvez demander un certificat via une demande de signature de certificat (CSR) ou une description intégrée des valeurs demandées. Certaines organisations peuvent préférer ajouter des limites concernant l'option qui peut être utilisée, car cette dernière méthode ne nécessite pas de preuve de possession de la clé privée associée. Vous pouvez définir ces limites à l'aide du champ allowedIssuanceModes.

Pour en savoir plus sur la spécification des différentes manières dont les certificats peuvent être demandés à partir d'un pool d'autorités de certification, consultez la section IssuanceModes.

Pour en savoir plus sur la demande de certificats, consultez Créez une demande de certificat.

• Exemple: Autoriser uniquement l'émission d'une requête de signature de certificat.

policy.yaml

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Restreindre les algorithmes de clé publique de la demande de certificat

Pour restreindre la longueur minimale de clé et les algorithmes de clé publique peuvent utiliser, utilisez le champ allowedKeyTypes dans le fichier YAML de stratégie d'émission de certificats. Si ce champ est spécifié, le la clé publique de demande de certificat doit correspondre à l'un des types de clés répertoriés dans le YAML. Si ce champ n'est pas spécifié, vous pouvez utiliser n'importe quelle clé, avec la propriété exception des clés RSA dont la taille du module est inférieure à 2 048 bits. Si vous souhaitez utiliser une clé RSA avec une taille de module inférieure à 2 048 bits, vous devez l'autoriser explicitement en utilisant stratégie d'émission de certificats.

Exemple: Autoriser les clés RSA avec une taille de module comprise entre 3 072 bits et 4 096 bits (inclus) ou clés ECDSA (Elliptic Curve Digital Signature Algorithm) sur la courbe NIST P-256.

policy.yaml

allowedKeyTypes:
- rsa:
    minModulusSize: 3072
    maxModulusSize: 4096
- ellipticCurve:
    signatureAlgorithm: ECDSA_P256

Vous pouvez choisir l'un des algorithmes de signature à courbe elliptique suivants:

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED : n'importe quel algorithme de signature peut être utilisé.
• ECDSA_P256 : signature numérique à courbe elliptique sur la courbe NIST P-256.
• ECDSA_P384 : signature numérique sur la courbe elliptique sur la courbe NIST P-384.
• EDDSA_25519 : algorithme de signature numérique à courbe d'Edwards sur la courbe 25519, tel que décrit dans le document RFC 8410.

Étape suivante

• En savoir plus sur les profils de certificat
• Découvrez comment demander des certificats.
• Apprenez à configurer les stratégies IAM.
• Découvrez comment utiliser le langage CEL (Common Expression Language).
• Découvrez comment gérer les différents contrôles des règles.