Certificate Manager utilizza un meccanismo di mappatura flessibile che ti offre un controllo granulare sui certificati che puoi assegnare e su come gestirli per ogni nome di dominio nel tuo ambiente. Il meccanismo include le seguenti entità:
- Certificati
- Mappe di certificati
- Voci della mappa dei certificati
- Autorizzazioni di dominio
Il seguente diagramma illustra le relazioni tra queste entità per un tipico proxy target specificato in una regola di inoltro del bilanciatore del carico:
Certificate Manager supporta i proxy HTTPS di destinazione e i proxy SSL di destinazione. Per ulteriori informazioni sulle differenze tra questi tipi di proxy, consulta Utilizzare i proxy di destinazione.
Per informazioni sui tipi di certificati supportati da Certificate Manager, consulta la Panoramica del deployment.
Certificati
Per impostazione predefinita, un certificato rappresenta un singolo certificato (SSL) X.509 Transport Layer Security (TLS) emesso per nomi o caratteri jolly di dominio specifici.
Certificate Manager supporta i seguenti tipi di certificati:
- I certificati gestiti da Google sono certificati che Google Cloud vengono ottenuti e gestiti per te.
- I certificati con gestione indipendente sono certificati che ottieni, esegui il provisioning e rinnova autonomamente.
Quando emetti un certificato utilizzando un'autorità di certificazione attendibile pubblicamente, l'autorità di certificazione pubblica informazioni sul dominio associato nei log Certificate Transparency, che sono accessibili pubblicamente. Questo fa parte della procedura standard di emissione dei certificati adottata da tutte le CA attendibili pubblicamente e si applica sia ai certificati gestiti da Google sia a quelli autogestiti. Tuttavia, se utilizzi il servizio dell'autorità di certificazione per emettere il certificato gestito da Google, Gestore dei 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 Certificate Manager, consulta la 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 richiede la configurazione manuale e la manutenzione regolare. Certificate Manager è un servizio progettato per aiutarti a semplificare questa procedura fornendo una piattaforma centralizzata. Puoi delegare la responsabilità di emettere e rinnovare i certificati a Certificate Manager, liberandoti del tempo da dedicare ad altre attività critiche.
Puoi verificare la proprietà del dominio pertinente utilizzando l'autorizzazione basata su bilanciatori del carico o su DNS. Gestore certificati supporta i certificati RSA gestiti da Google.
Per impostazione predefinita, la CA 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 Google per un determinato dominio, Gestore dei certificati utilizza l'autorità di certificazione Let's Encrypt. Ad esempio, l'autorità di certificazione Google potrebbe rifiutarsi di emettere un certificato per il dominio oppure il tuo record di autorizzazione dell'autorità di certificazione potrebbe vietare esplicitamente all'autorità di certificazione Google di emettere certificati per quel dominio.
L'autenticazione solo lato client non è supportata.
Per istruzioni su come limitare le CA che possono emettere certificati per i tuoi domini, consulta Specificare le CA che possono emettere il certificato gestito da Google.
Tieni presente che i certificati gestiti a livello di regione da Google supportano solo l'autorizzazione basata su DNS e ottengono i certificati dall'autorità di certificazione Google.
Certificati gestiti da Google emessi da Certificate Authority Service
Se vuoi utilizzare la tua catena di attendibilità anziché fare affidamento su CA pubbliche approvate da Google per emettere i tuoi certificati, puoi configurare Gestore dei certificati in modo che utilizzi un pool di CA di Certificate Authority Service come emittente del certificato. Per saperne di più sui pool di CA, consulta Creare pool di CA.
Certificati autogestiti
Se i requisiti della tua attività non ti consentono di utilizzare i certificati gestiti da Google, puoi caricare i certificati emessi da CA esterne insieme alle relative chiavi associate. Sei responsabile del rilascio e del rinnovo manuale dei certificati autogestiti.
Certificate Manager ti consente anche di eseguire il deployment di certificati autogestiti regionali su proxy Secure Web Proxy e bilanciatori del carico regionali.
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 dei certificati definiscono anche la logica di selezione seguita dal bilanciatore del carico durante l'instaurazione delle connessioni dei client. Puoi associare una mappa dei certificati a più proxy di destinazione per il riutilizzo su 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 pubblica il certificato principale. Per ulteriori informazioni, consulta la Logica di selezione dei certificati.
Voci della mappa dei certificati
Una voce mappa di certificati è un elenco di certificati pubblicati per un nome di dominio specifico. Puoi definire insiemi diversi di certificati per nomi di dominio diversi, come domini o sottodomini. Ad esempio, puoi caricare un certificato ECDSA e un certificato RSA e mapparli allo stesso nome di dominio. Quando un client si connette a questo nome di dominio, il bilanciatore del carico negozia il tipo di certificato da fornire al client durante l'handshake.
Autorizzazioni di dominio
Certificate Manager ti 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à di configurazione | Non richiede ulteriori passaggi di configurazione o modifiche alla configurazione DNS. | Richiede la creazione di un'autorizzazione DNS e l'aggiunta del corrispondente record CNAME 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 pubblicati dal certificato. Non funziona con altre configurazioni. | Funziona con configurazioni di elevata complessità, ad esempio porte diverse dalla porta 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 per gestire il traffico di rete. |
Per capire in che modo Certificate Manager 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 di emissione dei certificati è una risorsa che consente a Certificate Manager di utilizzare un pool di CA dalla tua istanza di Certificate Authority Service per emettere certificati gestiti da Google anziché dalla CA Google o dalla CA Let's Encrypt. Ti consente di specificare una serie di parametri che regolano l'emissione e la scadenza dei certificati, nonché di selezionare l'algoritmo della 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 attendibilità, che a sua volta incapsula un trust anchor e, facoltativamente, uno o più certificati intermedi.
Per saperne di più sull'autenticazione TLS reciproca, consulta Autenticazione TLS reciproca nella documentazione di Cloud Load Balancing.
Una risorsa di configurazione dell'attendibilità incapsula le entità dell'archivio di attendibilità, del trust anchor e del certificato intermedio.
Archivi di attendibilità
Un archivio attendibilità rappresenta la configurazione del secret attendibilità in Gestore certificati da utilizzare in scenari di autenticazione TLS reciproca. Incapsula un singolo trust anchor e, facoltativamente, uno o più certificati intermedi.
Trust anchor
Un'ancora di attendibilità rappresenta un singolo certificato radice da utilizzare negli scenari di autenticazione TLS reciproca. È incapsulato in un archivio attendibilità.
Certificati intermedi
Un certificato intermedio rappresenta un singolo certificato intermedio firmato da un certificato radice o un certificato intermedio a cui si fa riferimento nell'archivio di attendibilità incapsulante da utilizzare negli scenari di autenticazione TLS reciproca.
Uno o più certificati intermedi possono essere incapsulati in un archivio attendibilità, a seconda della configurazione della PKI. Tutti i certificati intermedi specificati all'interno di una configurazione della attendibilità sono inclusi nell'ambito della valutazione della attendibilità per ogni richiesta di connessione, oltre all'elenco dei certificati intermedi specificati nella richiesta stessa.
Certificati che richiedono una lista consentita
Se necessario, se devi utilizzare un certificato autofirmato, scaduto o altrimenti non valido oppure se non hai accesso ai certificati radice e intermedi, puoi aggiungerlo alla configurazione attendibilità nel campo allowlistedCertificates. Non è necessario un archivio di attendibilità
per aggiungere un certificato a una lista consentita.
L'aggiunta di un certificato alla lista consentita significa che il certificato viene sempre considerato valido purché sia possibile analizzarlo, sia stata stabilita la prova del possesso della chiave privata e siano soddisfatti i vincoli relativi al 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 di crittografia 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 dei certificati configurate. I fattori che determinano il certificato 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 dei certificati di cui è stato eseguito il provisioning, il bilanciatore del carico seleziona il certificato corrispondente.
Corrispondenza dell'hostname con caratteri jolly: se l'hostname del client non corrisponde a nessuna voce, ma corrisponde a un hostname con caratteri jolly in una voce della mappa dei certificati, il bilanciatore del carico seleziona il certificato corrispondente da quella voce. Ad esempio, una voce con caratteri jolly configurata come
*.myorg.example.comcopre i sottodomini di primo livello del dominiomyorg.example.com.Nessuna corrispondenza del nome host e una voce della mappa di certificati principale preconfigurata: il bilanciatore del carico seleziona una voce della mappa di certificati principale preconfigurata in assenza di una corrispondenza del nome host o di una voce della mappa di certificati provisionata corrispondente.
Errore di handshake: l'handshake non riesce 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.
- Non è stata trovata una voce mappa di certificati principale corrispondente o non hai configurato una voce mappa di certificati principale.
Priorità del certificato
Il bilanciatore del carico seleziona un certificato all'interno di una voce della mappa di certificati in base a quanto segue:
- Tipo di certificato. Se il client in connessione supporta i certificati ECDSA più sicuri, il bilanciatore del carico li dà la priorità rispetto ai certificati RSA. Se il client non indica il supporto dei certificati ECDSA, il bilanciatore del carico serve un certificato RSA.
- Dimensioni del certificato. Il bilanciatore del carico dà la priorità ai certificati dal più piccolo al più grande.
Nomi di dominio con caratteri jolly
Ai nomi di dominio jolly si applicano le seguenti regole:
- Solo i certificati gestiti da Google con autorizzazione DNS e i certificati gestiti da Google con il servizio CA supportano i nomi di dominio con caratteri jolly. I certificati gestiti da Google con autorizzazione del bilanciatore del carico non supportano i 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 di mappatura dei 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 solo a un livello di sottodominio. Ad esempio, una richiesta di connessione per
host1.myorg.example.comseleziona una voce della mappa dei certificati per*.myorg.example.com, ma non perhost1.hosts.myorg.example.com.
CA pubblica
Per utilizzare la funzionalità CA pubblica di Certificate Manager, devi conoscere i seguenti concetti:
Client ACME. Un client ACME (Automatic Certificate Management Environment) è un client di gestione dei certificati che utilizza il protocollo ACME. Il client ACME deve supportare l'associazione account esterno (EAB) per funzionare con la CA pubblica.
Associazione account esterno (EAB). Devi associare ogni account ACME che utilizzi con la CA pubblica di Certificate Manager al progetto Google Cloud di destinazione utilizzando l'associazione dell'account esterno. Per farlo, devi registrare ogni account ACME utilizzando un segreto collegato al progetto Google Cloud corrispondente. Per ulteriori informazioni, consulta la sezione Associazione di account esterni.
Sfide delle CA pubbliche
Quando utilizzi un'autorità di certificazione pubblica per richiedere un certificato, Gestione certificati ti chiede di dimostrare il tuo controllo sui domini elencati nel certificato. Puoi dimostrare il controllo del dominio risolvendo le sfide. La CA pubblica autorizza i nomi di dominio dopo che hai dimostrato di avere il controllo dei domini di destinazione.
Dopo aver ottenuto le autorizzazioni richieste, puoi richiedere certificati validi solo per un determinato periodo di tempo. Al termine di questo periodo, per continuare a richiedere certificati, dovrai convalidare nuovamente il nome di dominio risolvendo uno dei tre tipi di verifica.
Tipi di verifica dell'accesso
La CA pubblica supporta i seguenti tipi di verifiche:
Sfida HTTP. Questa verifica prevede la creazione di un file in una posizione ben nota su un server HTTP (porta 80) da recuperare e verificare dall'Autorità di certificazione pubblica. Per ulteriori informazioni, consulta la sezione Autenticazione HTTP.
Sfida TLS-Application Layer Protocol Negotiation (ALPN). Richiede a un server di fornire un certificato specifico durante una negoziazione TLS sulla porta 443 per dimostrare il controllo su un dominio. Per ulteriori informazioni, consulta Estensione della verifica ACME TLS-ALPN.
DNS challenge. Richiede l'aggiunta di un record DNS specifico in una posizione definita per dimostrare il controllo su un dominio. Per ulteriori informazioni, vedi DNS challenge.
Se utilizzi la verifica HTTP o la verifica TLS-ALPN per convalidare un nome di dominio, il client può richiedere solo che i nomi di dominio convalidati vengano inclusi in un certificato. Se utilizzi la verifica DNS, il cliente può anche richiedere l'inclusione dei sottodomini del nome di dominio in un 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 jolly. Tuttavia, se convalidi myorg.example.com utilizzando 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.*.myorg.example.com
Logica della soluzione della verifica
La logica della verifica CA pubblica è la seguente:
- La CA pubblica fornisce un token casuale.
- Il client rende il token disponibile in una posizione ben definita. La posizione dipende dalla sfida.
- Il cliente indica all'autorità di certificazione pubblica di aver preparato la verifica.
- La CA pubblica controlla se il token presente nella posizione prevista corrisponde al valore previsto.
Il nome di dominio viene autorizzato al termine di questa procedura. Il cliente può richiedere un certificato contenente il nome di dominio. Devi risolvere una sola verifica per nome di dominio.