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 target specificato in una regola di inoltro del bilanciatore del carico:
Gestore certificati supporta i proxy HTTPS di destinazione e SSL di destinazione proxy. Per ulteriori informazioni sulle differenze tra questi tipi di proxy, consulta Utilizzo dei 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 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 ottiene e gestisce 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 Certificate Authority Service per emettere il certificato gestito da Google, Gestore certificati non pubblica informazioni in 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
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. Certificate Manager è un servizio progettato per aiutarti a semplificare questa procedura fornendo una piattaforma centralizzata. Puoi delegare la responsabilità dell'emissione e del rinnovo dei certificati a Gestore certificati, che ti permette di risparmiare tempo per concentrarti su attività critiche.
Puoi verificare la proprietà del dominio pertinente utilizzando soluzioni basate su bilanciatore del carico Autorizzazione basata su DNS. Gestore certificati supporta RSA Certificati gestiti da Google.
Per impostazione predefinita, la CA di Google emette certificati gestiti da Google. Quando un nuovo Il certificato gestito da Google viene emesso o rinnovato, utilizza un nuovo certificato chiave privata. 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. 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 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é affidarti alle CA pubbliche affinché emettano i certificati, puoi configurare Gestore certificati per utilizzare un pool di CA 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 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. È 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. 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 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 dei 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 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 tabella.
| 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 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 a 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 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. 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) in Gestore certificati per l'utilizzo 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 (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 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 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
Se vuoi utilizzare un certificato autofirmato, scaduto o altrimenti non valido oppure se non hai accesso ai certificati radice e intermedi, puoi aggiungere il certificato alla configurazione attendibilità nel 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 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 di 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 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 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 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 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 solo a un 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 client di 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 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 secret collegato al progetto Google Cloud corrispondente. Per ulteriori informazioni, consulta la sezione Associazione di account esterni.
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 CA pubblica 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 che siano validi solo per un periodo di tempo specifico. Al termine di questo periodo, per continuare a richiedere certificati, devi 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 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, consulta Estensione della verifica ACME TLS-ALPN.
Verifica DNS. Richiede l'aggiunta di un record DNS specifico in una località definita per dimostrare il controllo di un dominio. Per ulteriori informazioni, vedi Verifica DNS.
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 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 della verifica
La logica di verifica della CA pubblica è la seguente:
- La CA pubblica fornisce un token casuale.
- Il client rende disponibile il token in una posizione ben definita. La posizione dipende dalla sfida.
- Il cliente indica all'autorità di certificazione pubblica di aver preparato la verifica.
- 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 contenente il nome di dominio. Devi risolvere un solo elemento per ogni nome di dominio.