Gestore certificati utilizza un meccanismo di mappatura flessibile offre un controllo granulare sui certificati che è possibile assegnare su come pubblicarli per ogni nome di dominio nel tuo ambiente. Il meccanismo include le seguenti entità:
- Certificati
- Mappe di certificati
- Voci della mappa di certificati
- Autorizzazioni per il dominio
Il seguente diagramma illustra le relazioni tra queste entità per un tipico proxy di destinazione specificato in una regola di forwarding del bilanciatore del carico:
Gestione certificati supporta i proxy target HTTPS e SSL. Per ulteriori informazioni sulle differenze tra questi tipi di proxy, consulta Utilizzo dei proxy di destinazione.
Per informazioni sui tipi di certificato utilizzati da Gestore certificati vedi Panoramica del deployment.
Certificati
Per impostazione predefinita, un certificato rappresenta un singolo certificato X.509 Transport Layer Security. (TLS) (SSL) emesso per nomi di dominio o domini specifici caratteri jolly.
Gestore certificati supporta i seguenti tipi di certificati:
- I certificati gestiti da Google sono certificati che Google Cloud che ottiene e gestisce per te.
- I certificati autogestiti sono i certificati che ottieni, di cui esegui il provisioning rinnovare l'abbonamento.
Quando emetti un certificato utilizzando un'autorità di certificazione pubblicamente attendibile, l'autorità di certificazione pubblica informazioni sul dominio associato ai log di Certificate Transparency, sono accessibili pubblicamente. Questo fa parte del processo standard di emissione dei certificati adottato da tutte le CA pubblicamente attendibili e si applica sia ai certificati gestiti da Google e autogestiti. Tuttavia, se utilizzi Certificate Authority Service per emettere i gestito da Google, Gestore certificati non pubblica alcun certificato ai log di Certificate Transparency.
Per ulteriori informazioni, vedi Certificate Transparency.
Per scoprire come eseguire il deployment di un certificato con Gestore certificati, consulta Panoramica del deployment.
Certificati gestiti da Google
Gestione dei certificati TLS (SSL) gestiti da Google per siti web e applicazioni può essere un'attività complessa e dispendiosa in termini di tempo, che spesso prevede la configurazione manuale e manutenzione regolare. Gestore certificati è un servizio progettato per aiutarti a semplificare questo processo fornendo una piattaforma centralizzata. Puoi delegare a Gestore certificati la responsabilità dell'emissione e del rinnovo dei certificati, liberando tempo da dedicare ad altre attività fondamentali.
Puoi verificare la proprietà del dominio pertinente utilizzando un'autorizzazione basata su bilanciatore del carico o DNS. Gestore certificati supporta RSA Certificati gestiti da Google.
Per impostazione predefinita, l'autorità di certificazione di Google emette certificati gestiti da Google. Quando viene emesso o rinnovato un nuovo certificato gestito da Google, viene utilizzata una chiave privata appena generata. Se non possono ottenere un certificato dall'autorità di certificazione di Google per un particolare dominio, Gestore certificati utilizza l'autorità di certificazione Let's Encrypt. Per Ad esempio, la CA di Google potrebbe rifiutare di emettere un certificato per il dominio il record di autorizzazione della CA impedisce esplicitamente alla CA Google di emettere certificati per quel dominio.
L'autenticazione solo per il lato client non è supportata.
Per istruzioni su come limitare le CA che possono emettere certificati per i tuoi domini, consulta Specifica delle CA che possono emettere il certificato gestito da Google.
Tieni presente che i certificati a livello di regione gestiti da Google (Anteprima) supportano solo l'autorizzazione basata su DNS e ottengono certificati dall'autorità di certificazione di Google.
Certificati gestiti da Google emessi da Certificate Authority Service
Se vuoi utilizzare la tua catena di attendibilità anziché affidarti a CA pubbliche approvate da Google per emettere i certificati, puoi configurare Gestore certificati in modo che utilizzi una Pool di CA del Certificate Authority Service come emittente del certificato. Per saperne di più sui pool di CA, consulta Creazione di pool di CA.
Certificati autogestiti
Se i tuoi requisiti aziendali non ti consentono di utilizzare certificati, puoi caricare quelli emessi da CA esterne insieme e le chiavi associate. È tua responsabilità emettere e rinnovare manualmente e autogestiti.
Gestore certificati consente anche di eseguire il deployment di certificati autogestiti Proxy Secure Web Proxy e proxy regionali bilanciatori del carico.
Mappe di certificati
Una mappa di certificati fa riferimento a una o più voci al suo interno che assegnano certificati specifici a nomi host specifici. Anche le voci della mappa di certificati definiscono la logica di selezione che il bilanciatore del carico segue quando stabilisce il client e altre connessioni. Puoi associare una mappa di certificati a più proxy di destinazione per riutilizzarli in più bilanciatori del carico.
Se un client richiede un nome host specificato in una mappa di certificati, il carico il bilanciatore del carico gestisce i certificati mappati a quel nome host. Altrimenti, il carico e gestisce il certificato principale. Per ulteriori informazioni, vedi Logica di selezione dei certificati.
Voci della mappa di certificati
Una voce della mappa di certificati è un elenco di certificati forniti per una specifica nome di dominio. Puoi definire set di certificati diversi per nomi di dominio differenti, come domini o sottodomini. Ad esempio, puoi caricare un report ECDSA e un RSA e mappale allo stesso nome di dominio. Quando un client si connette a quel nome di dominio, il bilanciatore del carico negozia il tipo di certificato da al client durante l'handshake.
Autorizzazioni per il dominio
Gestore certificati consente di dimostrare la proprietà dei domini per cui di voler emettere certificati gestiti da Google, come descritto .
| Autorizzazione bilanciatore del carico | Autorizzazione DNS | |
|---|---|---|
| Complessità della configurazione | Non sono necessari ulteriori passaggi di configurazione o modifiche al DNS configurazione. | Richiede la creazione di un'autorizzazione DNS e l'aggiunta del corrispondente Record CNAME alla tua configurazione DNS. |
| Sicurezza della rete | Il bilanciatore del carico deve essere completamente accessibile da internet sulla porta 443, inclusa la configurazione DNS per tutti i domini gestiti dal certificato. Non funziona con altre configurazioni. | Compatibile con configurazioni a elevata complessità, come porte diverse da 443 e CDN davanti al proxy di destinazione. |
| Velocità di provisioning | Puoi eseguire il provisioning dei certificati solo dopo che il bilanciatore del carico è stato completamente configurato e gestisce il traffico di rete. | Puoi eseguire il provisioning dei certificati in anticipo, prima che il proxy di destinazione pronti a gestire il traffico di rete. |
Per comprendere in che modo Gestore certificati verifica la proprietà del dominio utilizzando ciascun metodo, consulta Autorizzazioni di dominio per i certificati gestiti da Google.
Configurazioni di emissione dei certificati
Una configurazione dell'emissione dei certificati è una risorsa che consente a Gestore certificati per utilizzare un pool di CA dalla tua istanza Certificate Authority Service per emettere certificati gestiti da Google anziché la CA Google o la CA Let's Encrypt. Consente di specificare una serie di parametri che regolano l'emissione e la scadenza dei certificati, seleziona l'algoritmo chiave per i certificati emessi in questo modo.
Configurazioni di attendibilità
Una configurazione di attendibilità è una risorsa che rappresenta la configurazione dell'infrastruttura a chiave pubblica (PKI) in Gestore certificati per l'utilizzo in scenari di autenticazione TLS reciproca (mTLS). Incapsula un singolo archivio di attendibilità, che a sua volta incapsula un trust anchor e, facoltativamente, uno o più certificati intermedi.
Per saperne di più sull'autenticazione TLS reciproca (mTLS), consulta Autenticazione TLS reciproca nella documentazione di Cloud Load Balancing.
Una risorsa di configurazione dell'attendibilità incapsula un archivio attendibilità, un trust anchor e un certificato intermedio le entità.
Archivi di attendibilità
Un archivio di attendibilità rappresenta la configurazione del secret di attendibilità in Gestione certificati per l'utilizzo negli scenari di autenticazione TLS reciproca (mTLS). Incapsula un singolo trust anchor e, facoltativamente, uno o più certificati intermedi.
Trust anchor
Un trust anchor rappresenta un singolo certificato radice da utilizzare nel protocollo TLS reciproco scenari di autenticazione. È incapsulato in un archivio fiduciario.
Certificati intermedi
Un certificato intermedio rappresenta un singolo certificato intermedio firmato da un certificato radice o intermedio a cui viene fatto riferimento nel incapsulamento dell'archivio di attendibilità da utilizzare nell'autenticazione TLS reciproca (mTLS) diversi scenari.
Uno o più certificati intermedi possono essere incapsulati in un archivio di attendibilità, a seconda della configurazione dell'infrastruttura a chiave pubblica. Tutti i certificati intermedi specificati configurazione dell'attendibilità sono incluse nella valutazione dell'attendibilità richiesta di connessione oltre all'elenco dei certificati intermedi specificato nella richiesta stessa.
Certificati che richiedono una lista consentita
Facoltativamente, se devi utilizzare un certificato che è stato autofirmato,
scaduto o non valido, oppure se non hai accesso ai dati
certificati intermedi, puoi aggiungerlo alla configurazione dell'attendibilità
il campo allowlistedCertificates. Non è necessario un archivio attendibilità per aggiungere
a una lista consentita.
Se aggiungi un certificato alla lista consentita, il certificato è sempre considerata valida purché il certificato sia analizzabile, ovvero la prova della chiave privata. sia stato stabilito e i vincoli al campo SAN del certificato sono soddisfatti.
Logica di selezione dei certificati
A livello generale, il bilanciatore del carico seleziona un certificato come segue:
- Un client avvia un handshake. Durante questo passaggio, fornisce il bilanciatore del carico con un elenco di algoritmi crittografici da utilizzare per completare l'handshake, e, facoltativamente, un nome host.
Il bilanciatore del carico seleziona un certificato per completare l'handshake sicuro basato su handshake sul nome host fornito dal client e sulla mappa di certificati configurata le voci corrispondenti. I fattori che determinano il certificato del bilanciatore del carico sono le seguenti:
Corrispondenza esatta del nome host: se il client fornisce un nome host che corrisponde esattamente a una voce nella mappa di certificati di cui è stato eseguito il provisioning, il bilanciatore del carico seleziona il certificato corrispondente.
Corrispondenza del nome host del carattere jolly: se il nome host del client non corrisponde ad alcuna voce, ma corrisponde a un nome host con caratteri jolly in una voce di una mappa di certificati, il bilanciatore del carico seleziona il certificato corrispondente da quella voce. Ad esempio, una voce con carattere jolly configurata come
*.myorg.example.comcopre i sottodomini di primo livello nel dominiomyorg.example.com.Nessuna corrispondenza del nome host e voce preconfigurata della mappa dei certificati principale: Il bilanciatore del carico seleziona una voce preconfigurata della mappa di certificati primaria in assenza di una corrispondenza del nome host o di una voce della mappa di certificati di cui è stato eseguito il provisioning corrispondente.
Handshake non riuscito: l'handshake non va a buon fine se il bilanciatore del carico non riesce a trovare un certificato corrispondente per i seguenti motivi:
- Il client fornisce un nome host che non corrisponde a nessun nome host esatto o con caratteri jolly specificato in tutte le voci della mappa di certificati di cui è stato eseguito il provisioning oppure non fornisce alcun nome host.
- Impossibile trovare una voce corrispondente nella mappa dei certificati principale o se non hai configurato una voce nella mappa dei certificati primaria.
Priorità dei certificati
Il bilanciatore del carico seleziona un certificato all'interno di una voce della mappa di certificati in base a le seguenti:
- Tipo di certificato. Se il client di connessione supporta il modello ECDSA più sicuro il bilanciatore del carico assegna la priorità ai certificati RSA. Se Il client non indica il supporto per i certificati ECDSA, il bilanciatore del carico un certificato RSA.
- Dimensioni del certificato. Il bilanciatore del carico assegna la priorità ai certificati più piccoli al più grande.
Nomi di dominio con caratteri jolly
Ai nomi di dominio con caratteri jolly si applicano le seguenti regole:
- Solo i certificati gestiti da Google con autorizzazione DNS e i certificati gestiti da Google con CA Service supportano nomi di dominio con caratteri jolly. I certificati gestiti da Google con autorizzazione del bilanciatore del carico non supportano nomi di dominio con caratteri jolly.
- Una corrispondenza esatta ha la precedenza su un carattere jolly quando entrambi sono definiti nel
. Ad esempio, se hai configurato voci della mappa di certificati per
www.myorg.example.come*.myorg.example.com, una richiesta di connessione controwww.myorg.example.comseleziona sempre la voce perwww.myorg.example.comanche se una esiste anche una voce per*.myorg.example.com. - I nomi di dominio con caratteri jolly corrispondono a un solo livello di sottodominio. Per
Ad esempio, una richiesta di connessione per
host1.myorg.example.comseleziona un certificato voce mappa per*.myorg.example.com, ma non una perhost1.hosts.myorg.example.com.
Public CA
Per utilizzare la funzionalità CA pubblica di Gestore certificati, devi avere familiarità con i seguenti concetti:
Client ACME. Un client ACME (Automatic Certificate Management Environment) è un certificato che utilizza il protocollo ACME. Il tuo client ACME deve supportare l'associazione di account esterni (EAB) per poter funzionare con la CA pubblica.
Associazione di account esterni (EAB). Devi associare ogni account ACME che utilizzi a Gestore certificati una CA pubblica al progetto Google Cloud di destinazione utilizzando l'associazione di account esterni. Per farlo, devi registrare ogni Account ACME utilizzando un secret collegato al progetto Google Cloud corrispondente. Per saperne di più, consulta Account esterno associazione.
Sfide della Public CA
Quando utilizzi una Public CA per richiedere un certificato, Gestore certificati ti chiede di dimostrare il tuo controllo sui domini elencati nel certificato. Puoi dimostrare il controllo del dominio risolvendo delle sfide. La Public CA autorizza i nomi di dominio dopo la verifica dell'identità dei domini target.
Dopo aver ottenuto le autorizzazioni necessarie, puoi richiedere certificati che siano validi solo per un periodo di tempo specifico. Trascorso questo periodo, devi riconvalidare il nome di dominio risolvendo uno dei tre tipi di verifica per continuare a richiedere certificati.
Tipi di verifica dell'accesso
Public CA supporta i seguenti tipi di verifiche:
Verifica HTTP. Questa sfida prevede la creazione di un file in un posizione su un server HTTP (porta 80) per il recupero da parte della Public CA e verificare. Per ulteriori informazioni, consulta la pagina Verifica HTTP.
Sfida TLS-Application Layer Protocol Dispute (ALPN). Richiede un server per fornire un certificato specifico durante una negoziazione TLS sulla porta 443 per dimostrare il controllo di un dominio. Per ulteriori informazioni, vedi Estensione challenge TLS-ALPN di ACME.
Verifica DNS. Richiede l'aggiunta di un record DNS specifico in una località definita per dimostrare il controllo di un dominio. Per ulteriori informazioni, consulta la sezione Verifica DNS.
Se utilizzi il challenge HTTP o TLS-ALPN per convalidare un nome di dominio, il client può richiedere solo il dominio convalidato nomi da includere in un certificato. Se utilizzi la verifica DNS, un client può anche richiedere l'inclusione di sottodomini di quel nome di dominio certificato.
Ad esempio, se convalidi *.myorg.example.com utilizzando la verifica DNS,
subdomain1.myorg.example.com e subdomain2.myorg.example.com sono coperti automaticamente
dal certificato con caratteri jolly. Tuttavia, se convalidi myorg.example.com utilizzando un protocollo HTTP o
Verifica TLS-ALPN che il client può richiedere solo di includere myorg.example.com in
il certificato e non puoi convalidare *.myorg.example.com utilizzando le verifiche non DNS.
Logica della soluzione di verifica
La logica di verifica della CA pubblica è la seguente:
- Public CA fornisce un token casuale.
- Il client rende disponibile il token in una posizione ben definita. La la posizione dipende dalla sfida.
- Il client indica alla Public CA di aver preparato sfida.
- La Public CA controlla se il token è presente località corrisponda al valore previsto.
Il nome di dominio viene autorizzato al termine del processo. Il cliente può richiedere un certificato con quel nome di dominio. Devi risolvere un solo elemento per ogni nome di dominio.