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.

mTLS de front-end e back-end.
mTLS 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 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 balanceadores de carga de aplicativo externos globais.

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 de certificação (CA). O TLS autenticado de back-end 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 de 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 requerente (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 para TLS autenticado de back-end e mTLS de back-end, 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 leaf fornecidos pelo back-end têm os seguintes requisitos:

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

  • Os certificados raiz e intermediários usados com TLS autenticado de back-end têm os seguintes requisitos:

    • 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 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 de 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-o para o recurso 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 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.
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 o TLS autenticado de back-end e o mTLS de 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. Para configurar a confiança, use 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 na Trust Store.

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 armazenamento 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

O recurso Configuração de autenticação de back-end (BackendAuthenticationConfig), anexado ao serviço de back-end do balanceador de carga, permite o seguinte:

  • TLS autenticado de back-end (usando a configuração de confiança e as raízes públicas de confiança)
  • 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 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.

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

  • Certificado do cliente (clientCertificate): o certificado do cliente que o balanceador de carga usa para expressar sua identidade no back-end, se a conexão com o back-end usar mTLS. Para o TLS autenticado de back-end (autenticação de back-end), esse campo pode ficar em branco. Nesse caso, o balanceador de carga autentica apenas o back-end, mas não a si mesmo, no 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)

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.

O mTLS de back-end também é compatível com identidades de carga de trabalho gerenciadas do Compute Engine ao configurar certificados gerenciados pelo Gerenciador de certificados. Certificados gerenciados de PKI pública não são aceitos, e todos os certificados do 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 fazendo 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 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 particular 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 inclua 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 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 Configuração de autenticação de back-end ao serviço de back-end do balanceador de carga.

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

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, você também pode 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 de 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 a 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.

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 usando 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 de 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 secundário.
    • 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.

  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 um 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 ele considera o certificado do cliente 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 de 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 de chave RSA inválido.

Nenhuma validação é executada.

As chaves RSA podem ter de 2.048 a 4.096 bits.

 server_cert_invalid_rsa_key_size

Um servidor ou 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 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 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

Você configurou o mTLS sem configurar 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 só podem ser configurados para balanceadores de carga de aplicativo externos globais. Os balanceadores de carga de aplicativo clássicos não são compatíveis com TLS autenticado e mTLS de back-end.

  • 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

  • Para ativar o mTLS de back-end, também é necessário configurar o TLS autenticado de back-end.

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

  • As verificações de integridade usadas pelos back-ends não implementam a autenticação TLS nem os recursos de mTLS. Configure os back-ends com endpoints de verificação de integridade que podem responder a solicitações HTTP ou HTTPS.

  • 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 do host SNI do cliente usando um cabeçalho de solicitação personalizado.

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

    • As chaves RSA podem ter de 2.048 a 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 armazenamento 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