Crea un modello di certificato

In questa pagina vengono descritti gli attributi di un modello di certificato e viene spiegato come possono 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 dei certificati comuni. Un modello di certificato rappresenta uno schema di emissione dei certificati relativamente statico e ben definito all'interno di un'organizzazione. La risorsa CertificateTemplate include quanto segue.

1. Un'espressione Common Expression Language (CEL) 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'utilizzo di CEL, consulta Utilizzare CEL.
2. Una lista consentita che specifica se il nome alternativo del soggetto o del soggetto può essere copiato 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 vengono aggiunti a tutti i certificati emessi che utilizzano il modello.

Un modello di certificato può diventare essenzialmente un framework di emissione di certificati verticali a tutti gli effetti. 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 lo utilizzano. Consentono di creare scenari comuni di rilascio di certificati, come mTLS o firma del codice. I valori includono:

• Utilizzi chiave: specifica l'utilizzo di base della chiave per un certificato in base a RFC 5280 sezione 4.2.1.12.
• Utilizzi estesi della chiave: specifica l'utilizzo esteso della chiave per un certificato in base alla sezione 4.2.1.3 del RFC 5280.
• Se il certificato è una CA: 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 a questo 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: si riferisce ai server OCSP nell'estensione di accesso alle informazioni dell'autorità (AIA) di un 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 in 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

Per le seguenti estensioni, il valore predefinito è false se non viene specificato un valore:

• 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 tutte le SAN specificate dal chiamante.

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

Nota: se vuoi assicurarti che un modello debba essere utilizzato con la riflessione dell'identità, specifica i flag --no-copy-subject e --no-copy-sans insieme. Per saperne di più sulla riflessione dell'identità, consulta Riflessione dell'identità.

Il flag --identity-cel-expression accetta un'espressione CEL che viene valutata in base al nome alternativo del soggetto e del soggetto del certificato prima di essere emesso e restituisce un valore booleano che indica se la richiesta deve essere consentita. Per informazioni sull'utilizzo di un'espressione Common Expression Language (CEL) per un modello di certificato, consulta Utilizzare 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 qualsiasi richiesta di certificato che utilizza questo modello, con la precedenza su qualsiasi estensione consentita nella richiesta di certificato. Se aggiorni una parte dei valori X.509 predefiniti, l'aggiornamento sostituisce l'intero insieme di valori X.509 predefiniti.

Se il flag --copy-all-requested-extensions è impostato, tutte le estensioni specificate nella richiesta di certificato vengono copiate nel certificato firmato. In alternativa, è possibile usare il flag --copy-extensions-by-oid per copiare nel certificato firmato specifici OID dalla richiesta di certificato, mentre il flag --copy-known-extensions può essere usato 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 è mutuamente esclusivo dei 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 mantenere 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 del server DNS per qualsiasi dominio

Per creare un modello di certificato per l'emissione di certificati TLS del server che consentono di qualsiasi dominio, segui queste istruzioni:

1. Crea un file denominato leaf_server_tls_values.yaml e aggiungi 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 questo 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 templates create.

Certificati TLS del server DNS con solo domini di test

Per creare un modello di certificato per l'emissione di certificati TLS del server con DNS SAN limitati 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 gli stessi dell'esempio precedente.

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

Certificati di Workload Identity

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

1. Crea un file con il nome leaf_mtls_values.yaml e aggiungi quanto segue configurazione TLS reciproca di un'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 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 templates create.

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

Concedi l'accesso al modello di certificato

Puoi utilizzare un modello di certificato se disponi del ruolo CA Service Certificate Template User (roles/privateca.templateUser). Consigliamo agli autori di un modello di certificato di concedere il ruolo Utente modello di certificato di servizio CA ai membri dell'organizzazione che potrebbero utilizzare quel modello di certificato.

Per concedere il ruolo CA Service Certificate Template User (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 templates add-iam-policy-binding.

Per ulteriori informazioni sui ruoli IAM per CA Service, e sulle autorizzazioni associate, vedi Controllo dell'accesso con IAM.

Passaggi successivi

• Scopri di più su Common Expression Language.
• Scopri come utilizzare il linguaggio di espressione comune.
• Scopri di più sui profili dei certificati.