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

Cette page explique comment ajouter une stratégie d'émission de certificats à un pool d'autorités de certification.

Une stratégie d'émission de certificats vous permet de spécifier les noms d'objet et d'objet 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 mettre à jour un pool d'autorités de certification existant pour ajouter une stratégie d'émission.

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

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

Avant de commencer

• Assurez-vous de disposer du rôle IAM CA Service Operation Manager (roles/privateca.caManager) ou d'administrateur du service CA (roles/privateca.admin). Pour en savoir plus sur l'attribution d'un rôle IAM à un compte principal, consultez la section Attribuer un seul 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 de 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 vous souhaitez ajouter une stratégie d'émission de certificats.

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

Configurer les 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 dans les demandes de certificat, cliquez sur le bouton d'activation.
2. Facultatif: Pour interdire la transmission des noms d'objet alternatifs dans les demandes de certificat, cliquez sur le bouton d'activation.
3. Facultatif: ajoutez une expression CEL (Common Expression Language) pour appliquer des restrictions aux objets de certificat. Pour en savoir plus, consultez la section Utiliser CEL.
4. Cliquez sur Suivant.

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, le champ Extensions de certificat connues s'affiche. Vous pouvez l'utiliser pour sélectionner les extensions de certificat. Pour sélectionner les extensions de certificat, procédez comme suit:

1. (Facultatif) Cliquez sur le champ Extensions de certificat connues et supprimez les extensions inutiles du menu.
2. Facultatif: dans le champ Extensions personnalisées, ajoutez les identifiants d'objets pour les extensions que vous souhaitez inclure dans les certificats émis par le pool d'autorités de certification.

Configurer des valeurs de référence

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

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 les manières d'utiliser la clé contenue dans le certificat. Les options d'utilisation des clés incluent le chiffrement des clés, le chiffrement des données, la signature de certificat, la signature LRC, etc.

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

Pour définir les utilisations 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 les utilisations de base des clés pour les certificats.
2. Cochez les cases correspondant aux modalités d'utilisation d'une clé.

3. Cliquez sur Suivant.

Définir l'utilisation étendue des clés

Vous pouvez utiliser ce paramètre pour sélectionner des scénarios plus précis dans lesquels la clé contenue dans le certificat peut être utilisée. Ces options incluent l'authentification du serveur, l'authentification du client, la signature du code, la protection des e-mails, etc.

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

Pour en savoir plus, consultez 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 de clés pour les certificats émis par le 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 de règles de certificat dans le certificat exprime les règles suivies par le pool d'autorités de certification émettrice. Cette extension peut inclure des informations sur la manière dont les identités sont validées avant l'émission des certificats, sur la manière dont les certificats sont révoqués et sur la manière dont l'intégrité du pool d'autorités de certification est garantie. Cette extension vous permet de vérifier les certificats émis par le pool d'autorités de certification et de voir comment ils sont utilisés.

Pour en savoir plus, consultez la section Règles relatives aux certificats.

Pour spécifier la règle qui définit l'utilisation des certificats, 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 Accès aux informations des autorités.

Pour ajouter les serveurs OCSP qui apparaissent dans le champ d'extension AIA des certificats, procédez comme suit : 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 les 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 au format numérique séparé par un point.
3. Dans le champ Valeur, ajoutez la valeur encodée en base64 pour l'identifiant.
4. Si l'extension est critique, sélectionnez Extension est essentielle.

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

gcloud

Pour utiliser la Google Cloud CLI afin d'ajouter une stratégie d'émission de certificats à un pool d'autorités de certification, vous devez créer un fichier YAML décrivant les restrictions sur les certificats que le pool d'autorités de certification peut émettre. Le contenu correspond à une IssuancePolicy.

1. À l'aide de l'éditeur Cloud Shell, créez un fichier policy.yaml avec le contenu suivant:

   identityConstraints:
     allowSubjectPassthrough: true
     allowSubjectAltNamesPassthrough: true
   

   Où :

   • Le champ allowSubjectPassthrough est obligatoire. Si le champ allowSubjectPassthrough est défini sur true, le champ d'objet est copié dans le certificat signé à partir d'une demande de certificat. Sinon, l'objet demandé est supprimé.
   • Si le champ allowSubjectAltNamesPassthrough est défini sur true, l'extension SubjectAltNames est copiée d'une requête de certificat dans le certificat signé. Sinon, les objets 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 section gcloud privateca pools update.

Pour en savoir plus, consultez la section Créer un pool d'autorités de certification.

Restrictions acceptées

CA Service accepte les restrictions de stratégie d'émission suivantes. Vous pouvez combiner les restrictions suivantes si nécessaire pour créer une stratégie d'émission de certificats personnalisée.

Restreindre ou forcer les valeurs X.509 autorisées

Un pool d'autorités de certification peut limiter 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 toutes 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 des autorités de certification
• Serveurs OCSP AIA
• Extensions X.509 supplémentaires

Vous pouvez également combiner ces options.

Si vous mettez à jour une partie du champ baseline_values, elle remplace l'ensemble des valeurs du champ baseline_values.

• Exemple: Empêcher une autorité de certification de n'émettre que des certificats d'entité finale contenant 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: Empêcher une autorité de certification de n'émettre que des certificats de signature de code d'entité finale associés à une URL OCSP de référence AIA.

  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 le protocole mTLS d'entité de fin, consultez la section mTLS d'entité de fin.

Limiter les champs d'identité autorisés

Pour restreindre 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 stratégie d'émission. Les expressions CEL autorisent 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 les objets et les réseaux SAN, consultez la section Utiliser CEL.

• Exemple : Autoriser 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 résolu et le SAN avant la signature d'un certificat. Pour en savoir plus sur l'utilisation des expressions CEL, consultez Utiliser CEL.

• Exemple: Autoriser uniquement les SAN dont les noms DNS sont 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: Autoriser 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: Autoriser uniquement les SAN dont l'adresse e-mail est [e-mail] ou se termine 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: Autoriser uniquement les SAN personnalisés ayant un OID spécifique et 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, elle est explicitement tronquée.

Remarque :Un certificat ne peut jamais survivre à l'autorité de certification qui l'a émis. Si une demande de certificat mentionne une date de vie supérieure à la date not_after_time de l'autorité de certification, celle-ci 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 via une description intégrée des valeurs demandées. Certaines organisations peuvent préférer ajouter des limites à 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 savoir comment spécifier les méthodes de demande de certificats à partir d'un pool d'autorités de certification, consultez IssuanceModes.

Pour en savoir plus sur la demande de certificats, consultez la section Demander un certificat et afficher les certificats émis.

• Exemple: Autoriser uniquement l'émission de requêtes de signature de certificat.

policy.yaml

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

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

Pour limiter la longueur minimale de la clé et les algorithmes de clé publique utilisés par les certificats, vous pouvez utiliser le champ allowedKeyTypes dans le fichier YAML de la stratégie d'émission de certificats. Si ce champ est spécifié, la clé publique de la demande de certificat doit correspondre à l'un des types de clés répertoriés dans le fichier YAML. Si ce champ n'est pas spécifié, vous pouvez utiliser n'importe quelle clé, à l'exception des clés RSA dont la taille de 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 à l'aide de la stratégie d'émission de certificats.

Exemple: Autoriser les clés RSA dont la taille de module est comprise entre 3 072 et 4 096 bits (inclus), ou les 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 : vous pouvez utiliser n'importe quel algorithme de signature.
• ECDSA_P256 : signature numérique à courbe elliptique sur la courbe NIST P-256.
• ECDSA_P384 : signature numérique à courbe elliptique sur la courbe NIST P-384.
• EDDSA_25519 : algorithme de signature numérique à courbe Edwards sur la courbe 25519, tel que décrit dans le document RFC 8410.

Étapes suivantes

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