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 se autenticam verificando se cada um deles tem um certificado válido emitido por uma autoridade certificadora (AC) 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.

O mTLS é configurado 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

A 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 (AC). O mTLS para balanceadores de carga oferece suporte aos seguintes recursos:

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

• Valide certificados de cliente em um dos dois modos:

  • Rejeitar certificados inválidos: impõe a autenticação estrita rejeitando solicitações se a cadeia de certificados do cliente não puder ser validada.

  • Permitir certificados inválidos ou ausentes: oferece flexibilidade ao transmitir todas as solicitações para o back-end, mesmo que um certificado de cliente esteja ausente ou inválido.

• Valide certificados de 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 construir 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 passe uma impressão digital do certificado para o back-end como um cabeçalho de 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 atendem a 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. Os algoritmos de hash precisam usar SHA-256 ou uma função de hash criptográfico mais forte. Algoritmos de hash como MD4, MD5 e SHA-1 não são aceitos.
• 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.
  • A extensão Extended Key Usage não pode conter os campos codeSigning, timeStamping ou OCSPSigning.
  • O certificado não pode estar vencido.
  • 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 truststore. 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 de volta à âncora de confiança configurada.

Confira a seguir um breve resumo dos diferentes recursos que você precisa configurar para configurar o mTLS no balanceador de carga:

• Configuração de confiança. Contém um único recurso de armazenamento 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ário, adicione esse certificado à configuração de confiança no campo allowlistedCertificates. Não é necessário ter uma loja de certificados 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 (AC) âncora de confiança e intermediários que são usados para estabelecer uma cadeia de confiança e validar o certificado do cliente. Uma AC é usada para emitir certificados confiáveis para o cliente. A AC é identificada pelo certificado raiz da âncora de confiança do balanceador de carga ou pelos certificados de AC intermediários.

  Você pode fazer o 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 ACs particulares no seu controle, conforme descrito em Configurar TLS mútuo com uma AC 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 do 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).

Modo de validação do cliente

Quando o cliente apresenta um certificado inválido ou nenhum certificado para o balanceador de carga, o atributo clientValidationMode no recurso de autenticação do cliente (ServerTLSPolicy) especifica como o balanceador de carga processa a conexão do cliente.

Os valores do modo de validação do cliente são os seguintes:

• ALLOW_INVALID_OR_MISSING_CLIENT_CERT. Permite a conexão do cliente mesmo que a validação do certificado do cliente tenha falhado ou nenhum certificado do cliente tenha sido apresentado. Nesse modo, o balanceador de carga permite a conexão do cliente e transmite todas as solicitações ao back-end, independente 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.

• REJECT_INVALID. Rejeita 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 for possível estabelecer uma cadeia de confiança do certificado do cliente de volta ao âncora de confiança.

Configurar o mTLS no balanceador de carga

Confira a seguir uma visão geral de alto nível das principais etapas que você precisa seguir para configurar o 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 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 de ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID.

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 prova 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, significa que o cliente não é o proprietário do certificado. Nesse caso, o handshake de TLS é encerrado, mesmo que a configuração permita um certificado de 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 internos.

2. Verifique a cadeia de confiança.

   O balanceador de carga verifica a cadeia de confiança entre o certificado do cliente e a configuração de confiança configurada. As verificações de verificação 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 a mesma que a 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 pode ser confiável porque a chave pública raiz está sendo referenciada no AKID para verificar a validade do certificado.
   • O nome alternativo do assunto (SAN) de um certificado filho não viola o campo NameConstraints no certificado pai.
   Observação: os certificados de cliente autoassinados não conseguem formar 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 tomada 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 na 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: 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 os cabeçalhos mTLS personalizados que são transmitidos para o back-end, tanto quando o certificado do cliente é validado quanto quando ele falha. Se a validação do certificado do cliente falhar, os cabeçalhos personalizados serão transmitidos para o back-end somente quando o modo de validação do cliente estiver definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT.

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 variar de 2.048 a 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>

Tratamento e geração de registros de erros

Os Application Load Balancers oferecem recursos de geração de registros detalhados que permitem monitorar a validação do certificado do cliente, identificar possíveis problemas e solucionar problemas de conexão. Esta seção descreve os diferentes tipos de erros que podem ocorrer durante a validação do mTLS e como eles são registrados.

Erros registrados no modo REJECT_INVALID

Se a validação do certificado do cliente falhar e o modo de validação do cliente estiver definido como REJECT_INVALID, 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 variar de 2.048 a 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 é definido como ALLOW_INVALID_OR_MISSING_CLIENT_CERT ou REJECT_INVALID, alguns 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, você poderá ver os erros registrados para conexões fechadas durante a 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 armazenamento de confiança que contém no máximo 100 âncoras de confiança e 100 certificados intermediários 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 variar de 2.048 a 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.

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