O Gerenciador de certificados usa um mecanismo de mapeamento flexível que oferece controle granular sobre quais certificados podem ser atribuídos e como veiculá-los para cada nome de domínio no ambiente. O mecanismo inclui as seguintes entidades:
- Certificados
- Mapas de certificados
- Entradas do mapa de certificado
- Autorizações de domínio
O diagrama a seguir ilustra as relações entre essas entidades para um proxy de destino típico especificado em uma regra de encaminhamento do balanceador de carga:
O Gerenciador de certificados oferece suporte a proxies HTTPS e SSL de destino. Para mais informações sobre as diferenças entre esses tipos de proxy, consulte Como usar proxies de destino.
Para informações sobre os tipos de certificados aceitos pelo Gerenciador de certificados, consulte Visão geral da implantação.
Certificados
Por padrão, um certificado representa um único certificado X.509 Transport Layer Security (TLS, na sigla em inglês) (SSL, na sigla em inglês) emitido para nomes de domínio ou caracteres curinga de domínio específicos.
O Gerenciador de certificados oferece suporte aos seguintes tipos de certificado:
- Os certificados gerenciados pelo Google são recebidos e gerenciados pelo Google Cloud para você.
- Os certificados autogerenciados são conseguidos, provisionados e renovados por você.
Quando você emite um certificado usando uma CA confiável publicamente, a CA publica informações sobre o domínio associado nos registros da Transparência dos certificados, que são acessíveis publicamente. Isso faz parte do processo padrão de emissão de certificados adotado por todas as ACs publicamente confiáveis e se aplica a certificados gerenciados pelo Google e autogerenciados. No entanto, se você usar o Certificate Authority Service para emitir o certificado gerenciado pelo Google, o Gerenciador de certificados não publicará nenhuma informação nos registros da Transparência dos certificados.
Para mais informações, consulte Transparência dos certificados.
Para saber como implantar um certificado com o Gerenciador de certificados, consulte Visão geral da implantação.
Certificados gerenciados pelo Google
Gerenciar certificados TLS (SSL) gerenciados pelo Google para seus sites e aplicativos pode ser uma tarefa complexa e demorada que geralmente envolve configuração manual e manutenção regular. O Gerenciador de certificados é um serviço projetado para ajudar você a otimizar esse processo, fornecendo uma plataforma centralizada. Você pode delegar a responsabilidade de emitir e renovar certificados ao gerenciador de certificados, liberando seu tempo para se concentrar em outras tarefas essenciais.
Você pode verificar a propriedade do domínio relevante usando a autorização baseada no balanceador de carga ou em DNS. O Gerenciador de certificados dá suporte a certificados RSA gerenciados pelo Google.
Por padrão, a CA do Google emite certificados gerenciados pelo Google. Quando um novo certificado gerenciado pelo Google é emitido ou renovado, ele usa uma chave privada recém-gerada. Se você não conseguir um certificado da CA do Google para um domínio específico, o Gerenciador de certificados volta para a CA da Let's Encrypt. Por exemplo, a CA do Google pode se recusar a emitir um certificado para o domínio ou seu registro de autorização de CA proíbe explicitamente a emissão de certificados para esse domínio.
Não há suporte para autenticação apenas no lado do cliente.
Para instruções sobre como restringir as ACs que podem emitir certificados para seus domínios, consulte Como especificar as ACs que podem emitir seu certificado gerenciado pelo Google.
Os certificados regionais gerenciados pelo Google (pré-lançamento) só aceitam autorização baseada em DNS e recebem certificados da CA do Google.
Certificados gerenciados pelo Google emitidos pelo Certificate Authority Service
Se você quiser usar sua própria cadeia de confiança em vez de confiar em CAs públicas aprovadas pelo Google para emitir seus certificados, configure o Gerenciador de certificados para usar um pool de CAs do Serviço de autoridade de certificação como o emissor do certificado. Para mais informações sobre pools de CAs, consulte Como criar pools de CA.
Certificados autogerenciados
Se os requisitos da sua empresa não permitirem o uso de certificados gerenciados pelo Google, faça o upload de certificados emitidos por CAs externas com as chaves associadas a elas. Você é responsável por emitir e renovar manualmente os certificados autogerenciados.
O Gerenciador de certificados também permite implantar certificados autogerenciados regionais em proxies Secure Web Proxy e balanceadores de carga regionais.
Mapas de certificados
Um mapa de certificado faz referência a uma ou mais entradas que atribuem certificados específicos a nomes de host específicos. As entradas do mapa de certificado também definem a lógica de seleção que o balanceador de carga segue ao estabelecer conexões com o cliente. É possível associar um mapa de certificado a vários proxies de destino para reutilização em vários balanceadores de carga.
Se um cliente solicita um nome de host especificado em um mapa de certificado, o balanceador de carga exibe os certificados mapeados para esse nome de host. Caso contrário, o balanceador de carga exibirá o certificado principal. Para mais informações, consulte Lógica de seleção de certificados.
Entradas do mapa de certificado
Uma entrada do mapa de certificados é uma lista de certificados exibidos para um nome de domínio específico. É possível definir diferentes conjuntos de certificados para diferentes nomes de domínio, como domínios ou subdomínios. Por exemplo, é possível fazer upload de um ECDSA e um certificado de RSA e mapeá-los para o mesmo nome de domínio. Quando um cliente se conecta a esse nome de domínio, o balanceador de carga negocia o tipo de certificado a ser exibido ao cliente durante o handshake.
Autorizações de domínio
O Gerenciador de certificados permite comprovar a propriedade de domínios para que você quer emitir certificados gerenciados pelo Google, conforme descrito na tabela a seguir.
| Autorização do balanceador de carga | Autorização de DNS | |
|---|---|---|
| Complexidade de configuração | Não requer etapas adicionais de configuração ou alterações na sua configuração de DNS. | Exige que você crie uma autorização de DNS e adicione o registro CNAME correspondente à configuração do DNS. |
| Segurança de rede | O balanceador de carga precisa estar totalmente acessível pela Internet na porta 443, incluindo a configuração de DNS para todos os domínios atendidos pelo certificado. Não funciona com outras configurações. | Funciona com configurações de alta complexidade, como portas diferentes de 443 e camadas de CDN na frente do proxy de destino. |
| Velocidade de provisionamento | Só é possível provisionar certificados depois que o balanceador de carga for totalmente configurado e estiver veiculando tráfego de rede. | É possível provisionar certificados com antecedência, antes que o proxy de destino esteja pronto para atender ao tráfego de rede. |
Para entender como o Gerenciador de certificados verifica a propriedade do domínio usando cada método, consulte Autorizações de domínio para certificados gerenciados pelo Google.
Configurações de emissão de certificados
Uma configuração de emissão de certificados é um recurso que permite que o Gerenciador de certificados use um pool de CAs da sua própria instância do Certificate Authority Service para emitir certificados gerenciados pelo Google em vez da CA do Google ou da Let's Encrypt CA. Ele permite especificar vários parâmetros que regem a emissão e a expiração do certificado, além de selecionar o algoritmo de chave para certificados emitidos dessa maneira.
Configurações de confiança
Uma configuração de confiança é um recurso que representa a configuração da infraestrutura de chave pública (ICP) no Gerenciador de certificados para uso em cenários de autenticação TLS mútua. Ela encapsula um único repositório de confiança, que, por sua vez, encapsula uma âncora de confiança e, opcionalmente, um ou mais certificados intermediários.
Para saber mais sobre a autenticação TLS mútua, consulte Autenticação TLS mútua na documentação do Cloud Load Balancing.
Um recurso de configuração de confiança encapsula o repositório de confiança, uma âncora de confiança e entidades de certificado intermediárias.
Lojas de confiança
Um repositório de confiança representa a configuração do secret de confiança no Gerenciador de certificados para uso em cenários de autenticação TLS mútua. Ela encapsula uma única âncora de confiança e, opcionalmente, um ou mais certificados intermediários.
Âncoras confiáveis
Uma âncora de confiança representa um único certificado raiz para uso em cenários de autenticação TLS mútua. Ela é encapsulada em um repositório de confiança.
Certificados intermediários
Um certificado intermediário representa um único certificado intermediário assinado por um certificado raiz ou um certificado intermediário referenciado no repositório de confiança de encapsulamento para uso em cenários de autenticação TLS mútua.
Um ou mais certificados intermediários podem ser encapsulados em um repositório de confiança, dependendo da configuração da ICP. Todos os certificados intermediários especificados em uma configuração de confiança são incluídos como parte da avaliação de confiança de cada solicitação de conexão, além da lista de certificados intermediários especificados na própria solicitação.
Certificados autorizados
Um certificado na lista de permissões representa qualquer certificado que possa ser encapsulado na configuração de confiança para que seja sempre considerado válido. Um certificado da lista de permissões sempre é 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. Os certificados expirados também são considerados válidos quando estão na lista de permissões. Você não precisa de um repositório de confiança ao usar certificados da lista de permissões.
Lógica de seleção de certificados
Em um nível alto, o balanceador de carga seleciona um certificado da seguinte maneira:
- Um cliente inicia um handshake. Durante essa etapa, ele fornece ao balanceador de carga uma lista de algoritmos criptográficos que podem ser usados para concluir o handshake e, opcionalmente, um nome do host.
O balanceador de carga seleciona um certificado para concluir o handshake seguro com base no nome do host fornecido pelo cliente e nas entradas de mapa de certificado configuradas. Os fatores que determinam qual certificado o balanceador de carga seleciona são os seguintes:
Correspondência exata do nome do host: se o cliente informar um nome de host que corresponda exatamente a uma entrada no mapa de certificado provisionado, o balanceador de carga selecionará o certificado correspondente.
Correspondência de nome de host curinga: se o nome do host do cliente não corresponder a nenhuma entrada, mas corresponder a um nome de host curinga em uma entrada de mapa de certificado, o balanceador de carga selecionará o certificado correspondente dessa entrada. Por exemplo, uma entrada de caractere curinga configurada como
*.myorg.example.comabrange subdomínios de primeiro nível no domíniomyorg.example.com.Nenhuma correspondência de nome de host e uma entrada de mapa de certificado principal pré-configurada: o balanceador de carga seleciona uma entrada de mapa de certificado principal pré-configurada na ausência de uma correspondência de nome de host ou de uma entrada de mapa de certificado provisionado correspondente.
Falha no handshake: o handshake falhará se o balanceador de carga não encontrar um certificado correspondente pelos seguintes motivos:
- O cliente fornece um nome de host que não corresponde a nenhum nome de host exato ou curinga especificado em todas as entradas do mapa de certificado provisionado ou não fornece um nome do host.
- Uma entrada correspondente do mapa de certificado principal não foi encontrada ou se você não configurou uma entrada do mapa de certificado principal.
Prioridade do certificado
O balanceador de carga seleciona um certificado em uma entrada do mapa de certificado com base no seguinte:
- Tipo de certificado. Se o cliente conectado aceitar os certificados ECDSA mais seguros, o balanceador de carga os priorizará em relação aos certificados RSA. Se o cliente não indicar suporte para certificados ECDSA, o balanceador de carga exibirá um certificado RSA.
- Tamanho do certificado. O balanceador de carga prioriza os certificados do menor para o maior.
Nomes de domínio com caracteres curinga
As regras a seguir se aplicam a nomes de domínio com caractere curinga:
- Apenas certificados gerenciados pelo Google com autorização de DNS e certificados gerenciados pelo Google com serviço de CA são compatíveis com nomes de domínio com caractere curinga. Os certificados gerenciados pelo Google com autorização do balanceador de carga não são compatíveis com nomes de domínio curinga.
- Uma correspondência exata tem precedência sobre um caractere curinga quando ambos são definidos na
entrada. Por exemplo, se você configurou entradas do mapa de certificado para
www.myorg.example.come*.myorg.example.com, uma solicitação de conexão emwww.myorg.example.comsempre selecionará a entrada parawww.myorg.example.com, mesmo que também exista uma entrada para*.myorg.example.com. - Nomes de domínio curinga correspondem a apenas um nível de subdomínio. Por exemplo, uma solicitação de conexão para
host1.myorg.example.comseleciona uma entrada de mapa de certificado para*.myorg.example.com, mas não parahost1.hosts.myorg.example.com.
Public CA
Para usar o recurso de CA pública do Gerenciador de certificados, você precisa conhecer os seguintes conceitos:
Cliente ACME: O ambiente de gerenciamento automático de certificados (ACME, na sigla em inglês) é um cliente de gerenciamento de certificados que usa o protocolo ACME. Seu cliente ACME precisa oferecer suporte à vinculação de contas externas (EAB, na sigla em inglês) para funcionar com a CA pública.
Vinculação de conta externa (EAB, na sigla em inglês). Vincule cada conta ACME que você está usando com a CA pública do Gerenciador de certificados ao projeto do Google Cloud de destino usando a vinculação de conta externa. Para isso, registre cada conta da ACME usando um secret vinculado ao projeto correspondente do Google Cloud. Para mais informações, consulte Vinculação de conta externa.
Desafios do Public CA
Quando você usa o Public CA para solicitar um certificado, o Gerenciador de certificados pede que você comprove seu controle sobre os domínios listados nesse certificado. Você pode resolver desafios para provar o controle de domínio. Public CA autoriza os nomes de domínio depois que você prova seu controle sobre os domínios de destino.
Depois de receber as autorizações necessárias, você pode solicitar certificados válidos apenas por um período específico. Após esse período, você precisará revalidar o nome de domínio resolvendo um dos três tipos de desafios para continuar solicitando certificados.
Tipos de desafio
Public CA é compatível com os seguintes tipos de desafios:
Desafio HTTP: Esse desafio envolve a criação de um arquivo em um local conhecido em um servidor HTTP (porta 80) para o Public CA recuperar e verificar. Para mais informações, consulte Desafio HTTP.
Desafio de negociação do protocolo TLS-Application Layer (ALPN): Requer que um servidor forneça um certificado específico durante uma negociação de TLS na porta 443 para comprovar o controle sobre um domínio. Para mais informações, consulte Extensão de desafio TLS-ALPN ACME.
Desafio de DNS: Requer a adição de um registro DNS específico em um local definido para provar o controle sobre um domínio. Para mais informações, consulte Desafio de DNS.
Se você usar o desafio HTTP ou TLS-ALPN para validar um nome de domínio, o cliente só poderá solicitar que os nomes de domínio validados sejam incluídos em um certificado. Se você usar o desafio de DNS, o cliente também poderá solicitar que subdomínios desse nome de domínio sejam incluídos em um certificado.
Por exemplo, se você validar *.myorg.example.com usando o desafio DNS,
subdomain1.myorg.example.com e subdomain2.myorg.example.com serão cobertos automaticamente
pelo certificado de caractere curinga. No entanto, se você validar myorg.example.com usando um desafio HTTP ou
TLS-ALPN, o cliente só poderá solicitar a inclusão de myorg.example.com no
certificado e não será possível validar *.myorg.example.com usando desafios não DNS.
Lógica da solução do desafio
A lógica de desafio de CA pública é a seguinte:
- O Public CA fornece um token aleatório.
- O cliente disponibiliza o token em um local bem definido. O local depende do desafio.
- O cliente indica ao Public CA que preparou o desafio.
- Public CA verifica se o token presente no local esperado corresponde ao valor esperado.
O nome de domínio será autorizado depois que esse processo for concluído. O cliente pode solicitar um certificado com esse nome de domínio. Você precisa resolver apenas um desafio por nome de domínio.