Panoramica di mutual TLS

Mutual TLS, 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 sia in possesso di 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 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 utilizzando una delle modalità di convalida client.

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

• Fornisci certificati intermedi aggiuntivi per facilitare la creazione del percorso di convalida del certificato client rispetto ai trust anchor PKI specificati (certificati radice). Questi certificati intermedi consentono a mTLS di funzionare con i client che non forniscono la catena di certificati completa.

• Genera e passa una fingerprint del certificato al backend come intestazione della richiesta personalizzata.

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

• Passa il risultato della convalida ed eventuali errori di convalida al backend utilizzando intestazioni personalizzate.

Requisiti di certificato

Quando configuri i certificati per mTLS, assicurati che soddisfino questi 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.

  Nota: gli algoritmi di hashing devono utilizzare SHA-256 o una funzione di hash di crittografia più efficace. L'algoritmo di hashing come SHA-1 non è supportato, a meno che la modalità di convalida del client ALLOW_VALIDATION_RELAXATIONS non sia configurata con l'attenuazione ALLOW_SHA1_HASHING, che consente la convalida delle catene di certificati client firmate utilizzando digest dei messaggi SHA-1 legacy. Gli algoritmi di hashing come MD4 e MD5 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.

    Nota: se utilizzi la modalità di convalida del client ALLOW_VALIDATION_RELAXATIONS con l'allentamento ALLOW_MISSING_EKU, il bilanciatore del carico ignora questo requisito. Tuttavia, se il certificato ha un'estensione EKU che elenca un altro scopo (ad esempio serverAuth), ma non clientAuth, la connessione viene rifiutata.

  • L'estensione Extended Key Usage non deve contenere i campi codeSigning, timeStamping o OCSPSigning.

  • Il certificato non deve essere scaduto.

    Nota: se utilizzi la modalità di convalida del client ALLOW_VALIDATION_RELAXATIONS con l'attenuazione ALLOW_EXPIRED_LEAF_CERTIFICATE, il bilanciatore del carico ignora questo requisito.

  • 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 della chiave deve essere impostata su keyCertSign.

  • L'estensione Extended Key Usage deve contenere il campo clientAuth.

  • Il certificato non deve essere scaduto.

Architettura di un deployment mTLS

Con mTLS, puoi configurare una risorsa di configurazione del trust, che contiene un archivio di 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 di attendibilità. Contiene una singola risorsa dell'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 il trust anchor. Per saperne di più, consulta Configurazioni di attendibilità.

  Facoltativamente, se devi utilizzare un certificato autofirmato, scaduto o non valido, o se non hai accesso ai certificati radice e intermedi, puoi aggiungere il certificato alla configurazione di attendibilità nel campo allowlistedCertificates. Non è necessario un archivio di attendibilità per aggiungere un certificato a una lista consentita.

  L'aggiunta di un certificato alla lista consentita significa che il certificato viene sempre considerato valido, a condizione che sia analizzabile, che venga stabilita la prova del possesso della chiave privata e che vengano soddisfatti i vincoli relativi al campo SAN del certificato.

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

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

  • Certificati emessi da CA di terze parti di tua scelta.
  • Certificati emessi da CA private sotto il tuo controllo, come descritto in Configura mutual TLS con una CA privata.
  • Certificati forniti dall'utente, come descritto in Configura mutual TLS 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 nelle policy TLS del server. La risorsa di 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 un 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 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.

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

Modalità di convalida client

L'attributo clientValidationMode della risorsa di autenticazione client (ServerTLSPolicy) specifica il modo in cui il bilanciatore del carico gestisce la connessione client. La modalità determina se i certificati client non validi o mancanti vengono rifiutati rigorosamente (REJECT_INVALID), rifiutati ad eccezione di controlli X.509 specifici meno rigidi (ALLOW_VALIDATION_RELAXATIONS) o inoltrati al backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Le diverse modalità di convalida client sono le seguenti:

• Consenti certificati client non validi o mancanti (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
• Rifiuta i certificati client non validi (REJECT_INVALID)
• Consenti rilassamenti della convalida (ALLOW_VALIDATION_RELAXATIONS)

Consenti certificato client non valido o mancante

La modalità ALLOW_INVALID_OR_MISSING_CLIENT_CERT consente la connessione dal client anche se la convalida del certificato client non va a buon fine o se il client non presenta un certificato. 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 stabilire o meno 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.

Rifiuta certificato client non valido

La modalità 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.

Consenti rilassamenti della convalida

La modalità ALLOW_VALIDATION_RELAXATIONS applica la convalida del certificato client, ma consente di allentare i controlli di convalida specifici, ad esempio durante una migrazione in cui i certificati client legacy non soddisfano tutti i requisiti dei certificati rigorosi. Se hai una risorsa ServerTLSPolicy esistente in modalità REJECT_INVALID, puoi aggiornarla in modo che utilizzi la modalità ALLOW_VALIDATION_RELAXATIONS e specificare l'elenco di attenuazioni della convalida che vuoi consentire.

Nel campo clientValidationRelaxations puoi specificare uno o più dei seguenti valori:

• ALLOW_MISSING_EKU: consente al certificato client di omettere l'estensione Extended Key Usage (EKU).

  ALLOW_MISSING_EKU consente solo un certificato che non ha alcuna estensione EKU; non ignora un'estensione EKU presente con lo scopo sbagliato. Ad esempio, se l'estensione EKU è presente nel certificato client, deve comunque includere lo scopo della chiave clientAuth (OID 1.3.6.1.5.5.7.3.2) come specificato nei requisiti del certificato. Se il certificato ha un'estensione EKU che elenca un altro scopo (ad esempio serverAuth), ma non clientAuth, la connessione viene rifiutata.

  Attenzione: l'attivazione di ALLOW_MISSING_EKU è rischiosa se utilizzi una CA principale che emette certificati per più scopi. Senza l'applicazione dell'EKU, un certificato destinato a uno scopo non di autenticazione (come S/MIME o l'autenticazione solo server) potrebbe essere accettato per l'autenticazione client mTLS. Utilizza questa attenuazione solo se utilizzi una CA privata dedicata per l'emissione di certificati di autenticazione client.

• ALLOW_SHA1_HASHING: consente la convalida delle catene di certificati client firmate utilizzando digest dei messaggi SHA-1 legacy.

  Attenzione: l'autorizzazione dei digest dei messaggi SHA-1 non è sicura. Utilizza questa attenuazione solo temporaneamente per supportare i client legacy durante i periodi di migrazione.

• ALLOW_EXPIRED_LEAF_CERTIFICATE: consente la convalida di un certificato foglia client scaduto. Il bilanciatore del carico convalida il certificato foglia client scaduto come se l'ora corrente fosse un secondo prima della fine del periodo di validità (notAfter meno un secondo). In questo modo, il certificato foglia client supera il controllo della scadenza. Questa flessibilità si applica rigorosamente al certificato foglia del client e non ai certificati intermedi o root della catena. I certificati foglia client non ancora validi (in cui l'ora corrente è precedente al timestamp notBefore) vengono comunque rifiutati.

  Attenzione: consentire i certificati foglia client scaduti non è sicuro. Utilizza questa attenuazione solo temporaneamente per supportare i client legacy durante i periodi di migrazione.

La modalità ALLOW_VALIDATION_RELAXATIONS richiede un certificato client e convalida la catena di certificati in base alla risorsa di configurazione di attendibilità configurata, applicando al contempo le attenuazioni di convalida specifiche che specifichi nel campo clientValidationRelaxations.

Se selezioni ALLOW_VALIDATION_RELAXATIONS, devi specificare almeno un rilassamento della convalida. Se selezioni più rilassamenti, questi vengono applicati contemporaneamente. Se il client fornisce un certificato valido dopo l'applicazione delle attenuazioni selezionate, il bilanciatore del carico accetta la connessione. Ad esempio, se configuri ALLOW_MISSING_EKU e ALLOW_SHA1_HASHING, il bilanciatore del carico accetta connessioni da client che presentano certificati altrimenti validi che omettono l'estensione Extended Key Usage (EKU) e utilizzano l'hashing SHA-1.

Se un client non fornisce un certificato o se la convalida del certificato non riesce per un motivo non coperto dalle attenuazioni configurate, il bilanciatore del carico termina la connessione e registra l'errore in Cloud Logging.

Google Cloud consiglia di utilizzare le attenuazioni della convalida solo come soluzione temporanea durante le migrazioni dei certificati. L'utilizzo di ALLOW_VALIDATION_RELAXATIONS è più sicuro rispetto all'utilizzo di ALLOW_INVALID_OR_MISSING_CLIENT_CERT perché il bilanciatore del carico applica comunque tutti gli altri controlli di convalida e non richiede una logica di convalida personalizzata sul backend.

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 del trust contenente 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.

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 passare 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:

• Configura il mutual TLS con i certificati forniti dagli utenti
• Configura mutual TLS 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 client possieda la chiave privata.

   Il client dimostra il possesso della 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 va a buon fine, significa che il client non è il proprietario del certificato. In questo caso, il TLS handshake 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à convalidando il certificato client rispetto ai certificati configurati nella configurazione di attendibilità. La modalità di convalida del client determina se i certificati client non validi o mancanti vengono rifiutati rigorosamente (REJECT_INVALID), rifiutati ad eccezione di controlli X.509 specifici meno rigidi (ALLOW_VALIDATION_RELAXATIONS) o inoltrati al backend (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

   I controlli di verifica includono anche 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à (oggetto) del certificato principale sia la stessa dell'identità indicata come emittente nel certificato secondario.
   • L'identificatore chiave del soggetto (SKID) del certificato padre corrisponde all'identificatore chiave dell'autorità (AKID) nel certificato figlio. Questa corrispondenza conferma che il certificato secondario è stato emesso dall'autorità radice corretta e che è attendibile perché la chiave pubblica della radice viene indicata 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.
   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 le 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 alle intestazioni mTLS personalizzate, puoi configurare i campi facoltativi mTLS per verificare il motivo dell'errore.

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

Intestazioni mTLS personalizzate passate al backend

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

Queste variabili possono essere impostate anche sulla 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 certificato client o 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 certificato client o 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 o 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 le stesse informazioni Subject e Subject Public Key Info. 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 dieci vincoli di nome.	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 contiene un'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>
È 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).	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 alcuna 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 rispetto alla risorsa TrustConfig non riesce.	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 sistema 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 delle intestazioni personalizzate passati al backend

Alcuni valori delle variabili di intestazione mTLS personalizzate sono rappresentazioni di stringhe con codifica Base64 di dati dei certificati binari Distinguished Encoding Rules (DER). Puoi decodificare le stringhe con codifica 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 con codifica 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 in Base64 come segue:

  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 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 descrive i diversi tipi di errori che possono verificarsi durante la convalida mTLS e il modo in cui vengono registrati.

Errori registrati nelle modalità REJECT_INVALID e ALLOW_VALIDATION_RELAXATIONS

Se la convalida del certificato client non riesce e la modalità di convalida del client è impostata su REJECT_INVALID o ALLOW_VALIDATION_RELAXATIONS, la connessione viene terminata 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 certificato client o 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 certificato client o 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
L'infrastruttura a chiave pubblica da utilizzare per la convalida ha più di dieci certificati intermedi che condividono le stesse informazioni Subject e Subject Public Key Info. Non viene eseguita alcuna convalida.	client_cert_pki_too_large
Un certificato intermedio fornito per la convalida aveva più di dieci vincoli di nome.	client_cert_chain_max_name_constraints_exceeded
Il certificato client non ha un'estensione Extended Key Usage (EKU) che include 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 del 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 con la risorsa TrustConfig non riesce.	client_cert_validation_failed

Errori registrati per le connessioni chiuse

Quando è configurata la modalità di convalida del client, alcuni 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 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 (superiore a 16 KB).	Termina connessione	client_cert_exceeded_size_limit

Se il logging è abilitato sul servizio di backend, puoi eseguire una query per visualizzare i log per 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 trust anchor e certificati intermedi combinati (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 Subject e Subject Public Key Info. Per saperne di più, 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 saperne di più, consulta Quote e limiti.

• Le chiavi dei certificati caricati e trasmessi dal client sono limitate alle seguenti:

  • Le chiavi RSA possono variare da 2048 a 4096 bit. Per saperne di più, 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 saperne di più, consulta Quote e limiti.

• I certificati radice utilizzati per la convalida non possono contenere più di 10 vincoli di nome. Per saperne di più, consulta Quote e limiti.

• I Google Front End (GFE) di livello 1 applicano un timeout non configurabile di 10 secondi per consentire al client di presentare il proprio certificato durante il TLS handshake. In caso 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

• Configura il mutual TLS con i certificati forniti dagli utenti

• Configura mutual TLS con una CA privata

• Variabili che possono essere visualizzate nel valore dell'intestazione