Gestore certificati utilizza un meccanismo di mappatura flessibile che offre un controllo granulare sui certificati che puoi assegnare e sulla modalità di gestione 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:
Gestore certificati supporta i proxy HTTPS di destinazione e i proxy SSL di destinazione. Per ulteriori informazioni sulle differenze tra questi tipi di proxy, consulta Utilizzo dei proxy di destinazione.
Per informazioni sui tipi di certificato 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, esegui il provisioning e rinnovi autonomamente.
Quando emetti un certificato utilizzando una CA attendibile pubblicamente, la CA pubblica informazioni sul dominio associato nei log di Certificate Transparency, 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 Certificate Authority Service per emettere il certificato gestito da Google, Gestore 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 siti web e applicazioni può essere un'attività complessa e dispendiosa in termini di tempo che spesso prevede la configurazione manuale e una manutenzione regolare. Gestore certificati è un servizio progettato per aiutarti a semplificare questo processo fornendo una piattaforma centralizzata. Puoi delegare a Gestore certificati la responsabilità di emettere e rinnovare i certificati, liberando tempo da dedicare ad altre attività critiche.
Puoi verificare la proprietà del dominio pertinente utilizzando l'autorizzazione basata su bilanciatore del carico o DNS. Gestore certificati supporta i certificati RSA gestiti da Google.
Per impostazione predefinita, la CA di Google emette certificati gestiti da Google. Quando un nuovo certificato gestito da Google viene emesso o rinnovato, utilizza una chiave privata appena generata. Se non riesci a ottenere un certificato dalla CA di Google per un determinato dominio, Certificate Manager utilizza la CA Let's Encrypt. Ad esempio, la CA di Google potrebbe rifiutarsi di emettere un certificato per il dominio oppure il record di autorizzazione della CA impedisce in modo esplicito 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 certificati gestiti da Google.
Tieni presente che i certificati gestiti da Google a livello di regione (Anteprima) supportano solo l'autorizzazione basata su DNS e ricevono certificati dalla CA 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 certificati, puoi configurare Gestore certificati in modo che utilizzi un pool di CA da Certificate Authority Service come emittente del certificato. Per ulteriori informazioni 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 associate. Sei responsabile dell'emissione e del rinnovo manuale dei 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 dei 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 il riutilizzo 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 pubblica il certificato principale. Per saperne di più, consulta Logica di selezione dei certificati.
Voci della mappa di certificati
Una voce della mappa di certificati è un elenco di certificati forniti per un nome di dominio specifico. Puoi definire diversi insiemi di certificati per nomi di dominio diversi, ad esempio 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 al nome di dominio, negozia il tipo di certificato da pubblicare per il client durante l'handshake.
Autorizzazioni per il dominio
Gestore certificati ti consente di dimostrare la proprietà dei domini per i quali vuoi emettere certificati gestiti da Google, come descritto nella seguente tabella.
| 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 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 ha gestito 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 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 di emissione di 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 al posto della CA Google o della CA Let's Encrypt. Consente di specificare un numero 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 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 l'archivio di attendibilità, l'ancoraggio e le entità di certificato intermedie.
Archivi di attendibilità
Un archivio di attendibilità rappresenta la configurazione del secret di attendibilità in Gestore certificati per l'utilizzo 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 (mTLS). È incapsulato all'interno di un archivio di attendibilità.
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à incapsulante per l'utilizzo in scenari di autenticazione TLS reciproca (mTLS).
Uno o più certificati intermedi possono essere incapsulati all'interno di 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 nella valutazione dell'attendibilità per ogni richiesta di connessione, oltre all'elenco dei certificati intermedi specificati nella richiesta stessa.
Certificati consentiti
Un certificato nella lista consentita rappresenta qualsiasi certificato che può essere incapsulato all'interno della configurazione di attendibilità in modo che venga sempre considerato valido. Un certificato nella lista consentita è sempre considerato valido, purché sia analizzabile, venga stabilita una prova del possesso di una chiave privata e vengano soddisfatti i vincoli per il campo SAN del certificato. Anche i certificati scaduti sono considerati validi quando sono inseriti nella lista consentita. Non è necessario un archivio di attendibilità quando utilizzi i certificati inclusi nella lista consentita.
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 utilizzabili 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 dei certificati di cui è stato eseguito il provisioning, il bilanciatore del carico seleziona il certificato corrispondente.
Corrispondenza nome host con caratteri jolly: se il nome host del client non corrisponde a nessuna voce, ma corrisponde a un nome host con caratteri jolly in una voce della 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 una voce della mappa del certificato 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 corrispondente di cui è stato eseguito il provisioning.
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 specificati 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 della mappa di certificati principale corrispondente o non hai configurato una voce della 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 che si connette supporta i certificati ECDSA più sicuri, il bilanciatore del carico li assegna la priorità ai certificati RSA. Se il client non indica il supporto per i certificati ECDSA, il bilanciatore del carico pubblica un certificato RSA.
- Dimensioni certificato. Il bilanciatore del carico dà 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 quelli 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 sul carattere jolly se entrambi sono definiti nella voce. Ad esempio, se hai configurato le voci della mappa dei certificati per
www.myorg.example.come*.myorg.example.com, una richiesta di connessione perwww.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 dei certificati per*.myorg.example.com, ma non perhost1.hosts.myorg.example.com.
Public CA
Per utilizzare la funzionalità CA pubblica di Gestore certificati, è necessario conoscere i seguenti concetti:
Cliente 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 di account esterna (EAB) per funzionare con la CA pubblica.
Associazione di account esterna (EAB). Devi associare ogni account ACME che utilizzi con la CA pubblica di Gestore certificati al progetto Google Cloud di destinazione utilizzando l'associazione di account esterna. Per farlo, devi registrare ogni account ACME utilizzando un secret collegato al progetto Google Cloud corrispondente. Per saperne di più, consulta Associazione di account esterni.
Sfide Public CA
Quando utilizzi una Public CA per richiedere un certificato, Gestore certificati ti chiede di dimostrare che hai il controllo sui domini elencati nel certificato. Puoi dimostrare il controllo del dominio risolvendo alcuni problemi. 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 richieste, puoi richiedere certificati che siano validi solo per un periodo di tempo specifico. Dopo questa durata, 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. Questo test prevede la creazione di un file in una posizione nota su un server HTTP (porta 80) affinché la Public CA possa recuperare e verificare. Per ulteriori informazioni, consulta la sezione Verifica HTTP.
Verifica TLS-Application Layer Protocol Negoziazione (ALPN). Richiede che un server fornisca un certificato specifico durante una negoziazione TLS sulla porta 443 per dimostrare il controllo su 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 Verifica DNS.
Se utilizzi il test HTTP o TLS-ALPN per convalidare un nome di dominio, il client può richiedere solo l'inclusione dei nomi di dominio convalidati in un certificato. Se utilizzi il test DNS, il client può anche richiedere l'inclusione dei sottodomini di quel 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 saranno automaticamente coperti dal certificato con caratteri 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.
Logica della soluzione delle sfide
La logica di challenge della CA pubblica è la seguente:
- Public CA fornisce un token casuale.
- Il client rende il token disponibile in una posizione ben definita. La posizione dipende dalla sfida.
- Il cliente comunica alla Public CA che ha preparato la sfida.
- La Public CA verifica se il token presente nella posizione prevista corrisponde al valore previsto.
Il nome di dominio viene autorizzato al termine di questo processo. Il client può richiedere un certificato con quel nome di dominio. Devi risolvere una sola verifica per nome di dominio.