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 l'objet et les noms alternatifs d'objet (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 Présentation des modèles et des règles d'émission.

Attention :Les modifications apportées à la règle d'émission entrent en vigueur 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 Gestionnaire d'opérations du service CA (roles/privateca.caManager) ou 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 rôle unique.

• 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 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 auquel vous souhaitez ajouter une stratégie d'émission de certificats.

3. Sur la page Pool d'autorités de certification, 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:

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

Ce paramètre vous permet de configurer les manières dont la clé contenue dans le certificat peut être utilisée. Les options d'utilisation des clés incluent le chiffrement de clé, le chiffrement des données, la signature de certificats, la signature de LRC, 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 des clés

Vous pouvez utiliser ce paramètre pour sélectionner des scénarios plus précis pour lesquels la clé contenue dans le certificat peut être utilisée. Ces 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 configurez pas l'utilisation étendue 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 é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 des règles de certificat dans le certificat exprime les stratégies suivies par le pool d'autorités de certification émettrice. Cette extension peut inclure des informations sur la validation des identités avant l'émission des certificats, la révocation des certificats et la garantie de l'intégrité du pool d'autorités de certification. Cette extension vous aide à vérifier les certificats émis par le pool d'autorités de certification et à voir comment ils 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 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 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 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.

Lorsque vous cliquez 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, puis supprimez les extensions non requises du menu.
2. Facultatif: 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.

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, procédez comme suit:

1. Facultatif: Pour interdire le transfert de l'objet des demandes de certificat, cliquez sur le bouton d'activation.
2. Facultatif: Pour interdire le transfert des autres noms d'objet 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 sujets des certificats. Pour en savoir plus, consultez la page Utiliser le langage CEL.
4. Cliquez sur Suivant.

Pour savoir comment configurer des paramètres supplémentaires dans la stratégie d'émission de certificats, consultez 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 décrivant les restrictions appliquées aux certificats 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 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 "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 depuis 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 plus d'informations sur la commande gcloud privateca pools update, consultez la page sur la commande gcloud privateca pools update.

Restrictions acceptées

CA Service prend en charge les restrictions suivantes liées à la stratégie d'émission. Vous pouvez combiner les restrictions suivantes si nécessaire pour créer une stratégie d'émission de certificats personnalisée.

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 mettez à jour une partie du champ baseline_values, la mise à jour 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: Restreignez 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 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 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: Autoriser 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 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, 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éer 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 la clé et les algorithmes de clé publique que les certificats peuvent utiliser, 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 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 à l'aide de la 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 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 : 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 à 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.

Étapes suivantes

• En savoir plus sur les profils de certificat
• En savoir plus sur la demande de 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.