Crea un modello di certificato

In questa pagina vengono descritti gli attributi di un modello di certificato e viene spiegato come creare un modello di certificato.

Panoramica dei modelli di certificato

Certificate Authority Service fornisce modelli riutilizzabili e con parametri che puoi utilizzare per scenari di emissione di certificati comuni. Un modello di certificato rappresenta uno schema di emissione di certificati relativamente statico e ben definito all'interno di un'organizzazione. La risorsa CertificateTemplate include quanto segue.

1. Un'espressione CEL (Common Expression Language) che viene valutata in base all'oggetto richiesto e alle SAN in tutte le richieste di certificato che utilizzano il modello. Per ulteriori informazioni sull'uso di CEL, consulta la sezione Utilizzo di CEL.
2. Una lista consentita che specifica se l'oggetto o il nome alternativo del soggetto possono essere copiati dalla richiesta dell'utente finale al certificato emesso.
3. Una lista consentita facoltativa che specifica quali estensioni X.509, se presenti, possono essere copiate dalla richiesta dell'utente finale al certificato emesso.
4. Un insieme facoltativo di valori dell'estensione X.509 che viene aggiunto a tutti i certificati emessi che utilizzano il modello.

Un modello di certificato può fondamentalmente diventare un framework verticale di emissione di certificati completo. Per maggiori dettagli, consulta la definizione completa del messaggio CertificateTemplate.

Valori predefiniti in un modello di certificato

I valori predefiniti in un modello di certificato vengono aggiunti a tutti i certificati che utilizzano quel modello. Consentono di creare scenari comuni di emissione di certificati, come mTLS o firma del codice. I valori includono:

• Utilizzi della chiave: specifica l'utilizzo di base della chiave per un certificato in base alla sezione 4.2.1.12 di RFC 5280.
• Utilizzi estesi della chiave: specifica l'utilizzo esteso della chiave per un certificato in base alla sezione 4.2.1.3 di RFC 5280.
• Se il certificato è un'autorità di certificazione: specifica se il certificato può emettere certificati aggiuntivi o se si tratta di un certificato dell'entità finale.
• Lunghezza massima del percorso dell'emittente: nel caso di una CA, specifica il numero massimo di CA che possono essere concatenate al certificato CA. Se la lunghezza massima del percorso dell'emittente è impostata su 0, la CA può emettere solo certificati dell'entità finale. Se è impostato su 1, la catena al di sotto di questo certificato CA può includere una sola CA subordinata. Se non viene dichiarato un valore, il numero di CA subordinate nella catena al di sotto di questa CA è illimitato.
• Server OCSP AIA: fa riferimento ai server OCSP in un'estensione AIA (Authority Information Access) del certificato, come descritto nella sezione 4.2.2.1 di RFC 5280.
• Estensioni X.509 aggiuntive: descrive le estensioni X.509 personalizzate.

Il seguente esempio di codice menziona tutti i campi predefiniti in un modello di certificato:

keyUsage:
  baseKeyUsage:
    digitalSignature: true
    keyEncipherment: true
    contentCommitment: false
    dataEncipherment: false
    keyAgreement: false
    certSign: false
    crlSign: false
    encipherOnly: false
    decipherOnly: false
  extendedKeyUsage:
    serverAuth: true
    clientAuth: false
    codeSigning: false
    emailProtection: false
    timeStamping: false
    ocspSigning: false
caOptions:
  isCa: true
  maxIssuerPathLength: 1
policyIds:
- objectIdPath:
  - 1
  - 2
  - 3
additionalExtensions:
- objectId:
    objectIdPath:
    - 1
    - 2
    - 3
  critical: false
  value: "base64 encoded extension value"

I valori non specificati nel file YAML vengono omessi o impostati su false per impostazione predefinita.

Le seguenti estensioni vengono omesse se non viene specificato un valore:

• keyUsage
• policyIds
• additionalExtensions
• Campo maxIssuerPathLength nell'estensione caOptions

Se non viene specificato un valore, le seguenti estensioni hanno come valore predefinito false:

• Campo isCa nell'estensione caOptions

Crea un modello di certificato

Per creare un modello di certificato, utilizza il seguente comando gcloud:

gcloud

gcloud privateca templates create TEMPLATE_ID \
  --copy-subject \
  --copy-sans \
  --identity-cel-expression <expr> \
  --predefined-values-file FILE_PATH \
  --copy-all-requested-extensions \
  --copy-extensions-by-oid <1.2.3.4,5.6.7.8> \
  --copy-known-extensions <ext1,ext2>

Sostituisci quanto segue:

• TEMPLATE_ID: l'identificatore univoco del modello di certificato.
• FILE_PATH: il file YAML che descrive i valori X.509 impostati dal modello di certificato.

Il flag --copy-sans consente di copiare l'estensione Subject Alternative Name (SAN) dalla richiesta di certificato nel certificato firmato. In alternativa, puoi specificare --no-copy-sans per eliminare dalla richiesta di certificato qualsiasi SAN specificato dal chiamante.

Il flag --copy-subject consente di copiare l'oggetto della richiesta di certificato nel certificato firmato. In alternativa, puoi specificare --no-copy-subject per eliminare dalla richiesta di certificato qualsiasi oggetto specificato dal chiamante.

Nota: se vuoi assicurarti che un modello debba essere utilizzato con una riflessione dell'identità, specifica i flag --no-copy-subject e --no-copy-sans insieme. Per ulteriori informazioni sul riflesso dell'identità, consulta la pagina relativa al riflesso dell'identità.

Il flag --identity-cel-expression accetta un'espressione CEL che viene valutata in base al soggetto e al nome alternativo del soggetto del certificato prima che venga emesso e restituisce un valore booleano che indica se la richiesta deve essere consentita. Per informazioni sull'utilizzo di un'espressione CEL (Common Expression Language) per un modello di certificato, consulta Utilizzo di CEL per i modelli di certificato.

Il flag --predefined-values-file specifica il percorso di un file YAML che descrive tutti i valori X.509 predefiniti impostati da questo modello. Le estensioni fornite vengono copiate in tutte le richieste di certificato che utilizzano questo modello, hanno la precedenza sulle eventuali estensioni consentite nella richiesta di certificato. Se si aggiorna una qualsiasi parte dei valori X.509 predefiniti, l'aggiornamento sostituisce l'intero set di valori X.509 predefiniti.

Se è impostato il flag --copy-all-requested-extensions, tutte le estensioni specificate nella richiesta di certificato vengono copiate nel certificato firmato. In alternativa, puoi utilizzare il flag --copy-extensions-by-oid per copiare OID specifici dalla richiesta di certificato al certificato firmato e il flag --copy-known-extensions per copiare le estensioni dalla richiesta di certificato al certificato firmato. Deve essere uno dei seguenti: base-key-usage, extended-key-usage, ca-options, policy-ids, aia-ocsp-servers.

Nota: il flag del tag --copy-all-requested-extensions si esclude a vicenda dai flag --copy-known-extensions e --copy-extensions-by-oid.

Rimuovi il flag --copy-all-requested-extensions per ignorare tutte le estensioni X.509 nella richiesta di certificato, ma mantieni comunque i valori predefiniti definiti in questo modello.

Nota: se elimini risorse come pool di CA, autorità di certificazione e modelli di certificato, non potrai creare una nuova risorsa di quel tipo con lo stesso nome nello stesso progetto e nella stessa località.

Crea un modello di certificato per scenari comuni

Questa sezione fornisce i comandi gcloud per creare un modello di certificato per casi d'uso comuni.

Certificati TLS dei server DNS per qualsiasi dominio

Per creare un modello di certificato per l'emissione di certificati TLS dei server che consentano qualsiasi dominio, segui le istruzioni riportate di seguito:

1. Crea un file con il nome leaf_server_tls_values.yaml e aggiungi al file la seguente configurazione TLS del server dell'entità finale:

   leaf_server_tls_values.yaml

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

2. Per consentire solo i certificati con SAN di tipo DNS, esegui il seguente comando gcloud:

   gcloud

   gcloud privateca templates create server-tls \
     --predefined-values-file leaf_server_tls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == DNS)"
   

   Per ulteriori informazioni sul comando gcloud privateca templates create, consulta gcloud privateca template create.

Certificati TLS del server DNS con solo domini di test

Per creare un modello di certificato per l'emissione di certificati TLS dei server con SAN DNS limitate ai domini di test, utilizza il seguente comando gcloud:

gcloud

gcloud privateca templates create server-tls \
  --predefined-values-file leaf_server_tls_values.yaml \
  --copy-sans --no-copy-subject \
  --identity-cel-expression "subject_alt_names.all(san, san.type == DNS && san.value.endsWith('.test.example.com'))"

I contenuti del file leaf_server_tls_values.yaml devono essere uguali all'esempio precedente.

Per ulteriori informazioni sull'utilizzo delle espressioni CEL per garantire che i nomi DNS inizino o terminino con una determinata stringa, vedi Espressioni di esempio CEL.

Certificati di identità per i carichi di lavoro

Per creare un modello di certificato per l'emissione di certificati TLS reciproci (mTLS), utilizza le seguenti istruzioni:

1. Crea un file con il nome leaf_mtls_values.yaml e aggiungi la seguente configurazione TLS reciproca dell'entità finale.

   leaf_mtls_values.yaml

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

2. Per consentire solo i certificati con SAN URI SPIFFE, utilizza il seguente comando gcloud:

   gcloud

   gcloud privateca templates create workload-spiffe \
     --predefined-values-file leaf_mtls_values.yaml \
     --copy-sans --no-copy-subject \
     --identity-cel-expression "subject_alt_names.all(san, san.type == URI && san.value.startsWith('spiffe://'))"
   

   Per ulteriori informazioni sul comando gcloud privateca templates create, consulta gcloud privateca template create.

Per ulteriori informazioni sull'utilizzo delle espressioni CEL per garantire che i nomi DNS inizino o terminino con una determinata stringa, vedi Espressioni di esempio CEL.

Concedi l'accesso al modello di certificato

Puoi utilizzare un modello di certificato se hai il ruolo Utente modello certificato servizio CA (roles/privateca.templateUser). È consigliabile che gli autori di un modello di certificato concedano il ruolo Utente modello di certificato servizio CA ai membri dell'organizzazione che potrebbero utilizzare il modello di certificato.

Per concedere il ruolo Utente modello certificato servizio CA (roles/privateca.templateUser) a tutti gli utenti del dominio example.com, utilizza il seguente comando gcloud:

gcloud

gcloud privateca templates add-iam-policy-binding TEMPLATE_ID \
  --member "domain:example.com" \
  --role "roles/privateca.templateUser"

Sostituisci quanto segue:

• TEMPLATE_ID: l'identificatore univoco del modello di certificato.

Per ulteriori informazioni sul comando gcloud privateca templates add-iam-policy-binding, consulta gcloud privateca models add-iam-policy-binding.

Per ulteriori informazioni sui ruoli IAM per il servizio CA e sulle autorizzazioni associate, consulta Controllo dell'accesso con IAM.

Passaggi successivi

• Scopri di più sul Common Expression Language.
• Scopri come utilizzare il linguaggio delle espressioni comuni.
• Scopri di più sui profili certificati.