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 che il server si autentichino a vicenda verificando che ciascuno disponga di un certificato valido emesso da un'autorità di certificazione (CA) attendibile. A differenza di TLS standard, in cui viene autenticato solo il server, mTLS richiede che il client e il server presentino certificati, confermando le identità di entrambe le parti prima che venga stabilita la comunicazione.

mTLS è configurato sulla 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 entità 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 client che presenta il certificato possieda la chiave privata.

• Convalida i certificati client in una delle due modalità:

  • Rifiuta i certificati non validi: applica un'autenticazione rigorosa rifiutando le richieste se la catena di certificati client non può essere convalidata.

  • Consenti certificati non validi o mancanti: offre flessibilità passando tutte le richieste al backend, anche se un certificato client è mancante o non valido.

• Convalida i certificati client rispetto a un ancoraggio PKI caricato (certificato radice), con la possibilità di aggiungere più ancoraggi separatamente per consentire la migrazione senza problemi da una PKI precedente a una nuova senza tempi di inattività.

• Fornisci certificati intermedi aggiuntivi per contribuire a creare il percorso di convalida del certificato client in base agli ancoraggi PKI specificati (certificati radice). Questi certificati intermedi consentono a mTLS di funzionare con client che non forniscono la catena di certificati completa.

• Genera e trasmetti un'impronta del certificato al backend come intestazione della richiesta personalizzata.

• Trasferisci al backend i campi selezionati estratti dal certificato utilizzando intestazioni personalizzate.

• Trasferisci il risultato della convalida e gli eventuali errori di convalida al backend utilizzando intestazioni personalizzate.

Requisiti di certificato

Quando configuri i certificati per mTLS, assicurati che rispettino i seguenti requisiti:

• Gli strumenti di crittografia moderni costituiscono la base dell'autenticazione mTLS. I certificati devono utilizzare gli algoritmi RSA o ECDSA per lo scambio di chiavi. Gli algoritmi di hashing devono utilizzare SHA-256 o una funzione hash crittografica più sicura. Gli algoritmi di hashing come MD4, MD5 e SHA-1 non sono supportati.
• Per i certificati client (foglia):
  • L'estensione Basic Constraints 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 Basic Constraints deve contenere CA=true.
  • L'estensione Utilizzo 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 dell'attendibilità, che contiene un archivio 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 di archivio di 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 saperne di più, consulta Configurazioni attendibilità.

  Se vuoi utilizzare un certificato autofirmato, scaduto o altrimenti non valido oppure se non hai accesso ai certificati radice e intermedi, puoi aggiungerlo alla configurazione di attendibilità nel campo allowlistedCertificates. Non hai bisogno di un archivio attendibile per aggiungere un certificato a una lista consentita.

  L'aggiunta di un certificato all'allowlist significa che il certificato è sempre considerato valido, a condizione che sia analizzabile, che sia stata stabilita la prova del possesso della chiave privata e che siano soddisfatti i vincoli del campo SAN del certificato.

• Archivio di attendibilità. Contiene i certificati dell'autorità di certificazione (CA) trust anchor e intermedi 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 dal trust anchor (certificato radice) del bilanciatore del carico o dai certificati CA intermedi.

  Puoi caricare i seguenti tipi di certificati radice e intermedi nell'archivio attendibile:

  • Certificati emessi da CA di terze parti a tua scelta.
  • Certificati emessi da CA private sotto il tuo controllo, come descritto in Configurare TLS reciproco con una CA privata.
  • Certificati forniti dall'utente, come descritto in Configurare TLS reciproca 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 per la convalida dei 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.

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 di autenticazione 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 è riuscita o non è stato presentato alcun certificato client. In questa modalità, il bilanciatore del carico consente la connessione dal client e passa tutte le richieste al backend indipendentemente dal fatto che sia possibile o meno stabilire una catena di attendibilità.

  La prova del possesso della chiave privata viene sempre verificata quando viene presentato il certificato client. Se il client non può dimostrare il possesso della 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 dal client se non riesce a stabilire una catena di attendibilità dal certificato client al trust anchor.

Configura mTLS sul bilanciatore del carico

Di seguito è riportata una panoramica generale dei passaggi chiave da seguire per configuraremTLSS reciproca sul bilanciatore del carico:

1. Crea una risorsa di configurazione dell'attendibilità che comprenda il trust anchor (certificato radice) e i certificati intermedi che fungono da radici di attendibilità.

2. Collega la configurazione di attendibilità alla risorsa di autenticazione client (ServerTLSPolicy), che definisce la modalità di convalida del client di 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 trasferire informazioni sulla connessione mTLS a un servizio di backend o a una mappa URL.

Per saperne di più su questa configurazione, consulta le seguenti guide:

• Configurare TLS reciproco con certificati forniti dall'utente
• Configurare TLS reciproco con una CA privata

Passaggi di convalida del certificato client

Durante la convalida del certificato client, il bilanciatore del carico esegue le seguenti operazioni:

1. Verifica che il client disponga della chiave privata.

   Il client dimostra di possedere la chiave privata associata alla chiave pubblica nel certificato generando una firma durante il processo di handshake. Il bilanciatore del carico verifica questa firma utilizzando la chiave pubblica del client. Se la verifica della firma non riesce, significa che il client non è il proprietario del certificato, nel qual 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 i bilanciatori del carico delle applicazioni interni.

2. Verifica la catena di attendibilità.

   Il bilanciatore del carico verifica la catena di attendibilità tra il certificato 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 Oggetto nel certificato principale corrisponde al campo Emittente nel certificato secondario. Questa verifica garantisce che l'identità (soggetto) del certificato padre sia la stessa dell'identità elencata come emittente nel certificato figlio.
   • 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 utilizzata nell'AKID per verificare la validità del certificato.
   • Il nome alternativo del soggetto (SAN) di un certificato secondario non viola il campo NameConstraints nel certificato principale.

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 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 alle intestazioni mTLS personalizzate, puoi configurare i campi facoltativi mTLS per controllare il motivo dell'errore.

   • REJECT_INVALID: la connessione viene terminata e gli errori vengono registrati in Cloud Logging.

Intestazioni mTLS personalizzate trasmesse al backend

La tabella seguente mostra le variabili di intestazione mTLS personalizzate che possono essere trasmesse al backend, sia quando il certificato client supera la convalida sia quando non la supera. Se la convalida del certificato client non riesce, le richieste vengono trasmesse al backend solo quando la modalità di convalida del client è impostata su ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Queste variabili possono essere impostate anche nella mappa URL.

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 certificato client o intermedio utilizza un algoritmo non RSA, 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>
La PKI 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 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. Il numero massimo di iterazioni è 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 riesce rispetto alla 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 programma di verifica 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>

Analizza i valori delle variabili di intestazione personalizzata passati al backend

Alcuni valori delle variabili di intestazione mTLS personalizzate sono rappresentazioni di stringhe con codifica Base64 di dati binari del certificato Distinguished Encoding Rules (DER). Puoi decodificare le stringhe codificate in Base64 utilizzando gli strumenti o le librerie software che preferisci. Di seguito sono riportati alcuni esempi:

• I sistemi macOS e Linux possono utilizzare lo strumento a riga di comando base64, un'utilità di base inclusa in entrambi i sistemi operativi. Per decodificare le stringhe codificate Base64 utilizzando l'utilità base64, passa la stringa codificata come input standard al comando base64 e utilizza il flag -d per decodificare la stringa come segue:

  echo BASE_64_ENCODED_STRING | base64 -d
  

• Python include il modulo base64, che può essere utilizzato per decodificare le stringhe codificate Base64 nel seguente modo:

  import base64
  encoded_string=BASE_64_ENCODED_STRING
  decoded_string=base64.b64decode(encoded_string).decode()
  print(decoded_string) # Note that a newline character (\n) is added to the end of the string.
  

Gestione degli errori e logging

I bilanciatori del carico delle applicazioni forniscono 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 descrive 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 certificato client o intermedio utilizza un algoritmo non RSA o non ECDSA. Non viene eseguita alcuna convalida.	client_cert_unsupported_key_algorithm
La PKI 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 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 corrispondenza della firma del certificato client non riesce durante l'handshake.	Termina 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 la registrazione è abilitata 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 di attendibilità con un singolo archivio di attendibilità, che contiene al massimo: 200 tra trust anchor e certificati intermedi (il numero di certificati intermedi è limitato a 100) e 500 certificati aggiunti a una lista consentita. Tutti i certificati intermedi non devono avere più di tre certificati che condividono le stesse informazioni su soggetto e chiave pubblica del soggetto. 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 trasferiti dal client sono limitate a quanto segue:

  • Le chiavi RSA possono variare da 2048 a 4096 bit. Per maggiori 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.

• I Google Front End (GFE) di livello 1 impongono un timeout non configurabile di 10 secondi per la presentazione del certificato da parte del client durante l'handshake TLS. In condizioni di carico di picco, questo timeout potrebbe essere più breve. I client devono completare la presentazione del certificato entro questo periodo di tempo per stabilire correttamente una connessione mTLS.

Passaggi successivi

• Configurare TLS reciproco con certificati forniti dall'utente

• Configurare TLS reciproco con una CA privata

• Variabili che possono essere visualizzate nel valore dell'intestazione