Aggiungere criteri di emissione dei certificati

L'aggiunta di criteri di emissione dei certificati in CA Service prevede la definizione di regole e limitazioni che regolano i tipi di certificati emessi da un'autorità di certificazione (CA). Per scoprire di più sulle norme di emissione dei certificati, consulta Informazioni sulle norme di emissione dei certificati.

Un criterio di emissione dei certificati ti consente di specificare l'oggetto e i nomi alternativi dell'oggetto (SAN) che possono essere inclusi nei certificati emessi. Puoi specificare la policy di emissione dei certificati durante la creazione di un pool di CA oppure puoi aggiornare un pool di CA esistente per aggiungere una policy di emissione.

Per saperne di più, consulta Panoramica dei modelli e delle norme di emissione.

Prima di iniziare

• Assicurati di disporre del ruolo IAM Responsabile operativo servizio CA (roles/privateca.caManager) o Amministratore servizio CA (roles/privateca.admin). Per informazioni sulla concessione di un ruolo IAM a un'entità, consulta Concedere un singolo ruolo.

• Crea un pool di CA.

Puoi aggiungere una policy di emissione dei certificati a un pool di CA durante la creazione di un pool di CA o quando aggiorni un pool di CA esistente.

Utilizza uno dei seguenti metodi:

Limitazioni supportate

CA Service supporta le seguenti limitazioni dei criteri di emissione. Puoi combinare le seguenti limitazioni in base alle tue esigenze per creare una policy di emissione dei certificati personalizzata.

Limitare o forzare i valori X.509 consentiti

Un pool di CA può limitare i valori X.509 consentiti nelle richieste di certificato configurando il campo passthrough_extensions.

Un pool di CA può anche specificare esplicitamente i valori X.509 da aggiungere a tutti i certificati emessi, sovrascrivendo eventuali valori richiesti, utilizzando il campo baseline_values.

I valori baseline_values di un pool di CA consentono di specificare le seguenti proprietà:

• Utilizzo della chiave
• Opzioni CA
• Server AIA OCSP
• Estensioni X.509 aggiuntive

Puoi anche utilizzare queste opzioni insieme.

Se aggiorni una parte qualsiasi del campo baseline_values, l'aggiornamento sostituisce l'intero insieme di valori nel campo baseline_values.

• Esempio: limita una CA a emettere solo certificati dell'entità finale con valori X.509 per TLS reciproca (mTLS).

  policy.yaml

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

• Esempio: limita una CA a emettere solo certificati di firma del codice dell'entità finale con un URL OCSP AIA di base.

  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"
  

Per saperne di più sul profilo del certificato per mTLS dell'entità finale, consulta mTLS dell'entità finale.

Limita i campi dell'identità consentiti

Per limitare l'identità dei certificati emessi tramite un pool di CA, puoi aggiungere un'espressione [Common Expression Language (CEL)][4]{: .external} al campo identity_constraints della policy di emissione. Le espressioni CEL consentono restrizioni arbitrarie sul nome di dominio del soggetto (incluso il nome comune) e sui SAN di un certificato.

Per saperne di più sull'utilizzo di un'espressione CEL per limitare il soggetto e i SAN, consulta Utilizzo di CEL.

• Esempio Consenti alla CA di emettere solo certificati corrispondenti a un soggetto specificato.

  policy.yaml

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

  Il campo celExpression è facoltativo. Utilizza un'espressione Common Expression Language (CEL) per convalidare l'oggetto e il SAN X.509 risolti prima che venga firmato un certificato. Per ulteriori informazioni sull'utilizzo delle espressioni CEL, consulta la sezione Utilizzo di CEL.

• Esempio: consenti solo SAN con nomi DNS come us.google.org o che terminano con .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")) )'
  

• Esempio: consenti solo i SAN con URI https://google.com/webhp o che iniziano con 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/")) )'
  

• Esempio: consenti solo i SAN con indirizzi email example@google.com o che terminano con @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")) )'
  

• Esempio: consenti solo SAN personalizzate con un OID specifico e un valore personalizzato.

  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" )'
  

Limitare la durata della retrodatazione dei certificati emessi

Per impostare un valore not_before_time precedente per i certificati emessi, utilizza il campo backdate_duration. Se configurati, i certificati di questo pool di CA hanno un valore not_before_time uguale all'ora di emissione meno la durata specificata. Il valore di not_after_time viene modificato per mantenere la durata del certificato richiesta. Il valore di backdate_duration deve essere inferiore o uguale a 48 ore.

Esempio

Per retrodatare i certificati di 1 ora, utilizza il seguente file policy.yaml:

backdateDuration: 3600s

Limitare la durata massima dei certificati emessi

Per limitare la durata dei certificati emessi, utilizza il campo maximum_lifetime. Se la durata richiesta di un certificato è superiore alla durata massima, la durata del certificato viene troncata in modo esplicito.

Esempio

Per consentire una durata massima di 30 giorni, utilizza il seguente file policy.yaml:

maximumLifetime: 2592000s

Limitare le modalità di emissione dei certificati consentite

Puoi richiedere un certificato tramite una richiesta di firma del certificato (CSR) o una descrizione in linea dei valori richiesti. Alcune organizzazioni potrebbero preferire aggiungere limitazioni all'opzione che può essere utilizzata perché quest'ultimo metodo non richiede una prova di possesso della chiave privata associata. Puoi impostare queste limitazioni utilizzando il campo allowedIssuanceModes.

Per ulteriori informazioni su come specificare i modi in cui è possibile richiedere i certificati da un pool di CA, consulta IssuanceModes.

Per saperne di più sulla richiesta di certificati, consulta Creare una richiesta di certificato.

• Esempio: consenti solo l'emissione di CSR.

allowedIssuanceModes:
  allowCsrBasedIssuance: True
  allowConfigBasedIssuance: False

Limitare gli algoritmi di chiave pubblica della richiesta di certificato

Per limitare la lunghezza minima della chiave e gli algoritmi di chiave pubblica che i certificati possono utilizzare, puoi utilizzare il campo allowedKeyTypes nel file YAML della policy di emissione dei certificati. Se questo campo è specificato, la chiave pubblica della richiesta di certificato deve corrispondere a uno dei tipi di chiave elencati nel file YAML. Se questo campo non è specificato, puoi utilizzare qualsiasi chiave, ad eccezione delle chiavi RSA la cui dimensione del modulo è inferiore a 2048 bit. Se vuoi utilizzare una chiave RSA con dimensioni del modulo inferiori a 2048 bit, devi consentirlo esplicitamente utilizzando il criterio di emissione di certificati.

Esempio: consenti chiavi RSA con una dimensione del modulo compresa tra 3072 e 4096 bit (inclusi) o chiavi Elliptic Curve Digital Signature Algorithm (ECDSA) sulla curva NIST P-256.

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

Puoi scegliere uno dei seguenti algoritmi di firma con curva ellittica:

• EC_SIGNATURE_ALGORITHM_UNSPECIFIED - È possibile utilizzare qualsiasi algoritmo di firma.
• ECDSA_P256 - Elliptic Curve Digital Signature sulla curva NIST P-256.
• ECDSA_P384 - Firma digitale con curva ellittica sulla curva NIST P-384.
• EDDSA_25519 - Edwards-curve Digital Signature Algorithm sulla curva 25519, come descritto in RFC 8410.

Passaggi successivi

• Scopri di più sui profili dei certificati.
• Scopri di più su come richiedere i certificati.
• Scopri come configurare i criteri IAM.
• Scopri come utilizzare Common Expression Language (CEL).
• Scopri come gestire vari controlli dei criteri.