Informações gerais sobre o TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo padrão do setor para autenticação mútua entre um cliente e um servidor. Ele garante que o cliente e o servidor autentiquem um ao outro, verificando se cada um tem um certificado válido emitido por uma autoridade certificadora (CA) confiável. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS exige que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes que a comunicação seja estabelecida.

A mTLS é configurada no recurso de proxy HTTPS de destino de todos os balanceadores de carga de aplicativo:

• Balanceador de carga de aplicativo externo global
• Balanceador de carga de aplicativo clássico
• Balanceador de carga de aplicativo externo regional
• Balanceador de carga de aplicativo interno regional
• Balanceador de carga de aplicativo interno entre regiões

O mTLS usa a infraestrutura de chave pública (ICP) para autenticar a identidade das entidades que se comunicam pela rede. A infraestrutura inclui três componentes: um cliente, um servidor e uma autoridade certificadora (CA). O mTLS para balanceadores de carga oferece suporte aos seguintes recursos:

• Verifique se o cliente que apresenta o certificado possui a chave privada dele.

• Valide os certificados do cliente usando um dos modos de validação do cliente.

• Valide os certificados do cliente em relação a uma âncora de ICP (certificado raiz) enviada, com a opção de adicionar várias âncoras separadamente para permitir a migração sem problemas de uma ICP antiga para uma nova sem inatividade.

• Forneça outros certificados intermediários para ajudar a criar o caminho de validação do certificado do cliente em relação a âncoras de ICP especificadas (certificados raiz). Esses certificados intermediários permitem que o mTLS funcione com clientes que não fornecem a cadeia de certificados completa.

• Gere e transmita uma impressão digital do certificado para o back-end como um cabeçalho da solicitação personalizado.

• Transmita os campos selecionados extraídos do certificado para o back-end usando cabeçalhos personalizados.

• Transmita o resultado e os erros de validação ao back-end usando cabeçalhos personalizados.

Requisitos de certificado

Ao configurar certificados para mTLS, verifique se eles estão em conformidade com estes requisitos:

• As ferramentas de criptografia modernas formam a base da autenticação mTLS. Os certificados precisam usar algoritmos RSA ou ECDSA para troca de chaves.

  Observação: os algoritmos de hash precisam usar SHA-256 ou uma função hash criptográfica mais forte. Algoritmos de hash, como SHA-1, não são compatíveis, a menos que o modo de validação do cliente ALLOW_VALIDATION_RELAXATIONS esteja configurado com a flexibilização ALLOW_SHA1_HASHING, que permite a validação de cadeias de certificados do cliente assinadas com resumos de mensagens SHA-1 legados. Algoritmos de hash como MD4 e MD5 não são compatíveis.

• Para certificados de cliente (folha):

  • A extensão Basic Constraints não pode conter CA=true.

  • A extensão Extended Key Usage precisa conter clientAuth.

    Observação: se você usar o modo de validação de cliente ALLOW_VALIDATION_RELAXATIONS com a flexibilização ALLOW_MISSING_EKU, o balanceador de carga vai ignorar esse requisito. No entanto, se o certificado tiver uma extensão de EKU que liste outra finalidade (como serverAuth), mas não clientAuth, a conexão será rejeitada.

  • A extensão Extended Key Usage não pode conter os campos codeSigning, timeStamping ou OCSPSigning.

  • O certificado não pode estar vencido.

    Observação : se você usar o modo de validação de cliente ALLOW_VALIDATION_RELAXATIONS com a flexibilização ALLOW_EXPIRED_LEAF_CERTIFICATE, o balanceador de carga vai ignorar esse requisito.

  • O certificado do cliente não pode ser um certificado autoassinado.

• Para certificados raiz e intermediários:

  • A extensão Basic Constraints precisa conter CA=true.

  • A extensão Key Usage precisa ser definida como keyCertSign.

  • A extensão Extended Key Usage precisa conter o campo clientAuth.

  • O certificado não pode estar vencido.

Arquitetura de uma implantação de mTLS

Com o mTLS, é possível configurar um recurso de configuração de confiança, que contém um repositório de confiança. O repositório de confiança encapsula uma âncora de confiança (certificado raiz) e, opcionalmente, um ou mais certificados intermediários. Quando o balanceador de carga recebe um certificado do cliente, ele o valida estabelecendo uma cadeia de confiança do certificado do cliente até a âncora de confiança configurada.

Confira a seguir uma breve visão geral dos diferentes recursos que você precisa configurar para definir o mTLS para o balanceador de carga:

• Configuração de confiança. Contém um único recurso de repositório de confiança, que, por sua vez, encapsula uma âncora de confiança (certificado raiz) e, opcionalmente, um ou mais certificados intermediários. A configuração de confiança é usada para estabelecer uma cadeia de confiança entre o certificado do cliente e a âncora de confiança. Para mais informações, consulte Configurações de confiança.

  Se você precisar usar um certificado autoassinado, expirado ou inválido, ou se não tiver acesso aos certificados raiz e intermediários, adicione esse certificado à configuração de confiança no campo allowlistedCertificates. Não é necessário um repositório de confiança para adicionar um certificado a uma lista de permissões.

  Adicionar um certificado à lista de permissões significa que ele sempre será considerado válido, desde que seja analisável, a comprovação de posse da chave privada seja estabelecida e as restrições no campo SAN do certificado sejam atendidas.

• Repositório de confiança. Contém os certificados de autoridade de certificação (CA, na sigla em inglês) âncora de confiança e certificado intermediário que são usados para estabelecer uma cadeia de confiança e validar o certificado do cliente. Uma CA é usada para emitir certificados confiáveis para o cliente. A CA é identificada pela âncora de confiança do balanceador de carga (certificado raiz) ou pelos certificados de CA intermediários.

  É possível fazer upload dos seguintes tipos de certificados raiz e intermediários para o repositório de confiança:

  • Certificados emitidos por CAs de terceiros de sua escolha.
  • Certificados emitidos por CAs privadas no seu controle, conforme descrito em Configurar TLS mútuo com uma CA particular.
  • Certificados fornecidos pelo usuário, conforme descrito em Configurar TLS mútuo com certificados fornecidos pelo usuário.

• Autenticação do cliente (também conhecida como ServerTLSPolicy). Especifica o modo de validação do cliente e o recurso de configuração de confiança a ser usado ao validar certificados do cliente. Quando o cliente apresenta um certificado inválido ou nenhum certificado para o balanceador de carga, o modo de validação do cliente especifica como a conexão do cliente é processada. É possível especificar todos os parâmetros relacionados à autenticação mTLS nas políticas de TLS do servidor. O recurso de autenticação do cliente (ServerTLSPolicy) é anexado ao recurso de proxy HTTPS de destino.

Os diagramas a seguir mostram os diferentes componentes de mTLS anexados ao recurso de proxy HTTPS de destino dos balanceadores de carga de aplicativo globais e regionais.

global

O diagrama a seguir mostra os componentes de uma implantação do balanceador de carga de aplicativo externo. Essa arquitetura também se aplica ao balanceador de carga de aplicativo interno entre regiões, que é um balanceador de carga de aplicativo interno que usa componentes globais.

TLS mútuo com componentes globais externos do balanceador de carga de aplicativo (clique para ampliar).

regional

O diagrama a seguir mostra os componentes de uma implantação regional do balanceador de carga de aplicativo interno. Essa arquitetura também se aplica ao balanceador de carga de aplicativo externo regional, que é um balanceador de carga de aplicativo externo que usa componentes regionais.

TLS mútuo com componentes regionais internos do balanceador de carga de aplicativo (clique para ampliar).

Modos de validação do cliente

O atributo clientValidationMode no recurso de autenticação do cliente (ServerTLSPolicy) especifica como o balanceador de carga processa a conexão do cliente. O modo determina se os certificados do cliente inválidos ou ausentes são rejeitados estritamente (REJECT_INVALID), rejeitados, exceto para verificações X.509 relaxadas específicas (ALLOW_VALIDATION_RELAXATIONS), ou encaminhados para o back-end (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

Os diferentes modos de validação do cliente são os seguintes:

• Permitir certificados do cliente inválidos ou ausentes (ALLOW_INVALID_OR_MISSING_CLIENT_CERT)
• Rejeitar certificados do cliente inválidos (REJECT_INVALID)
• Permitir flexibilizações de validação (ALLOW_VALIDATION_RELAXATIONS)

Permitir certificado do cliente inválido ou ausente

O modo ALLOW_INVALID_OR_MISSING_CLIENT_CERT permite a conexão do cliente mesmo que o certificado do cliente falhe na validação ou o cliente não apresente um certificado. Nesse modo, o balanceador de carga permite a conexão do cliente e transmite todas as solicitações para o back-end, independentemente de uma cadeia de confiança poder ser estabelecida ou não.

O comprovante de posse da chave privada é sempre verificado quando o certificado do cliente é apresentado. Se o cliente não puder provar a posse da chave privada, o handshake de TLS será encerrado, mesmo que o modo de validação do cliente permita um certificado de cliente inválido ou ausente.

Rejeitar certificado do cliente inválido

O modo REJECT_INVALID rejeitará a conexão se um cliente não fornecer um certificado ou se a validação do certificado falhar. Nesse modo, o balanceador de carga encerra a conexão do cliente se não conseguir estabelecer uma cadeia de confiança do certificado do cliente de volta para a âncora de confiança.

Permitir flexibilizações de validação

O modo ALLOW_VALIDATION_RELAXATIONS aplica a validação do certificado do cliente, mas permite flexibilizações em verificações de validação específicas, por exemplo, durante uma migração em que os certificados do cliente legados não atendem a todos os requisitos de certificado estritos. Se você tiver um recurso ServerTLSPolicy no modo REJECT_INVALID, poderá atualizá-lo para usar o modo ALLOW_VALIDATION_RELAXATIONS e especificar a lista de relaxamentos de validação que quer permitir.

É possível especificar um ou mais dos seguintes valores no campo clientValidationRelaxations:

• ALLOW_MISSING_EKU: permite que o certificado do cliente omita a extensão de uso de chave estendido (EKU, na sigla em inglês).

  O ALLOW_MISSING_EKU só permite um certificado que não tenha nenhuma extensão de EKU. Ele não ignora uma extensão de EKU que esteja presente com a finalidade errada. Por exemplo, se a extensão de EKU estiver presente no certificado do cliente, ela ainda precisará incluir a finalidade da chave clientAuth (OID 1.3.6.1.5.5.7.3.2), conforme especificado nos requisitos do certificado. Se o certificado tiver uma extensão de EKU que liste outra finalidade (como serverAuth), mas não clientAuth, a conexão será rejeitada.

  Atenção: ativar ALLOW_MISSING_EKU é arriscado se você usa uma CA raiz que emite certificados para várias finalidades. Sem a aplicação de EKU, um certificado destinado a uma finalidade que não seja de autenticação (como S/MIME ou autenticação somente de servidor) pode ser aceito para autenticação de cliente mTLS. Use essa flexibilização apenas se você usar uma AC particular dedicada para emitir certificados de autenticação de cliente.

• ALLOW_SHA1_HASHING: permite a validação de cadeias de certificados do cliente assinadas com resumos de mensagens SHA-1 legados.

  Atenção: permitir resumos de mensagens SHA-1 não é seguro. Use essa flexibilização apenas temporariamente para oferecer suporte a clientes legados durante períodos de migração.

• ALLOW_EXPIRED_LEAF_CERTIFICATE: permite a validação de um certificado de folha de cliente expirado. O balanceador de carga valida o certificado de folha do cliente expirado como se o horário atual fosse um segundo antes do fim do período de validade (notAfter menos um segundo). Isso permite que o certificado de folha do cliente passe na verificação de validade. Essa flexibilização se aplica estritamente ao certificado de folha do cliente, e não aos certificados intermediários ou raiz na cadeia. Os certificados de folha do cliente que ainda não são válidos (em que o horário atual é anterior ao carimbo de data/hora notBefore) ainda são rejeitados.

  Atenção: permitir certificados de folha de cliente expirados não é seguro. Use essa flexibilização apenas temporariamente para oferecer suporte a clientes legados durante períodos de migração.

O modo ALLOW_VALIDATION_RELAXATIONS exige um certificado do cliente e valida a cadeia de certificados em relação ao recurso de configuração de confiança configurado, aplicando as flexibilizações de validação específicas que você especificar no campo clientValidationRelaxations.

Ao selecionar ALLOW_VALIDATION_RELAXATIONS, é preciso especificar pelo menos uma flexibilização de validação. Se você selecionar várias flexibilizações, todas as selecionadas serão aplicadas simultaneamente. Desde que o cliente forneça um certificado válido após a aplicação das flexibilizações selecionadas, o balanceador de carga aceitará a conexão. Por exemplo, se você configurar ALLOW_MISSING_EKU e ALLOW_SHA1_HASHING, o balanceador de carga vai aceitar conexões de clientes que apresentem certificados válidos que omitam a extensão de uso de chave estendido (EKU) e usem o hash SHA-1.

Se um cliente não fornecer um certificado ou se a validação do certificado falhar por qualquer motivo não coberto pelas flexibilizações configuradas, o balanceador de carga encerrará a conexão e registrará o erro no Cloud Logging.

OGoogle Cloud recomenda o uso de relaxamentos de validação apenas como uma solução temporária durante as migrações de certificados. Usar ALLOW_VALIDATION_RELAXATIONS é mais seguro do que usar ALLOW_INVALID_OR_MISSING_CLIENT_CERT, porque o balanceador de carga ainda aplica todas as outras verificações de validação e não exige uma lógica de validação personalizada no back-end.

Configurar o mTLS no balanceador de carga

Confira a seguir uma visão geral das principais etapas para configurar a mTLS no balanceador de carga:

1. Crie um recurso de configuração de confiança que inclua a âncora de confiança (certificado raiz) e os certificados intermediários que servem como raízes de confiança.

2. Vincule a configuração de confiança ao recurso de autenticação do cliente (ServerTLSPolicy), que define o modo de validação do cliente.

3. Anexe o recurso de autenticação do cliente (ServerTLSPolicy) ao recurso de proxy HTTPS de destino do balanceador de carga.

4. Opcional: é possível usar cabeçalhos mTLS personalizados para transmitir informações sobre a conexão mTLS para um serviço de back-end ou um mapa de URL.

Para saber mais sobre essa configuração, consulte os seguintes guias:

• Configurar o TLS mútuo com certificados fornecidos pelo usuário
• Configurar o TLS mútuo com uma CA particular

Etapas de validação do certificado do cliente

Ao validar o certificado do cliente, o balanceador de carga faz o seguinte:

1. Verifique se o cliente tem a chave privada.

   O cliente comprova a posse da chave privada associada à chave pública no certificado gerando uma assinatura durante o processo de handshake. O balanceador de carga verifica essa assinatura usando a chave pública do cliente. Se a verificação de assinatura falhar, isso significa que o cliente não é o proprietário do certificado. Nesse caso, o handshake de TLS é encerrado, mesmo que sua configuração permita um certificado do cliente inválido ou ausente. Nenhum erro é registrado para balanceadores de carga de aplicativo externos globais, mas um erro de TLS é registrado no campo proxyStatus para balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos.

2. Verifique a cadeia de confiança.

   O balanceador de carga verifica a cadeia de confiança validando o certificado do cliente em relação aos certificados configurados na configuração de confiança. O modo de validação do cliente determina se os certificados do cliente inválidos ou ausentes são rejeitados estritamente (REJECT_INVALID), rejeitados, exceto para verificações X.509 relaxadas específicas (ALLOW_VALIDATION_RELAXATIONS), ou encaminhados para o back-end (ALLOW_INVALID_OR_MISSING_CLIENT_CERT).

   As verificações também incluem o seguinte:

   • Os certificados do cliente, intermediários e raiz estão em conformidade com os requisitos de certificado.
   • O campo de assunto no certificado pai corresponde ao campo de emissor no certificado filho. Essa verificação garante que a identidade (assunto) do certificado pai seja igual à identidade listada como emissor no certificado filho.
   • O identificador de chave de assunto (SKID, na sigla em inglês) do certificado pai corresponde ao identificador de chave de autoridade (AKID, na sigla em inglês) no certificado filho. Essa correspondência confirma que o certificado filho foi emitido pela autoridade raiz correta e que é confiável porque a chave pública da raiz está sendo referenciada no AKID para verificar a validade do certificado.
   • O nome alternativo do sujeito (SAN, na sigla em inglês) de um certificado filho não viola o campo NameConstraints no certificado pai.
   Observação : os certificados do cliente autoassinados não formam uma cadeia de confiança válida e são sempre rejeitados.

3. Encaminhar a solicitação para o back-end.

   Se a validação do certificado do cliente for bem-sucedida, a solicitação será encaminhada para o back-end usando cabeçalhos mTLS personalizados.

   No entanto, se a validação falhar, a ação realizada vai depender do valor do modo de validação do cliente:

   • ALLOW_INVALID_OR_MISSING_CLIENT_CERT: a solicitação é encaminhada com cabeçalhos mTLS personalizados indicando o motivo da falha de validação. Para balanceadores de carga de aplicativo internos entre regiões, balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais, além de cabeçalhos mTLS personalizados, é possível configurar campos opcionais do mTLS para verificar o motivo da falha.

   • REJECT_INVALID e ALLOW_VALIDATION_RELAXATIONS: a conexão é encerrada e os erros são registrados no Cloud Logging.

Cabeçalhos mTLS personalizados transmitidos para o back-end

A tabela a seguir mostra as variáveis de cabeçalho mTLS personalizadas que estão disponíveis para serem transmitidas ao back-end, tanto quando o certificado do cliente passa na validação quanto quando falha. Se a validação do certificado do cliente falhar, as solicitações serão transmitidas para o back-end somente quando o modo de validação do cliente estiver definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

Essas variáveis também podem ser definidas no mapa de URL.

Status do certificado do cliente	Modo de validação do cliente	Cabeçalhos personalizados
A cadeia de certificados do cliente é muito longa (mais de 10 certificados intermediários incluídos no certificado do cliente).	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>
Um cliente ou um certificado intermediário tem um tamanho de chave RSA inválido. Nenhuma validação é executada. As chaves RSA podem ter entre 2.048 e 4.096 bits.	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>
Um cliente ou um certificado intermediário está usando uma curva elíptica não compatível. Nenhuma validação é executada. As curvas elípticas válidas são 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>
Um cliente ou certificado intermediário está usando um algoritmo não RSA, não ECDSA. Nenhuma validação é executada.	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>
A ICP a ser usada para validação tem mais de dez certificados intermediários que compartilham as mesmas informações sobre o sujeito e sobre a chave pública do sujeito. Nenhuma validação é executada.	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>
Um certificado intermediário fornecido para validação tinha mais de 10 restrições de 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>
O certificado do cliente não tem a extensão Extended Key Usage (EKU) que inclui 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>
O limite de tempo é excedido ao tentar validar a cadeia de certificados.	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>
O limite de profundidade ou iteração é atingido ao tentar validar a cadeia de certificados. A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do cliente. O máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do cliente).	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>
Você configurou o mTLS sem configurar um recurso TrustConfig. Nenhuma validação pode ser realizada, mas o hash do certificado é encaminhado para o back-end.	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>
Nenhum certificado de cliente.	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>
A validação do certificado do cliente falha no recurso 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>
O certificado do cliente passa na validação do verificador do certificado.	Não relevante	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>

Analisar valores de variáveis de cabeçalho personalizadas transmitidos para o back-end

Alguns valores de variáveis de cabeçalho mTLS personalizadas são representações de string codificadas em Base64 de dados de certificado binários de regras de codificação diferenciadas (DER, na sigla em inglês). É possível decodificar strings codificadas em Base64 usando as ferramentas ou bibliotecas de software de sua escolha. Confira alguns exemplos:

• Os sistemas macOS e Linux podem usar a ferramenta de linha de comando base64, que é um utilitário principal incluído nos dois sistemas operacionais. Para decodificar strings codificadas em Base64 usando o utilitário base64, transmita a string codificada como entrada padrão para o comando base64 e use a flag -d para decodificar a string da seguinte maneira:

  echo BASE_64_ENCODED_STRING | base64 -d
  

• O Python inclui o módulo base64, que pode ser usado para decodificar strings codificadas em Base64 da seguinte maneira:

  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.
  

Tratamento de erros e geração de registros

Os balanceadores de carga de aplicativo oferecem recursos de geração de registros detalhados que permitem monitorar a validação de certificados do cliente, identificar possíveis problemas e solucionar problemas de conexão. Nesta seção, descrevemos os diferentes tipos de erros que podem ocorrer durante a validação de mTLS e como eles são registrados.

Erros registrados nos modos REJECT_INVALID e ALLOW_VALIDATION_RELAXATIONS

Se a validação do certificado do cliente falhar e o modo de validação do cliente estiver definido como REJECT_INVALID ou ALLOW_VALIDATION_RELAXATIONS, a conexão será encerrada e os erros serão registrados no Cloud Logging. Esses erros são descritos na tabela a seguir.

Status do certificado do cliente	Erro registrado
A cadeia de certificados do cliente é muito longa (mais de 10 certificados intermediários incluídos no certificado do cliente).	client_cert_chain_exceeded_limit
Um cliente ou um certificado intermediário tem um tamanho de chave RSA inválido. Nenhuma validação é executada. As chaves RSA podem ter entre 2.048 e 4.096 bits.	client_cert_invalid_rsa_key_size
Um cliente ou um certificado intermediário está usando uma curva elíptica não compatível. Nenhuma validação é executada. As curvas válidas são P-256 e P-384.	client_cert_unsupported_elliptic_curve_key
Um cliente ou certificado intermediário está usando um algoritmo não RSA ou não ECDSA. Nenhuma validação é executada.	client_cert_unsupported_key_algorithm
A ICP a ser usada para validação tem mais de dez certificados intermediários que compartilham as mesmas informações sobre o sujeito e sobre a chave pública do sujeito. Nenhuma validação é executada.	client_cert_pki_too_large
Um certificado intermediário fornecido para validação tinha mais de 10 restrições de nome.	client_cert_chain_max_name_constraints_exceeded
O certificado do cliente não tem uma extensão Extended Key Usage (EKU) que inclua clientAuth.	client_cert_chain_invalid_eku
O limite de tempo é excedido ao tentar validar a cadeia de certificados.	client_cert_validation_timed_out
O limite de profundidade ou iteração é atingido ao tentar validar a cadeia de certificados. A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do cliente. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do cliente).	client_cert_validation_search_limit_exceeded
Você configurou o mTLS sem configurar um recurso TrustConfig.	client_cert_validation_not_performed
O cliente não forneceu o certificado solicitado durante o handshake.	client_cert_not_provided
A validação do certificado do cliente falha com o recurso TrustConfig.	client_cert_validation_failed

Erros registrados para conexões fechadas

Quando o modo de validação do cliente é configurado, determinados erros resultam em conexões fechadas e são registrados no Cloud Logging. Esses erros são descritos na tabela a seguir.

Status do certificado do cliente	Solicitação	Erro registrado
O certificado do cliente falha na correspondência da assinatura durante o handshake.	Encerrar handshake de SSL	Nenhum
O serviço não pode realizar a validação da cadeia de certificados.	Encerrar conexão	client_cert_validation_unavailable
Erro interno ao validar a cadeia de certificados.	Encerrar conexão	client_cert_validation_internal_error
TrustConfig não encontrado.	Encerrar conexão	client_cert_trust_config_not_found
O payload do certificado do cliente (incluindo certificados intermediários) é muito grande (mais de 16 KB).	Encerrar conexão	client_cert_exceeded_size_limit

Se a geração de registros estiver ativada no serviço de back-end, será possível executar uma consulta para visualizar os registros de validação do certificado do cliente mTLS.

Limitações

• O balanceador de carga não executa verificações de revogação em certificados do cliente.

• Os balanceadores de carga de aplicativo permitem fazer upload de uma configuração de confiança com um único repositório de confiança, que contém no máximo: 200 do número combinado de âncoras de confiança e certificados intermediários (o número de certificados intermediários é limitado a 100) e 500 certificados adicionados a uma lista de permissões. Os certificados intermediários não podem ter mais de três certificados que compartilham as mesmas informações de Assunto e de Chave pública do assunto. Para mais informações, consulte Cotas e limites.

• A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do cliente. O número máximo de vezes que os certificados intermediários podem ser avaliados ao tentar criar a cadeia de confiança é 100. Para mais informações, consulte Cotas e limites.

• As chaves de certificados enviadas e passadas do cliente são restritas ao seguinte:

  • As chaves RSA podem ter entre 2.048 e 4.096 bits. Para mais informações, consulte Cotas e limites.
  • As chaves ECDSA podem usar as curvas P-256 ou P-384.

• A cadeia de certificados aceitos recebida do cliente está limitada a até 16 KB e 10 certificados. Para mais informações, consulte Cotas e limites.

• Os certificados raiz usados para validação não podem conter mais de 10 restrições de nome. Para mais informações, consulte Cotas e limites.

• Os Google Front Ends (GFEs) da camada 1 aplicam um tempo limite não configurável de 10 segundos para que o cliente apresente o certificado durante o handshake de TLS. Em períodos de pico, esse tempo limite pode ser menor. Os clientes precisam concluir a apresentação do certificado dentro desse período para estabelecer uma conexão mTLS.

A seguir

• Configurar o TLS mútuo com certificados fornecidos pelo usuário

• Configurar o TLS mútuo com uma CA particular

• Variáveis que podem aparecer no valor do cabeçalho