Panoramica di mutual TLS

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 i 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 ad ancore 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 o OCSPSigning.
  • Il certificato non deve essere scaduto.
  • Il certificato client non può essere un certificato autofirmato.
• 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.

Architettura di un deployment mTLS

Con mTLS, puoi configurare una risorsa di configurazione della attendibilità, che contiene un magazzino della 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 è 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.

Mutual TLS con componenti del bilanciatore del carico delle applicazioni esterno globale (fai clic per ingrandire).

regionale

Il seguente diagramma mostra i componenti di un deployment di 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.

Mutual TLS con componenti del bilanciatore del carico delle applicazioni interno regionale (fai clic per ingrandire).

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 verificata 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 è andata a buon fine. 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:

1. Crea una risorsa di configurazione attendibilità contenente l'ancora di attendibilità (certificato radice) e i certificati intermedi che fungono da radici di attendibilità.

2. Collega la configurazione di attendibilità alla risorsa Client Authentication (ServerTLSPolicy), che definisce la modalità di convalida del client ALLOW_INVALID_OR_MISSING_CLIENT_CERT o REJECT_INVALID.

3. Collega la risorsa di autenticazione client (ServerTLSPolicy) alla risorsa proxy HTTPS di destinazione del bilanciatore del carico.

4. (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:

1. 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 regionali e interni.

2. 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.
   Nota: i certificati client autofirmati non riescono a formare una catena di attendibilità valida e vengono sempre rifiutati.

3. 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 della mancata 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 alle 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	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_exceeded_limit client_cert_sha256_fingerprint: <cert hash>
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	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_invalid_rsa_key_size client_cert_sha256_fingerprint: <cert hash>
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	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_elliptic_curve_key client_cert_sha256_fingerprint: <cert hash>
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	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_unsupported_key_algorithm client_cert_sha256_fingerprint: <cert hash>
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	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_pki_too_large client_cert_sha256_fingerprint: <cert hash>
Un certificato intermedio fornito per la convalida aveva più di 10 vincoli relativi ai nomi.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_max_name_constraints_exceeded client_cert_sha256_fingerprint: <cert hash>
Il certificato client non ha l'estensione Extended Key Usage (EKU) che include clientAuth.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_chain_invalid_eku client_cert_sha256_fingerprint: <cert hash>
Il limite di tempo è stato superato durante il tentativo di convalidare la catena di certificati.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_timed_out client_cert_sha256_fingerprint: <cert hash>
Il limite di profondità o di iterazione viene raggiunto durante il tentativo di convalidare la catena di certificati. La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e client. Le iterazioni massime sono 100 (certificati esaminati per convalidare la catena di certificati client).	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_search_limit_exceeded client_cert_sha256_fingerprint: <cert hash>
Hai configurato mTLS senza configurare una risorsa TrustConfig. Non è possibile eseguire la convalida, ma l'hash del certificato viene inoltrato al backend.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_not_performed client_cert_sha256_fingerprint: <cert hash>
Nessun certificato client.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: false client_cert_chain_verified: false client_cert_error: client_cert_not_provided client_cert_sha256_fingerprint: <empty>
La convalida del certificato client non è riuscita per la risorsa TrustConfig.	ALLOW_INVALID_OR_MISSING_CLIENT_CERT	client_cert_present: true client_cert_chain_verified: false client_cert_error: client_cert_validation_failed client_cert_sha256_fingerprint: <cert hash>
Il certificato client supera la convalida del verificatore dei certificati.	Non applicabile	client_cert_present: true client_cert_chain_verified: true client_cert_error: <empty> client_cert_sha256_fingerprint: <cert hash> client_cert_serial_number: <serial_number> client_cert_valid_not_before: <date> client_cert_valid_not_after: <date> client_cert_uri_sans: <list> client_cert_dnsname_sans: <list> client_cert_issuer_dn: <issuer> client_cert_subject_dn: <subject> client_cert_leaf: <certificate> client_cert_chain: <list>

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.	client_cert_chain_max_name_constraints_exceeded
Il certificato client non ha un'estensione Extended Key Usage (EKU) che includa clientAuth.	client_cert_chain_invalid_eku
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 determinano 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.

Passaggi successivi

• Configurare TLS reciproco con i certificati forniti dall'utente

• Configurare TLS reciproco con una CA privata

• Voci che possono apparire nel valore dell'intestazione