Gestore certificati utilizza un meccanismo di mappatura flessibile che offre un controllo granulare sui certificati che puoi assegnare e su come pubblicarli per ciascun 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 certificati supportati da Gestore certificati, consulta Panoramica del deployment.
Certificati
Per impostazione predefinita, un certificato rappresenta un singolo certificato (SSL) X.509 Transport Layer Security (TLS) emesso per nomi di dominio o caratteri jolly di dominio specifici.
Gestore certificati supporta i seguenti tipi di certificati:
- I certificati gestiti da Google sono certificati che Google Cloud ottiene e gestisce per te.
- I certificati autogestiti sono certificati che ottieni, di cui esegui il provisioning e rinnovi in autonomia.
Quando emetti un certificato utilizzando un'autorità di certificazione pubblicamente attendibile, la CA pubblica le informazioni sul dominio associato nei log di Certificate Transparency, che sono accessibili pubblicamente. Fa parte del processo di emissione dei certificati standard adottato da tutte le CA pubblicamente attendibili e si applica sia ai certificati gestiti da Google sia ai certificati autogestiti. Tuttavia, se utilizzi Certificate Authority Service per emettere il certificato gestito da Google, Gestione certificati non pubblica alcuna informazione nei log di Certificate Transparency.
Per ulteriori informazioni, consulta Certificate Transparency.
Per scoprire come eseguire il deployment di un certificato con Gestore certificati, consulta Panoramica del deployment.
Certificati gestiti da Google
La gestione dei certificati TLS (SSL) gestiti da Google per i tuoi siti web e le tue applicazioni può essere un'attività complessa e dispendiosa in termini di tempo, che spesso prevede la configurazione manuale e la manutenzione regolare. Gestore certificati è un servizio progettato per semplificare il 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 i certificati RSA 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 riesci a ottenere un certificato dall'autorità di certificazione di Google per un determinato dominio, Certificate Manager utilizza l'opzione Let's Encrypt CA. Ad esempio, la CA di Google potrebbe rifiutare di emettere un certificato per il dominio o 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, vedi Specificare le 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 l'emissione dei certificati, puoi configurare Gestore certificati in modo da utilizzare un pool di CA di 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 i certificati gestiti da Google, puoi caricare i certificati emessi da CA esterne insieme alle relative chiavi. Sei responsabile dell'emissione e del rinnovo manuale di certificati autogestiti.
Gestore certificati consente inoltre di eseguire il deployment di certificati autogestiti a livello di regione su proxy Secure Web Proxy e bilanciatori del carico a livello di regione.
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. Le voci della mappa di certificati definiscono anche la logica di selezione che il bilanciatore del carico segue quando stabilisce le connessioni client. 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 bilanciatore del carico pubblica i certificati mappati a quel nome host. In caso contrario, il bilanciatore del carico gestisce il certificato principale. Per ulteriori informazioni, consulta Logica di selezione dei certificati.
Voci della mappa di certificati
Una voce della mappa di certificati è un elenco di certificati pubblicati per un nome di dominio specifico. Puoi definire set di certificati diversi per nomi di dominio diversi, ad esempio domini o sottodomini. Ad esempio, puoi caricare un certificato ECDSA e un RSA e mapparli 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 fornire al client durante l'handshake.
Autorizzazioni per il dominio
Gestore certificati consente di dimostrare la proprietà dei domini per i quali vuoi emettere certificati gestiti da Google, come descritto nella tabella seguente.
| Autorizzazione bilanciatore del carico | Autorizzazione DNS | |
|---|---|---|
| Complessità della configurazione | Non sono necessari ulteriori passaggi di configurazione o modifiche alla configurazione DNS. | Richiede la creazione di un'autorizzazione DNS e l'aggiunta del record CNAME corrispondente alla 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. | Funziona con configurazioni ad alta complessità, come porte diverse da 443 e livelli 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 sia pronto a gestire il traffico di rete. |
Per capire 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 di utilizzare un pool di CA dalla tua istanza di 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, nonché di selezionare 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) nel Gestore certificati da utilizzare 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 ulteriori informazioni sull'autenticazione TLS reciproca (mTLS), consulta Autenticazione TLS reciproca nella documentazione di Cloud Load Balancing.
Una risorsa di configurazione dell'attendibilità incapsula archivio attendibilità, trust anchor ed entità di certificato intermedie.
Archivi di attendibilità
Un archivio di attendibilità rappresenta la configurazione del secret di attendibilità in Gestore certificati da utilizzare in 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 in scenari di autenticazione TLS reciproca. È incapsulato in un archivio fiduciario.
Certificati intermedi
Un certificato intermedio rappresenta un singolo certificato intermedio firmato da un certificato radice o un certificato intermedio a cui viene fatto riferimento nell'archivio di attendibilità di incapsulamento da utilizzare negli scenari di autenticazione TLS reciproca (mTLS).
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 in una configurazione di attendibilità sono inclusi come parte della valutazione dell'attendibilità per ogni richiesta di connessione, oltre all'elenco dei certificati intermedi specificati nella richiesta stessa.
Certificati che richiedono una lista consentita
Facoltativamente, se devi utilizzare un certificato autofirmato, scaduto o non valido in altro modo oppure se non hai accesso ai certificati radice e intermedi, puoi aggiungerlo alla configurazione dell'attendibilità nel campo allowlistedCertificates. Non è necessario un archivio di attendibilità
per aggiungere un certificato a una lista consentita.
Aggiungere un certificato alla lista consentita significa che il certificato viene sempre considerato valido, purché sia analizzabile, sia stata stabilita la prova di possesso della chiave privata e vengano soddisfatti i vincoli sul campo SAN del certificato.
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 al bilanciatore del carico un elenco di algoritmi crittografici che può utilizzare per completare l'handshake e, facoltativamente, un nome host.
Il bilanciatore del carico seleziona un certificato per completare l'handshake sicuro in base al nome host fornito dal client e alle voci della mappa di certificati configurata. I fattori che determinano quale certificato viene selezionato dal bilanciatore del carico sono i 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 della mappa di certificati primaria preconfigurata: il bilanciatore del carico seleziona una voce preconfigurata della mappa dei 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 di mappa di certificati in base a quanto segue:
- Tipo di certificato. Se il client di connessione supporta i certificati ECDSA più sicuri, 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 pubblica invece un certificato RSA.
- Dimensioni del certificato. Il bilanciatore del carico assegna la priorità ai certificati dal più piccolo 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 nella voce. Ad esempio, se hai configurato voci della mappa di certificati per
www.myorg.example.come*.myorg.example.com, una richiesta di connessione awww.myorg.example.comseleziona sempre la voce perwww.myorg.example.comanche se esiste anche una voce per*.myorg.example.com. - I nomi di dominio con caratteri jolly corrispondono a un solo livello di sottodominio. Ad
esempio, una richiesta di connessione per
host1.myorg.example.comseleziona una voce della mappa di certificati per*.myorg.example.com, ma non una perhost1.hosts.myorg.example.com.
Public CA
Per utilizzare la funzionalità CA pubblica di Gestore certificati, devi conoscere i seguenti concetti:
Client ACME. Un client ACME (Automatic Certificate Management Environment) è un client per la gestione dei certificati 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 con una CA pubblica di Certificate Manager 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 maggiori informazioni, consulta la pagina Associazione di account esterni.
Sfide della Public CA
Quando utilizzi la Public CA per richiedere un certificato, Certificate Manager 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 che hai dimostrato di avere il controllo dei domini di destinazione.
Dopo aver ottenuto le autorizzazioni necessarie, puoi richiedere certificati validi solo per un periodo di tempo specifico. Trascorso questo periodo di tempo, 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 verifica prevede la creazione di un file in una posizione nota su un server HTTP (porta 80) per il recupero e la verifica da parte della Public CA. Per ulteriori informazioni, consulta la pagina Verifica HTTP.
Sfida TLS-Application Layer Protocol Negozi (ALPN). Richiede che un server fornisca un certificato specifico durante una negoziazione TLS sulla porta 443 per dimostrare il controllo di un dominio. Per ulteriori informazioni, consulta 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 l'inclusione in un certificato solo dei nomi di dominio convalidati. Se utilizzi la verifica DNS, il client può anche richiedere l'inclusione in un certificato dei sottodomini di quel nome di dominio.
Ad esempio, se convalidi *.myorg.example.com utilizzando la verifica DNS,
subdomain1.myorg.example.com e subdomain2.myorg.example.com vengono automaticamente coperti
dal certificato con caratteri jolly. Tuttavia, se convalidi myorg.example.com con una verifica HTTP o TLS-ALPN, il client può richiedere solo di includere myorg.example.com nel 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 località dipende dalla sfida.
- Il client indica alla Public CA di aver preparato la sfida.
- La Public CA controlla se il token presente nella località prevista corrisponde al valore previsto.
Il nome di dominio viene autorizzato al termine del processo. Il client può richiedere un certificato con quel nome di dominio. Devi risolvere una sola sfida per nome di dominio.