Informações gerais sobre o TLS e o mTLS autenticados no back-end

Quando um balanceador de carga se conecta a back-ends que estão no Google Cloud, ele aceita qualquer certificado presente nos back-ends. Nesses casos, o balanceador de carga não realiza nenhuma validação de certificado.

Com o TLS autenticado de back-end ou a autenticação de back-end, o balanceador de carga pode verificar a identidade dos back-ends a que se conecta. Com o mTLS de back-end, o balanceador de carga também pode provar a identidade para os back-ends usando um certificado TLS de cliente.

O diagrama a seguir mostra a diferença entre o mTLS de front-end e de back-end, com foco na função do balanceador de carga em cada caso. No mTLS de front-end, o balanceador de carga atua como o servidor, verificando a identidade do cliente. No mTLS de back-end, o balanceador de carga atua como o cliente, provando sua identidade para o back-end.

mTLSs de front-end e back-end (clique para ampliar).

O mTLS opera de forma independente no front-end e no back-end. É possível configurar o mTLS no front-end, no back-end ou em ambos.

Este documento apresenta uma visão geral do TLS autenticado de back-end e do mTLS de back-end. Para saber mais sobre o mTLS de front-end, consulte a visão geral do TLS mútuo.

O TLS autenticado de back-end e o mTLS de back-end podem ser configurados no recurso de serviço de back-end dos seguintes balanceadores de carga:

• Balanceadores de carga de aplicativos externos globais
• Balanceadores de carga de aplicativo externos regionais
• Balanceadores de carga de aplicativo internos regionais
• Balanceadores de carga de aplicativo internos entre regiões

Recursos

A mTLS usa a infraestrutura de chave pública (PKI) 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 TLS autenticado e o mTLS de back-end adicionam os seguintes recursos aos balanceadores de carga de aplicativo:

• O balanceador de carga pode validar certificados apresentados por back-ends em relação às suas próprias âncoras de confiança. É possível fazer upload de várias âncoras de confiança para permitir a migração perfeita de uma ICP anterior para uma nova sem inatividade.

• O balanceador de carga pode validar certificados TLS de back-ends em relação a raízes de confiança públicas (PKI da Web).

• Além das âncoras de confiança, é possível configurar certificados intermediários para ajudar a construir o caminho de validação do certificado de back-end. O uso de certificados intermediários significa que os servidores de back-end não precisam fornecer a cadeia de certificados completa.

• É possível configurar um nome do host de indicação de nome do servidor (SNI) TLS para seu serviço de back-end. Durante o handshake TLS, o balanceador de carga inclui esse nome de host SNI na mensagem ClientHello enviada ao back-end. O back-end responde com o certificado TLS, e o balanceador de carga verifica se pelo menos um dos campos de nome alternativo do sujeito (SAN) do certificado corresponde ao nome do host ou a qualquer um dos campos SAN configurados para o serviço de back-end.

• É possível configurar o serviço de back-end do balanceador de carga para usar mTLS e provar a identidade aos back-ends. Essa autenticação é realizada usando um certificado de cliente (balanceador de carga) que o balanceador de carga apresenta ao back-end.

Requisitos de certificado

Ao configurar certificados, verifique se eles atendem a estes requisitos:

• As ferramentas de criptografia moderna 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 compatíveis.

• Os certificados de servidor folha fornecidos pelo back-end têm os seguintes requisitos:

  • A extensão restrições básicas não pode conter CA=true.
  • A extensão uso estendido de chave precisa conter serverAuth.
  • A extensão extended key usage não pode conter os campos codeSigning, timeStamping ou OCSPSigning.
  • O certificado não pode estar vencido.

• Para certificados de cliente folha (balanceador de carga) usados no mTLS de back-end, o certificado precisa ser um recurso de certificado do Certificate Manager. O escopo desse certificado precisa ser client-auth, o que indica que ele é usado como um certificado de cliente em mTLS de back-end.

  • A extensão restrições básicas não pode conter CA=true.
  • A extensão uso estendido de chave 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.

• Para autenticar os certificados de servidor que seu back-end apresenta ao balanceador de carga, os certificados raiz e intermediários localizados na configuração de confiança precisam atender aos seguintes requisitos:

  • A extensão restrições básicas precisa conter CA=true.
  • A extensão uso de chave precisa ser definida como keyCertSign.
  • A extensão uso estendido de chave precisa conter o campo serverAuth.
  • O certificado não pode estar vencido.

Principais componentes do TLS autenticado de back-end e do mTLS de back-end

Com o TLS autenticado de back-end, o balanceador de carga pode verificar a identidade dos back-ends a que se conecta. É possível configurar o TLS autenticado de back-end em um balanceador de carga HTTP(S) que usa HTTPS ou HTTP/2 como protocolo serviço de back-end. Se você não configurar o TLS autenticado de back-end, o balanceador de carga aceitará qualquer certificado do back-end. Com o mTLS de back-end, é possível configurar o balanceador de carga para apresentar o próprio certificado do cliente ao back-end, que pode ser usado para autenticar o balanceador de carga.

Para configurar o TLS autenticado de back-end, faça o seguinte:

• Crie um recurso de configuração de confiança.
• Crie um recurso de configuração de autenticação de back-end.
• Atualize o atributo de configuração de TLS no serviço de back-end, apontando para o recurso de configuração de autenticação de back-end.

Para configurar o mTLS de back-end, crie um certificado de cliente e anexe-o ao recurso de configuração de autenticação de back-end. Não é possível anexar o certificado do cliente depois que o recurso de configuração de autenticação de back-end é criado.

O diagrama a seguir mostra os diferentes componentes anexados ao serviço de back-end de um balanceador de carga de aplicativo que ativam o TLS autenticado de back-end e o mTLS de back-end.

Componentes de TLS autenticado de back-end e mTLS de back-end (clique para ampliar).

As informações a seguir oferecem uma visão geral dos diferentes componentes usados para configurar a autenticação TLS e o mTLS no back-end.

Configuração de confiança

Para autenticar os certificados de servidor que seu back-end apresenta ao balanceador de carga, ele precisa ser configurado com certificados X.509 que estabelecem uma cadeia de confiança para o emissor do certificado do back-end. Você configura a configuração de confiança usando um recurso TrustConfig, que expressa toda a configuração de confiança e contém um único repositório de confiança.

Um repositório de confiança encapsula uma âncora de confiança (certificado raiz) e, opcionalmente, um ou mais certificados intermediários. Uma âncora de confiança é um certificado que representa uma raiz de confiança. Um certificado de servidor válido precisa mostrar uma cadeia de confiança de volta a alguma âncora de confiança no repositório de confiança.

Um certificado intermediário faz parte de uma cadeia de confiança que leva de volta a uma âncora de confiança no repositório de confiança. Ele é usado, junto com outras ACs intermediárias incluídas no certificado folha, para criar a cadeia de confiança durante o processo de validação. A criação de um certificado intermediário é opcional.

Se você precisar usar um certificado autoassinado, expirado, que não se encadeia a uma raiz de confiança especificada ou que falhou na validação, adicione esse certificado a uma lista de permissões na configuração de confiança. A criação de um certificado autoassinado que pode ser adicionado a uma lista de permissões também é opcional.

O repositório de confiança não contém chaves privadas porque apenas os certificados são necessários para verificar uma cadeia de confiança.

Recurso de configuração de autenticação de back-end

A configuração de autenticação de back-end (recurso BackendAuthenticationConfig) é anexada ao serviço de back-end do balanceador de carga e executa as seguintes funções:

• Ativa o TLS autenticado de back-end (autenticação de back-end) usando a configuração de confiança e as raízes públicas de confiança.
• Além disso, ativa o mTLS de back-end usando o certificado do cliente.

Para ativar o TLS autenticado de back-end e o mTLS de back-end, o recurso de configuração de autenticação de back-end aponta para os seguintes recursos:

• Configuração de confiança (trustConfig): a configuração de confiança anexada usada para validar o certificado do servidor fornecido pelo back-end. A configuração de confiança não é necessária quando a configuração de autenticação de back-end usa as raízes públicas de confiança para validar o certificado do servidor.

• Raízes de confiança públicas (wellKnownRoots): indica se o balanceador de carga confia em certificados de servidor de back-end emitidos por CAs públicas, além de certificados confiáveis pela configuração de confiança. Para saber mais, consulte Usar raízes de confiança públicas.

• Certificado do cliente (clientCertificate): o certificado do cliente que o balanceador de carga usa para expressar a identidade dele para o back-end, se a conexão com o back-end usar mTLS. Para TLS autenticado de back-end (autenticação de back-end), esse campo pode ficar vazio. Nesse caso, o balanceador de carga autentica apenas o back-end, mas não a si mesmo, para o back-end.

Observação: não é possível enviar um certificado do cliente para o back-end sem configurar primeiro o TLS autenticado do back-end. Isso ocorre porque o balanceador de carga não pode apresentar o certificado ao back-end sem primeiro validar o certificado apresentado pelo back-end.

Serviço de back-end

No serviço de back-end, o atributo tlsSettings aponta para os seguintes recursos para validar o certificado de back-end.

• Configuração de autenticação de back-end (authenticationConfig)
• Nome do host SNI (sni)
• SANs aceitas (subjectAltNames)

Observação: configurar o nome do host SNI e os SANs aceitos no serviço de back-end para verificar o certificado de back-end é opcional. No entanto, não é possível validar o certificado de back-end sem configurar o recurso de configuração de autenticação de back-end no serviço de back-end. Em outras palavras, o certificado de back-end precisa ser validado por uma cadeia de certificados confiável, que é expressa usando uma configuração de confiança.

Os campos SNI (sni) e SAN (subjectAltNames) no atributo tlsSettings controlam como o balanceador de carga valida o certificado do back-end com base nos valores SAN do certificado. Esses campos influenciam o processo de validação, independentemente de o TLS autenticado de back-end estar configurado.

Quando o campo SNI é definido (tlsSettings.sni), o balanceador de carga faz o seguinte:

• Envia o nome do host SNI para o servidor de back-end durante o handshake de TLS.
• Verifica se o certificado TLS do back-end inclui um SAN que corresponde ao nome do host SNI.

Por padrão, o balanceador de carga verifica se o certificado TLS do back-end inclui um SAN que corresponde ao nome do host SNI. No entanto, se os SANs forem configurados no serviço de back-end (tlsSettings.subjectAltNames), o balanceador de carga fará o seguinte:

• Ignora o nome do host SNI para verificação de SAN.
• Verifica se o certificado TLS do back-end inclui um SAN que corresponde a um dos SANs aceitos (subjectAltNames) configurados no serviço de back-end.

Certificado do cliente

Além do TLS autenticado de back-end (autenticação de back-end), é possível configurar o serviço de back-end de um balanceador de carga para usar mTLS, de modo que o balanceador de carga possa provar sua identidade para o back-end. Essa autenticação usa um certificado de cliente (balanceador de carga) que o balanceador de carga apresenta ao back-end.

Para configurar o mTLS de back-end, faça o seguinte:

• Crie um recurso de certificado do cliente que contenha o certificado do cliente (balanceador de carga) e a chave privada dele.
• Anexe o certificado do cliente ao recurso de configuração de autenticação de back-end.

Certificados gerenciados de PKI pública não são aceitos, e todos os certificados de cliente precisam ter um escopo client-auth e obedecer aos requisitos de certificado.

Se o back-end solicitar um certificado de cliente, ele precisará ser configurado para aceitar o certificado de cliente. Se o back-end recusar a conexão do balanceador de carga, ele vai retornar um código de status HTTP 502 para as solicitações que estiver encaminhando por proxy e registrar um status genérico no Cloud Logging.

Configurar o TLS autenticado de back-end e o mTLS de back-end no balanceador de carga

É possível configurar o TLS autenticado de back-end e o mTLS de back-end no balanceador de carga usando uma PKI particular ou raízes de confiança públicas.

Usar uma ICP particular

Confira a seguir uma visão geral das principais etapas que você precisa seguir para configurar o TLS autenticado de back-end e o mTLS de back-end no balanceador de carga usando certificados emitidos pela sua PKI privada. A PKI privada tem a vantagem de estar totalmente sob seu controle e isolada dos sistemas de PKI da Internet pública.

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

2. Para configurar o mTLS de back-end, crie um certificado de cliente que contenha o certificado do cliente (balanceador de carga) e a chave privada dele.

3. Crie um recurso de configuração de autenticação de back-end que faça referência à configuração de confiança. Se você quiser configurar o mTLS de back-end, o recurso de configuração de autenticação de back-end vai referenciar a configuração de confiança e o certificado do cliente.

4. Anexe o recurso de configuração de autenticação de back-end ao serviço de back-end do balanceador de carga.

Observe o seguinte:

• Não é possível enviar um certificado do cliente para o back-end sem configurar primeiro o TLS autenticado do back-end.

• Se você quiser ativar o mTLS de back-end, crie o certificado do cliente antes de configurar o recurso de configuração de autenticação de back-end.

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

• Configurar o TLS autenticado de back-end

• Configurar o mTLS de back-end

Usar raízes de confiança públicas

Além de usar certificados emitidos pela sua ICP particular para ativar o TLS autenticado de back-end, também é possível usar raízes públicas de confiança para validar o certificado de back-end.

Para usar raízes de confiança públicas, não é necessário criar uma configuração de confiança e anexá-la ao recurso de configuração de autenticação de back-end. Em vez disso, defina PUBLIC_ROOTS como um valor no campo wellKnownRoots do recurso de configuração de autenticação do back-end. No entanto, também é possível criar uma configuração de confiança que inclua explicitamente as raízes dos seus certificados emitidos publicamente, além dos certificados confiáveis pela configuração de confiança.

A configuração PUBLIC_ROOTS usa um conjunto de CAs raiz, semelhante ao conjunto de CAs raiz confiáveis pelos navegadores, que é gerenciado pelo Google e pode mudar com o tempo. Isso apresenta um risco de os certificados de back-end ficarem inválidos quando essas raízes mudarem. Se você precisar validar certificados emitidos publicamente, escolha uma CA confiável e bem estabelecida que use assinatura cruzada intermediária para emitir seus certificados de back-end e reduzir o risco de expiração ou revogação de um certificado raiz.

Usar a identidade da carga de trabalho gerenciada

É possível usar o mTLS com identidades de carga de trabalho gerenciadas.

Quando você usa uma identidade de carga de trabalho gerenciada, ela cria automaticamente os seguintes recursos:

• Configuração de confiança do Certificate Manager
• Certificado de identidade gerenciada do Certificate Manager
• Configuração de autenticação de back-end

Para saber mais, consulte Visão geral do mTLS de back-end com a Identidade da carga de trabalho gerenciada.

Etapas de validação do certificado do servidor

Ao validar o certificado do servidor durante o TLS autenticado de back-end ou a autenticação de back-end, o balanceador de carga faz o seguinte:

1. Verifique se o servidor tem a chave privada do certificado.

   O servidor prova a posse da chave privada associada ao certificado que apresenta ao balanceador de carga assinando uma informação com a chave privada e enviando-a ao balanceador de carga como parte da mensagem CertificateVerify. Em seguida, o balanceador de carga verifica essa assinatura usando a chave pública do certificado do servidor. Se a verificação de assinatura falhar, isso indica que o servidor de back-end não tem a chave privada correspondente ao certificado. Nesses casos, o balanceador de carga encerra o handshake de TLS sem registrar erros.

2. Verifique a cadeia de confiança.

   Se a configuração de confiança incluir pelo menos uma âncora de confiança ou tiver o atributo wellKnownRoots definido como PUBLIC_ROOTS, o balanceador de carga tentará verificar uma cadeia de confiança entre o certificado do servidor e a âncora de confiança configurada.

   As verificações incluem o seguinte:

   • O certificado do servidor do back-end, os certificados intermediários (se fornecidos) e o certificado raiz configurado estão em conformidade com os requisitos de certificado.
   • Para todos os certificados na cadeia de confiança, o campo de assunto no certificado pai corresponde ao campo de emissor no certificado filho. Essa verificação ajuda a garantir que a identidade (assunto) do certificado principal seja a mesma listada como emissor no certificado filho.
   • Para todos os certificados na cadeia de confiança, o identificador de chave de assunto (SKID) do certificado pai corresponde ao identificador de chave de autoridade (AKID) no certificado filho. Essa correspondência confirma que o certificado filho foi emitido pela autoridade raiz correta e que ele é confiável porque a chave pública da raiz está sendo referenciada no AKID para verificar a validade do certificado.
   Observação: os certificados do cliente autoassinados não formam uma cadeia de confiança válida e são sempre rejeitados.

3. Estabeleça uma conexão com o back-end.

   Se a validação do certificado for bem-sucedida, o balanceador de carga vai continuar com a conexão com o back-end.

   No entanto, se a validação do certificado falhar, o balanceador de carga vai encerrar a conexão com o back-end, enviar um código de status HTTP 502 ao cliente e registrar o motivo do encerramento no Cloud Logging. Em caso de erro de validação de certificado, as solicitações de entrada subsequentes acionam o balanceador de carga para reiniciar a conexão de back-end.

   A conexão de back-end também pode falhar se o servidor de back-end recusar a conexão. Com o mTLS de back-end, isso pode acontecer porque o certificado do cliente é considerado inválido. Quando a conexão com o back-end falha, o balanceador de carga responde às solicitações de proxy com um código de status HTTP 502 e registra um motivo de erro genérico no Cloud Logging.

Tratamento de erros e geração de registros

Os balanceadores de carga de aplicativos oferecem recursos detalhados de geração de registros que permitem monitorar a validação de certificados do servidor, 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.

Se a validação do certificado do servidor falhar, 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 servidor	Erro registrado
A cadeia de certificados do servidor é muito longa (mais de 10 certificados intermediários incluídos no certificado do servidor).	server_cert_chain_exceeded_limit
Um servidor ou um certificado intermediário tem um tamanho da chave RSA inválido. Nenhuma validação é executada. As chaves RSA podem ter entre 2.048 e 4.096 bits.	server_cert_invalid_rsa_key_size
Um servidor 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.	server_cert_unsupported_elliptic_curve_key
Um servidor ou certificado intermediário está usando um algoritmo não RSA ou não ECDSA. Nenhuma validação é executada.	server_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.	server_cert_pki_too_large
Um certificado intermediário fornecido para validação tinha mais de 10 restrições de nome.	server_cert_chain_max_name_constraints_exceeded
O certificado do servidor tem um campo de extensão Extended Key Usage (EKU) que não inclui serverAuth.	server_cert_chain_invalid_eku
O limite de tempo é excedido ao tentar validar a cadeia de certificados.	server_cert_validation_timed_out
O limite de profundidade ou de iteração é alcançado na tentativa de validação da cadeia de certificados. A profundidade máxima de uma cadeia de certificados é dez, incluindo os certificados raiz e do servidor. O número máximo de iterações é 100 (certificados examinados para validar a cadeia de certificados do servidor).	server_cert_validation_search_limit_exceeded
O mTLS foi configurado sem a configuração de um recurso TrustConfig.	server_cert_validation_not_performed
O servidor não forneceu o certificado solicitado durante o handshake.	server_cert_not_provided
A verificação do certificado do servidor falhou com o recurso TrustConfig.	ssl_certificate_verification_failed
O serviço não pode realizar a validação da cadeia de certificados.	server_cert_validation_unavailable
Erro interno ao validar a cadeia de certificados.	server_cert_validation_internal_error
TrustConfig não encontrado.	server_cert_trust_config_not_found
O payload do certificado do servidor (incluindo certificados intermediários) é muito grande (mais de 16 KB).	server_cert_exceeded_size_limit

Limitações

• O TLS autenticado de back-end e o mTLS de back-end não são compatíveis com balanceadores de carga de aplicativo clássicos.

• O TLS autenticado de back-end e o mTLS de back-end não são compatíveis com os seguintes tipos de back-end:

  • Back-ends de NEG global da Internet

  • Back-ends do App Engine

• As verificações de integridade não são compatíveis com a autenticação TLS nem com recursos de mTLS. Os verificadores de integridade não podem apresentar certificados de cliente nem validar certificados de servidor em relação a configurações de confiança. Se os back-ends exigirem certificados de cliente para tráfego HTTPS, verifique se as sondagens de verificação de integridade podem ser concluídas sem mTLS. Por exemplo, usando verificações de integridade TCP ou configurando um endpoint ou porta de verificação de integridade dedicada que não exija autenticação do cliente.

• O balanceador de carga não transmite o nome de host SNI do cliente da conexão TLS de front-end ao se conectar a um back-end. No entanto, os back-ends podem acessar o nome de host SNI do cliente usando um cabeçalho da solicitação personalizado.

• Para mTLS de back-end, as chaves de certificado do cliente são restritas ao seguinte:

  • As chaves RSA podem ter entre 2.048 e 4.096 bits.
  • As chaves ECDSA podem usar as curvas P-256 ou P-384.

• O TLS autenticado de back-end não é compatível com verificações de revogação de certificado.

Cotas e limites

• Um único repositório de confiança pode conter até 200 âncoras de confiança e certificados intermediários combinados, com um limite separado de 100 para certificados intermediários. No máximo três certificados intermediários podem compartilhar as mesmas informações de assunto e de chave pública do assunto.

• A profundidade máxima de uma cadeia de certificados é de 10 certificados, incluindo os certificados raiz e folha. O número máximo de certificados intermediários que podem ser avaliados ao tentar criar a cadeia de confiança é 100.

• O TLS autenticado de back-end limita a cadeia de certificados recebida do back-end a no máximo 16 KB e 10 certificados.

• Os certificados raiz usados para validação não podem conter mais de 10 restrições de nome.

• O número máximo de nomes alternativos de assunto permitidos no campo tlsSettings.subjectAltNames[] é 5.

A seguir

• Configurar o TLS autenticado de back-end usando certificados autogerenciados