Questa pagina descrive i passaggi per creare un'autorità di certificazione subordinata (CA secondaria).
Le CA secondarie sono responsabili dell'emissione di certificati direttamente alle entità finali, come utenti, computer e dispositivi. Sono firmati crittograficamente da una CA principale, spesso la CA radice. I sistemi che considerano attendibile la CA radice considerano automaticamente attendibili le CA secondarie e i certificati che emettono.
Il firmatario del certificato CA può essere un'altra CA creata in CA Service, ad esempio la CA principale, o una CA esterna. Con le CA esterne, il servizio CA genera una richiesta di firma del certificato (CSR) che la CA esterna deve firmare.
Prima di iniziare
Per ottenere le autorizzazioni necessarie per creare un'autorità di certificazione secondaria, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore del servizio di certificazione (certificate-authority-service-admin). Per ulteriori informazioni sui ruoli, consulta
Definizioni dei ruoli.
Recupera il file kubeconfig
Per eseguire comandi sul server API Management, assicurati di disporre delle seguenti risorse:
Accedi e genera il file kubeconfig per il server API Management se non ne hai uno.
Utilizza il percorso del file kubeconfig del server API Management per sostituire
MANAGEMENT_API_SERVER_KUBECONFIGin queste istruzioni.
Crea una CA secondaria gestita
Per una CA secondaria gestita, il firmatario del certificato CA è un'altra CA (CA radice) creata nel servizio CA.
Per creare una CA secondaria gestita, applica una risorsa personalizzata all'istanza di Distributed Cloud Appliance.
Crea una risorsa
CertificateAuthoritye salvala come file YAML denominatosubca.yaml:apiVersion: pki.security.gdc.goog/v1 kind: CertificateAuthority metadata: Name: SUB_CA_NAME namespace: USER_PROJECT_NAMESPACE spec: caProfile: commonName: COMMON_NAME duration: DURATION renewBefore: RENEW_BEFORE organizations: - ORGANIZATIONS organizationalUnits: - ORGANIZATIONAL_UNITS countries: - COUNTRIES localities: - LOCALITIES provinces: - PROVINCES streetAddresses: - STREET_ADDRESSES postalCodes: - POSTAL_CODES caCertificate: managedSubCA: certificateAuthorityRef: name: ROOT_CA_NAME namespace: USER_PROJECT_NAMESPACE certificateProfile: keyUsage: - digitalSignature - keyCertSign - crlSign extendedKeyUsage: - EXTENDED_KEY_USAGE secretConfig: secretName: SECRET_NAME privateKeyConfig: algorithm: KEY_ALGORITHM size: KEY_SIZE acme: enabled: ACME_ENABLEDSostituisci le seguenti variabili:
Variabile Descrizione SUB_CA_NAME Il nome della CA secondaria. USER_PROJECT_NAMESPACE Il nome dello spazio dei nomi in cui si trova il progetto utente. COMMON_NAME Il nome comune del certificato CA. DURATION La durata richiesta del certificato CA. ROOT_CA_NAME Il nome della CA radice. SECRET_NAME Il nome del secret Kubernetes che contiene la chiave privata e il certificato CA firmato. Le seguenti variabili sono valori facoltativi:
Variabile Descrizione RENEW_BEFORE Il tempo di rotazione prima della scadenza del certificato CA. ORGANIZATIONS Organizzazioni da utilizzare nel certificato. ORGANIZATIONAL_UNITS Unità organizzative da utilizzare nel certificato. COUNTRIES Paesi da utilizzare nel certificato. LOCALITIES Città da utilizzare nel certificato. PROVINCES Stati o province da utilizzare nel certificato. STREET_ADDRESSES Indirizzi da utilizzare sul certificato. POSTAL_CODES I codici postali da utilizzare nel certificato. EXTENDED_KEY_USAGE L'utilizzo esteso della chiave per il certificato. Se specificato, i valori consentiti sono serverAutheclientAuth.KEY_ALGORITHYM L'algoritmo della chiave privata utilizzato per questo certificato. I valori consentiti sono RSA, Ed25519 o ECDSA. Se le dimensioni non vengono fornite, il valore predefinito è 256 per ECDSA e 2048 per RSA. La dimensione della chiave viene ignorata per Ed25519. KEY_SIZE Le dimensioni, in bit, della chiave privata per questo certificato dipendono dall'algoritmo. RSA consente 2048, 3072, 4096 o 8192 (2048 per impostazione predefinita). ECDSA consente 256, 384 o 521 (256 per impostazione predefinita). Ed25519 ignora le dimensioni. ACME_ENABLED Se impostato su true, CA viene eseguito in modalità ACME e restituisce l'URL del server ACME. Puoi quindi utilizzare il client e il protocollo ACME per gestire i certificati.Applica la risorsa personalizzata all'istanza Distributed Cloud:
kubectl apply -f subca.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIGSostituisci
MANAGEMENT_API_SERVER_KUBECONFIGcon il percorso del file kubeconfig del server API Management.Verifica che la CA secondaria sia pronta. L'autorità di certificazione richiede circa 40 minuti per essere pronta:
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'L'output è simile al seguente:
{ "lastTransitionTime": "2025-01-24T17:09:29Z", "message": "CA reconciled", "observedGeneration": 2, "reason": "Ready", "status": "True", "type": "Ready" }
Crea una CA secondaria da una CA esterna
Questa CA secondaria supporta la firma di certificati foglia con CA esterne o gestite dagli utenti. Genera una CSR che gli utenti devono firmare.
Crea una risorsa
CertificateAuthoritye salvala come file YAML denominatosubca-external.yaml:apiVersion: pki.security.gdc.goog/v1 kind: CertificateAuthority metadata: Name: SUB_CA_NAME namespace: USER_PROJECT_NAMESPACE spec: caProfile: commonName: COMMON_NAME duration: DURATION renewBefore: RENEW_BEFORE organizations: - ORGANIZATION organizationalUnits: - ORGANIZATIONAL_UNITS countries: - COUNTRIES localities: - LOCALITIES provinces: - PROVINCES streetAddresses: - STREET_ADDRESSES postalCodes: - POSTAL_CODES caCertificate: externalCA: {} certificateProfile: keyUsage: - digitalSignature - keyCertSign - crlSign extendedKeyUsage: - EXTENDED_KEY_USAGE secretConfig: secretName: SECRET_NAME privateKeyConfig: algorithm: KEY_ALGORITHM size: KEY_SIZE acme: enabled: ACME_ENABLEDSostituisci le seguenti variabili:
Variabile Descrizione SUB_CA_NAME Il nome della sub-CA. USER_PROJECT_NAMESPACE L'ID progetto del progetto in cui vuoi importare l'immagine. COMMON_NAME Il nome comune del certificato CA. DURATION La durata richiesta del certificato CA SECRET_NAME Il nome del secret Kubernetes che contiene la chiave privata e il certificato CA firmato. Le seguenti variabili sono valori facoltativi:
Variabile Descrizione RENEW_BEFORE Il tempo di rotazione prima della scadenza del certificato CA. ORGANIZATION L'organizzazione da utilizzare nel certificato. ORGANIZATIONAL_UNITS Unità organizzative da utilizzare nel certificato. COUNTRIES Paesi da utilizzare nel certificato. LOCALITIES Città da utilizzare nel certificato. PROVINCES Stati o province da utilizzare nel certificato. STREET_ADDRESSES Indirizzi da utilizzare sul certificato. POSTAL_CODES I codici postali da utilizzare nel certificato. EXTENDED_KEY_USAGE L'utilizzo esteso della chiave per il certificato. Se specificato, i valori consentiti sono serverAutheclientAuth.KEY_ALGORITHYM L'algoritmo della chiave privata utilizzato per questo certificato. I valori consentiti sono RSA,Ed25519oECDSA. Se le dimensioni non vengono fornite, il valore predefinito è 256 perECDSAe 2048 perRSA. La dimensione della chiave viene ignorata perEd25519.KEY_SIZE Le dimensioni, in bit, della chiave privata per questo certificato dipendono dall'algoritmo. RSAconsente 2048, 3072, 4096 o 8192 (2048 per impostazione predefinita).ECDSAconsente 256, 384 o 521 (256 per impostazione predefinita).Ed25519ignora le dimensioni.ACME_ENABLED Se impostato su true, CA viene eseguito in modalità ACME e restituisce l'URL del server ACME. Puoi quindi utilizzare il client e il protocollo ACME per gestire i certificati.Applica la risorsa personalizzata all'istanza Distributed Cloud:
kubectl apply -f subca-external.yaml --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIGUna CSR per la CA secondaria viene generata all'interno del server dell'API GDC Management. Devi scaricare la CSR e firmarla. Una volta firmato, puoi caricare il certificato firmato nel server dell'API GDC Management.
Raccogli le richieste di firma del certificato (CSR) dal tuo ambiente Distributed Cloud:
kubectl get certificateauthorities SUB_CA_NAME -n USER_PROJECT_NAMESPACE -ojson | jq -j '"echo ", .status.externalCA.csr, " | base64 -d > ","sub_ca.csr\n"' | bashIl comando genera un file CSR denominato
sub_ca.csrnella directory corrente. Questo file contiene una CSR per un certificato CAX.509.Utilizza la CA radice del cliente per richiedere certificati CA firmati per il file
sub_ca.csr.Per una richiesta di firma del certificato approvata, devi ottenere un certificato CA firmato dalla CA radice del cliente. Memorizza il certificato nel file
sub_ca.crtnella directory attuale.Se applicabile, ottieni il certificato CA radice del cliente e memorizzalo nel file
ca.crtnella directory corrente.Verifica le estensioni del nome alternativo del soggetto (SAN) nel certificato:
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject Alternative Name"Se il certificato CA ha un nome comune (CN) anziché un SAN, verifica il CN nel certificato:
openssl x509 -text -noout -in sub_ca.crt | grep -A 1 "Subject: CN"Genera il
specper applicare la patch alla risorsaCertificateAuthority:echo "spec: caCertificate: externalCA: signedCertificate: certificate: $(base64 -w0 SUB_CA_NAME.crt) ca: $(base64 -w0 ca.crt)" > patch.txtI contenuti del file
patch.txthanno un aspetto simile al seguente:spec: caCertificate: externalCA: signedCertificate: certificate: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURSekNDQ… ca: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURRVENDQ…Modifica il campo
specdella risorsaCertificateAuthority:kubectl patch certificateauthority SUB_CA_NAME -n USER_PROJECT_NAMESPACE--patch-file patch.txt --type='merge'Verifica la preparazione della CA secondaria BYO (Bring Your Own). In genere, sono necessari circa 40 minuti prima che la CA sia pronta:
kubectl -n USER_PROJECT_NAMESPACE get certificateauthority.pki.security.gdc.goog/SUB_CA_NAME -ojson | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'L'output è simile al seguente:
{ "lastTransitionTime": "2024-04-30T22:10:50Z", "message": "Certificate authority is ready for use", "observedGeneration": 3, "reason": "Ready", "status": "True", "type": "Ready" }Verifica la data di scadenza dei certificati CA firmati:
kubectl -n USER_PROJECT_NAMESPACE get secret SECRET_NAME -ojson | jq -j '"echo ", .metadata.name, " $(echo ", .data["tls.crt"], "| base64 -d | openssl x509 -enddate -noout)\n"' | bash
Elenco delle CA
Per elencare tutte le risorse di Certificate Authority Service nella tua istanza Distributed Cloud air-gapped, procedi nel seguente modo:
Utilizza il parametro certificateauthorities per elencare tutte le risorse CertificateAuthority:
kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG -n USER_PROJECT_NAMESPACE get certificateauthorities
L'output è simile al seguente:
NAMESPACE NAME READY REASON AGE
foo root-ca True Ready 7h24m
foo sub-ca True Ready 7h24m