Ajouter une règle 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 règle d'émission de certificats vous permet de spécifier l'objet et les autres noms d'objet (SAN) pouvant être inclus dans les certificats émis. Vous pouvez spécifier la règle d'émission de certificats lorsque vous créez un pool d'autorités de certification ou mettre à jour un pool d'autorités de certification existant pour ajouter une règle d'émission.

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

Avant de commencer

• Assurez-vous de disposer du rôle IAM "Responsable des opérations du service CA" (roles/privateca.caManager) ou "Administrateur du service CA" (roles/privateca.admin). Pour savoir comment attribuer un rôle IAM à un principal, consultez la section Attribuer un rôle unique.

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

Ajouter un fichier de règles 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:

Restrictions acceptées

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

Limiter 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 les valeurs demandées, à l'aide du champ baseline_values.

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

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

Vous pouvez également les utiliser conjointement.

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

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 d'appliquer des restrictions arbitraires au nom de domaine de l'objet (y compris le nom commun) et aux SAN d'un certificat.

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

• Exemple : Autorisez l'autorité de certification à n'émettre que des certificats correspondant à un sujet 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 l'Autre nom de l'objet résolus avant la signature d'un certificat. Pour en savoir plus sur l'utilisation d'expressions CEL, consultez Utiliser CEL.

• Exemple: Autorisez uniquement les SAN dont le nom DNS est us.google.org ou se termine 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: n'autorisez que les SAN dont les URI sont https://google.com/webhp ou commencent 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 dont les adresses e-mail sont example@google.com ou se terminent par @google.org.

  policy.yaml

  identityConstraints:
    allowSubjectPassthrough: false
    allowSubjectAltNamesPassthrough: true
    celExpression:
      expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "example@google.com" || 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, elle est tronquée explicitement.

Exemple

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

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 à l'option pouvant ê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 méthodes de demande de certificats auprès d'un pool d'autorités de certification, consultez IssuanceModes.

Pour en savoir plus sur la demande de certificats, consultez la section Créer une requête de certificat.

• Exemple: n'autorisez que l'émission de CSR.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

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

Pour limiter la longueur minimale de 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 listé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 règle d'émission de certificats.

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

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

Vous pouvez choisir l'un des algorithmes de signature par 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 P-384 du NIST.
• EDDSA_25519 : algorithme de signature numérique à courbe d'Edwards sur la courbe 25519, comme décrit dans la RFC 8410.

Étape suivante

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