Ajouter des règles d'émission de certificat

L'ajout de règles d'émission de certificats dans CA Service implique de définir des règles et des restrictions qui régissent les types de certificats émis par une autorité de certification (CA). Pour en savoir plus sur les règles d'émission de certificats, consultez À propos des règles d'émission de certificats.

Une règle d'émission de certificats vous permet de spécifier les noms d'objet et les autres noms d'objet (SAN) qui peuvent ê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. Vous pouvez également mettre à jour un pool d'autorités de certification existant pour ajouter une règle d'émission.

Pour en savoir plus, consultez 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 accorder un rôle IAM à un compte principal, consultez Attribuer un seul rôle.

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

Vous pouvez ajouter une règle d'émission de certificats à un pool d'autorités de certification lors de la création d'un pool d'autorités de certification ou lors de la mise à jour d'un pool d'autorités de certification existant.

Pour ce faire, utilisez une des méthodes suivantes :

Restrictions acceptées

Certificate Authority Service est compatible avec les restrictions de règles d'émission suivantes. Vous pouvez combiner les restrictions suivantes selon vos besoins 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 les valeurs X.509 à ajouter à tous les certificats émis, en écrasant toutes les valeurs demandées, à l'aide du champ baseline_values.

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

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

Vous pouvez également combiner ces options.

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 pour qu'elle n'émette que des certificats d'entité finale 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 à l'émission de 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é finale, consultez mTLS d'entité finale.

Restreindre les champs d'identité autorisés

Pour limiter l'identité des certificats émis par un pool d'autorités de certification, vous pouvez ajouter une expression [Common Expression Language (CEL)][4]{: .external} au champ identity_constraints de la règle 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 champs "Objet" et "SAN", consultez Utiliser CEL.

• Exemple : Autoriser l'autorité de certification à émettre uniquement 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 et le SAN X.509 résolus avant la signature d'un certificat. Pour en savoir plus sur l'utilisation des expressions CEL, consultez Utiliser CEL.

• Exemple : Autorisez uniquement les SAN dont les noms DNS sont us.google.org ou se terminent 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 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 des adresses e-mail example@google.com 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 == "example@google.com" || 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" )'
  

Restreindre la durée de rétroactivité des certificats émis

Pour définir une valeur not_before_time antérieure pour les certificats émis, utilisez le champ backdate_duration. Lorsqu'ils sont configurés, les certificats de ce pool d'autorités de certification ont une valeur not_before_time égale à l'heure d'émission moins la durée spécifiée. La valeur not_after_time est ajustée pour maintenir la durée de vie du certificat demandée. La valeur backdate_duration doit être inférieure ou égale à 48 heures.

Exemple

Pour antidater les certificats d'une heure, utilisez le fichier policy.yaml suivant :

backdateDuration: 3600s

Restreindre 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 pour un certificat est supérieure à la durée de vie maximale, elle est explicitement tronquée.

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 requête 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 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 méthodes de demande de certificats à partir d'un pool de CA, consultez IssuanceModes.

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

• Exemple : Autoriser uniquement l'émission de CSR.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

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

Pour limiter la longueur de clé minimale et les algorithmes de clé publique que les certificats peuvent utiliser, vous pouvez utiliser le champ allowedKeyTypes dans le fichier YAML de la règle 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 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 règle d'émission de certificats.

Exemple : Autoriser les clés RSA avec une taille de module 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.

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

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

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED : tout 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 la norme RFC 8410.

Étapes suivantes

• En savoir plus sur les profils de certificats
• En savoir plus sur la demande de 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 des règles.