TLS reciproco, o mTLS, è un protocollo standard di settore per l'autenticazione reciproca tra un client e un server. Garantisce che sia il client sia il server si autentichino tra loro verificando che ciascuno detenga un certificato valido emesso da un'autorità di certificazione (CA) attendibile. A differenza del TLS standard, in cui viene autenticato solo il server, mTLS richiede che sia il client sia il server presentino certificati, confermando le identità di entrambe le parti prima che la comunicazione sia stabilita.
mTLS è configurato nella risorsa proxy HTTPS di destinazione di tutti i bilanciatori del carico delle applicazioni:
- Bilanciatore del carico delle applicazioni esterno globale
- Bilanciatore del carico delle applicazioni classico
- Bilanciatore del carico delle applicazioni esterno regionale
- Bilanciatore del carico delle applicazioni interno regionale
- Bilanciatore del carico delle applicazioni interno tra regioni
mTLS utilizza l'infrastruttura a chiave pubblica (PKI) per autenticare l'identità delle persone che comunicano sulla rete. L'infrastruttura include tre componenti: un client, un server e un'autorità di certificazione (CA). mTLS per i bilanciatori del carico supporta le seguenti funzionalità:
Verifica che il cliente che presenta il certificato possieda la relativa chiave privata.
Convalida i certificati client in una delle due modalità:
Rifiuta certificati non validi: applica l'autenticazione rigorosa rifiutando le richieste se non è possibile convalidare la catena di certificati client.
Consenti certificati non validi o mancanti: offre flessibilità in quanto consente di passare tutte le richieste al backend, anche se un certificato client è mancante o non valido.
Convalida i certificati client in base a un'ancora PKI (certificato radice) caricata, con la possibilità di aggiungere più ancore separatamente per consentire la migrazione senza problemi da una vecchia PKI a una nuova senza tempi di inattività.
Fornisci certificati intermedi aggiuntivi per contribuire a creare il percorso di convalida del certificato client rispetto agli ancoraggi PKI (certificati radice) specificati. Questi certificati intermedi consentono a mTLS di funzionare con i client che non forniscono la catena di certificati completa.
Genera e passa un'impronta del certificato al backend come intestazione personalizzata della richiesta.
Passa i campi selezionati estratti dal certificato al backend utilizzando intestazioni personalizzate.
Passa il risultato della convalida e gli eventuali errori di convalida al backend utilizzando le intestazioni personalizzate.
Requisiti del certificato
Quando configuri i certificati per mTLS, assicurati che rispettino i seguenti requisiti:
- Gli strumenti di crittografia moderna costituiscono la base dell'autenticazione mTLS. I certificati devono utilizzare algoritmi RSA o ECDSA per lo scambio di chiavi. Gli algoritmi di hashing devono utilizzare SHA-256 o una funzione di hashing crittografica più sicura. Gli algoritmi di hashing come MD4, MD5 e SHA-1 non sono supportati.
- Per i certificati client (a livello di foglia):
- L'estensione Limiti di base
non deve contenere
CA=true
. - L'estensione Utilizzo esteso della chiave deve contenere
clientAuth
. - L'estensione Utilizzo esteso della chiave
non deve contenere i campi
codeSigning
,timeStamping
oOCSPSigning
. - Il certificato non deve essere scaduto.
- Il certificato client non può essere un certificato autofirmato.
- L'estensione Limiti di base
non deve contenere
- Per i certificati radice e intermedi:
- L'estensione Restrizioni di base deve contenere
CA=true
. - L'estensione Utilizzo della chiave deve essere impostata su
keyCertSign
. - L'estensione Utilizzo esteso della chiave deve contenere il campo
clientAuth
. - Il certificato non deve essere scaduto.
- L'estensione Restrizioni di base deve contenere
Architettura di un deployment mTLS
Con mTLS, puoi configurare una risorsa di configurazione della attendibilità, che contiene un magazzino attendibilità. L'archivio di attendibilità incapsula un trust anchor (certificato radice) e, facoltativamente, uno o più certificati intermedi. Quando il bilanciatore del carico riceve un certificato client, lo convalida stabilendo una catena di attendibilità dal certificato client al trust anchor configurato.
Di seguito è riportata una breve panoramica delle diverse risorse che devi configurare per impostare mTLS per il bilanciatore del carico:
Configurazione dell'attendibilità. Contiene una singola risorsa dell'archivio attendibilità, che a sua volta incapsula un trust anchor (certificato radice) e, facoltativamente, uno o più certificati intermedi. La configurazione di attendibilità viene utilizzata per stabilire una catena di attendibilità tra il certificato client e l'ancora di attendibilità. Per ulteriori informazioni, consulta Trust configs.
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 della attendibilità nel campo
allowlistedCertificates
. Non è necessario un elenco attendibile per aggiungere un certificato a una lista consentita.L'aggiunta di un certificato alla lista consentita significa che il certificato è 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.
Archivio attendibilità. Contiene l'ancora di attendibilità e i certificati delle autorità di certificazione (CA) intermedie utilizzati per stabilire una catena di attendibilità e convalidare il certificato client. Una CA viene utilizzata per emettere certificati attendibili per il client. La CA viene identificata dall'ancora di attendibilità del bilanciatore del carico (certificato radice) o dai certificati CA intermedi.
Puoi caricare i seguenti tipi di certificati radice e intermedi nel magazzino attendibilità:
- Certificati emessi da CA di terze parti a tua scelta.
- Certificati emessi da CA private sotto il tuo controllo, come descritto in Configurare TLS mutuale con una CA privata.
- Certificati forniti dall'utente, come descritto in Configurare TLS reciproco con certificati forniti dall'utente.
Autenticazione client (nota anche come
ServerTLSPolicy
). Specifica la modalità di convalida client e la risorsa di configurazione di attendibilità da utilizzare quando convalidi i certificati client. Se il client ha un certificato non valido o non ha nessun certificato per il bilanciatore del carico, la modalità di convalida del client specifica come viene gestita la connessione del client. Puoi specificare tutti i parametri relativi all'autenticazione mTLS nei criteri TLS del server. La risorsa Autenticazione client (ServerTLSPolicy
) è collegata alla risorsa proxy HTTPS di destinazione.
I seguenti diagrammi mostrano i diversi componenti mTLS collegati alla risorsa proxy HTTPS di destinazione dei bilanciatori del carico delle applicazioni globali e regionali.
globale
Il seguente diagramma mostra i componenti di un deployment di bilanciatore del carico delle applicazioni esterno. Questa architettura si applica anche al bilanciatore del carico delle applicazioni interno tra regioni, che è un bilanciatore del carico delle applicazioni interno che utilizza componenti globali.
regionale
Il seguente diagramma mostra i componenti di un deployment di un bilanciatore del carico delle applicazioni interno regionale. Questa architettura si applica anche al bilanciatore del carico delle applicazioni esterno regionale, che è un bilanciatore del carico delle applicazioni esterno che utilizza componenti regionali.
Modalità di convalida client
Se il client ha un certificato non valido o non ha nessun certificato per il bilanciatore del carico, l'attributo clientValidationMode
della risorsa Authentication client (ServerTLSPolicy
) specifica come il bilanciatore del carico gestisce la connessione del client.
I valori della modalità di convalida client sono i seguenti:
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
. Consente la connessione dal client anche se la convalida del certificato client non è andata a buon fine o se non è stato presentato alcun certificato client. In questa modalità, il bilanciatore del carico consente la connessione dal client e inoltra tutte le richieste al backend, indipendentemente dal fatto che sia possibile stabilire o meno una catena di attendibilità.La prova della proprietà della chiave privata viene sempre controllata quando viene presentato il certificato client. Se il client non è in grado di dimostrare di possedere la chiave privata, l'handshake TLS viene terminato anche se la modalità di convalida del client consente un certificato client non valido o mancante.
REJECT_INVALID
. Rifiuta la connessione se un client non fornisce un certificato o se la convalida del certificato non è riuscita. In questa modalità, il bilanciatore del carico termina la connessione proveniente dal client se non riesce a stabilire una catena di attendibilità dal certificato del client al trust anchor.
Configura mTLS sul bilanciatore del carico
Di seguito è riportata una panoramica generale dei passaggi chiave da seguire per configurare mTLS sul bilanciatore del carico:
Crea una risorsa di configurazione attendibilità contenente l'ancora di attendibilità (certificato radice) e i certificati intermedi che fungono da radici di attendibilità.
Collega la configurazione di attendibilità alla risorsa Client Authentication (
ServerTLSPolicy
), che definisce la modalità di convalida del clientALLOW_INVALID_OR_MISSING_CLIENT_CERT
oREJECT_INVALID
.Collega la risorsa di autenticazione client (
ServerTLSPolicy
) alla risorsa proxy HTTPS di destinazione del bilanciatore del carico.(Facoltativo) Puoi utilizzare intestazioni mTLS personalizzate per trasmettere informazioni sulla connessione mTLS a un servizio di backend o a una mappa URL.
Per scoprire di più su questa configurazione, consulta le seguenti guide:
- Configurare TLS reciproco con i certificati forniti dall'utente
- Configurare TLS reciproco con una CA privata
Passaggi per la convalida del certificato client
Durante la convalida del certificato client, il bilanciatore del carico esegue le seguenti operazioni:
Verifica che il cliente possieda la chiave privata.
Il client dimostra di possedere la chiave privata associata alla chiave pubblica nel certificato generando una firma durante la procedura di handshake. Il bilanciatore del carico verifica questa firma utilizzando la chiave pubblica del client. Se la verifica della firma non va a buon fine, significa che il client non è il proprietario del certificato. In questo caso, l'handshake TLS viene terminato anche se la configurazione consente un certificato client non valido o mancante. Non vengono registrati errori per i bilanciatori del carico delle applicazioni esterni globali, ma viene registrato un errore TLS nel campo
proxyStatus
per i bilanciatori del carico delle applicazioni esterni a livello di regione e per i bilanciatori del carico delle applicazioni interni.Verifica la catena di attendibilità.
Il bilanciatore del carico verifica la catena di attendibilità tra il certificato del client e la configurazione di attendibilità configurata. I controlli di verifica includono quanto segue:
- I certificati client, intermedi e radice sono conformi ai requisiti dei certificati.
- Il campo dell'oggetto nel certificato principale corrisponde al campo dell'emittente nel certificato secondario. Questa verifica garantisce che l'identità (soggetto) del certificato principale sia uguale all'identità elencata come emittente nel certificato secondario.
- L'identificatore chiave del soggetto (SKID) del certificato principale corrisponde all'identificatore chiave dell'autorità (AKID) nel certificato secondario. Questa corrispondenza conferma che il certificato secondario è stato emesso dall'autorità radice corretta e che può essere considerato attendibile perché la chiave pubblica della radice viene richiamata nell'AKID per verificare la validità del certificato.
- Il nome alternativo dell'oggetto (SAN) di un certificato secondario non viola il campo
NameConstraints
nel certificato principale.
Inoltra la richiesta al backend.
Se la convalida del certificato client ha esito positivo, la richiesta viene inoltrata al backend utilizzando intestazioni mTLS personalizzate.
Tuttavia, se la convalida non va a buon fine, l'azione intrapresa dipende dal valore della modalità di convalida del client:
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
: la richiesta viene inoltrata con intestazioni mTLS personalizzate che indicano il motivo dell'errore di convalida. Per i bilanciatori del carico delle applicazioni interni tra regioni, i bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni interni regionali, oltre agli intestazioni mTLS personalizzate, puoi configurare i campi facoltativi mTLS per controllare il motivo dell'errore.REJECT_INVALID
: la connessione viene interrotta e gli errori vengono registrati in Cloud Logging.
Intestazioni mTLS personalizzate passate al backend
La tabella seguente mostra gli intestazioni mTLS personalizzate che vengono trasmesse al backend, sia quando il certificato client supera la convalida sia quando non riesce. Se la convalida del certificato client non va a buon fine, le intestazioni personalizzate vengono trasmesse al backend solo quando la modalità di convalida del client è impostata su ALLOW_INVALID_OR_MISSING_CLIENT_CERT
.
Stato del certificato client | Modalità di convalida client | Intestazioni personalizzate |
---|---|---|
La catena di certificati client è troppo lunga (più di 10 certificati intermedi inclusi nel certificato client). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Un client o un certificato intermedio ha una dimensione della chiave RSA non valida. Non viene eseguita alcuna convalida. Le chiavi RSA possono variare da 2048 a 4096 bit. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Un client o un certificato intermedio utilizza una curva ellittica non supportata. Non viene eseguita alcuna convalida. Le curve ellittiche valide sono P-256 e P-384. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Un client o un certificato intermedio utilizza un algoritmo non RSA e non ECDSA. Non viene eseguita alcuna convalida. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
L'infrastruttura a chiave pubblica da utilizzare per la convalida ha più di dieci certificati intermedi che condividono lo stesso oggetto e le stesse informazioni sulla chiave pubblica dell'oggetto. Non viene eseguita alcuna convalida. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Un certificato intermedio fornito per la convalida aveva più di 10 vincoli relativi ai nomi. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Il certificato client non ha un'estensione |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Il limite di tempo è stato superato durante il tentativo di convalidare la catena di certificati. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
client_cert_sha256_fingerprint: <cert hash>
|
È stato raggiunto il limite di profondità o di iterazione durante il tentativo di convalidare la catena di certificati. La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e client. Il numero massimo di iterazioni è 100 (certificati esaminati per convalidare la catena di certificati client). |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Hai configurato mTLS senza impostare una risorsa Non è possibile eseguire la convalida, ma l'hash del certificato viene inoltrato al backend. |
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Nessun certificato client. | ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
La convalida del certificato client non è riuscita per la risorsa
TrustConfig .
|
ALLOW_INVALID_OR_MISSING_CLIENT_CERT
|
|
Il certificato client supera la convalida del verificatore dei certificati. | Non applicabile |
client_cert_error: <empty>
|
Gestione degli errori e registrazione
I bilanciatori del carico delle applicazioni offrono funzionalità di logging dettagliate che ti consentono di monitorare la convalida dei certificati client, identificare potenziali problemi e risolvere i problemi di connessione. Questa sezione illustra i diversi tipi di errori che possono verificarsi durante la convalida mTLS e come vengono registrati.
Errori registrati in modalità REJECT_INVALID
Se la convalida del certificato client non va a buon fine e la modalità di convalida del client è impostata su REJECT_INVALID
, la connessione viene interrotta e gli errori vengono registrati in Cloud Logging. Questi errori sono descritti nella tabella seguente.
Stato del certificato client | Errore registrato |
---|---|
La catena di certificati client è troppo lunga (più di 10 certificati intermedi inclusi nel certificato client). |
client_cert_chain_exceeded_limit
|
Un client o un certificato intermedio ha una dimensione della chiave RSA non valida. Non viene eseguita alcuna convalida. Le chiavi RSA possono variare da 2048 a 4096 bit. |
client_cert_invalid_rsa_key_size
|
Un client o un certificato intermedio utilizza una curva ellittica non supportata. Non viene eseguita alcuna convalida. Le curve valide sono P-256 e P-384. |
client_cert_unsupported_elliptic_curve_key
|
Un client o un certificato intermedio utilizza un algoritmo non RSA o non ECDSA. Non viene eseguita alcuna convalida. |
client_cert_unsupported_key_algorithm
|
L'infrastruttura a chiave pubblica da utilizzare per la convalida ha più di dieci certificati intermedi che condividono lo stesso oggetto e le stesse informazioni sulla chiave pubblica dell'oggetto. Non viene eseguita alcuna convalida. |
client_cert_pki_too_large
|
Un certificato intermedio fornito per la convalida aveva più di 10 vincoli relativi ai nomi. |
|
Il certificato client non ha un'estensione
|
|
Il limite di tempo è stato superato durante il tentativo di convalidare la catena di certificati. |
client_cert_validation_timed_out
|
È stato raggiunto il limite di profondità o di iterazione durante il tentativo di convalidare la catena di certificati. La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e client. Il numero massimo di iterazioni è 100 (certificati esaminati per convalidare la catena di certificati client). |
client_cert_validation_search_limit_exceeded
|
Hai configurato mTLS senza configurare una risorsa TrustConfig .
|
client_cert_validation_not_performed
|
Il client non ha fornito il certificato richiesto durante l'handshake. |
client_cert_not_provided
|
La convalida del certificato client non riesce con la risorsa
TrustConfig .
|
client_cert_validation_failed
|
Errori registrati per le connessioni chiuse
Quando la modalità di convalida del client è impostata su ALLOW_INVALID_OR_MISSING_CLIENT_CERT
o REJECT_INVALID
, determinati errori comportano la chiusura delle connessioni e vengono registrati in Cloud Logging. Questi errori
sono descritti nella tabella seguente.
Stato del certificato client | Richiesta | Errore registrato |
---|---|---|
La firma del certificato client non corrisponde durante l'handshake. | Termina l'handshake SSL | Nessuno |
Il servizio non è in grado di eseguire la convalida della catena di certificati. | Termina connessione |
client_cert_validation_unavailable
|
Errore interno durante la convalida della catena di certificati. | Termina connessione |
client_cert_validation_internal_error
|
TrustConfig corrispondente non trovato.
|
Termina connessione |
client_cert_trust_config_not_found
|
Il payload del certificato client (inclusi eventuali certificati intermedi) è troppo grande (più di 16 KB). | Termina connessione |
client_cert_exceeded_size_limit
|
Se il logging è abilitato nel servizio di backend, puoi visualizzare gli errori registrati per le connessioni chiuse durante la convalida del certificato client mTLS.
Limitazioni
Il bilanciatore del carico non esegue controlli di revoca sui certificati client.
I bilanciatori del carico delle applicazioni ti consentono di caricare una configurazione attendibilità con un singolo archivio di attendibilità contenente al massimo 100 trust anchor e 100 certificati intermedi e 500 certificati aggiunti a una lista consentita. Tutti i certificati intermedi non devono avere più di tre certificati che condividono le stesse informazioni relative a Subject e Subject Public Key. Per ulteriori informazioni, consulta Quote e limiti.
La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e client. Il numero massimo di volte in cui i certificati intermedi possono essere valutati durante il tentativo di creare la catena di attendibilità è 100. Per ulteriori informazioni, consulta Quote e limiti.
Le chiavi dei certificati caricati e trasmessi dal client sono limitate a quanto segue:
- Le chiavi RSA possono variare da 2048 a 4096 bit. Per ulteriori informazioni, consulta Quote e limiti.
- Le chiavi ECDSA possono utilizzare le curve P-256 o P-384.
La catena di certificati accettata ricevuta dal client è limitata a un massimo di 16 KB e 10 certificati. Per ulteriori informazioni, consulta Quote e limiti.
I certificati radice utilizzati per la convalida non possono contenere più di 10 vincoli relativi ai nomi. Per ulteriori informazioni, consulta Quote e limiti.