O Gerenciador de certificados usa um mecanismo de mapeamento flexível que fornece controle granular sobre quais certificados podem ser atribuídos e como exibi-los para cada nome de domínio no seu ambiente. O mecanismo inclui as seguintes entidades:
- Certificados
- Mapas de certificados
- Entradas do mapa de certificado
- Autorizações de domínio
No diagrama a seguir, ilustramos 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 de destino e proxies SSL de destino. Para mais informações sobre as diferenças entre esses tipos de proxy, consulte Como usar proxies de destino.
Para mais informações sobre os tipos de certificado compatíveis com o 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) (SSL) 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 certificados que o Google Cloud recebe e gerencia para você.
- Os certificados autogerenciados são aqueles que você recebe, provisiona e renova por conta própria.
Quando você emite um certificado usando uma CA publicamente confiável, a CA publica informações sobre o domínio associado nos registros de 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 CAs publicamente confiáveis e se aplica aos certificados gerenciados pelo Google e autogerenciados. No entanto, se você usar o Certificate Authority Service para emitir seu certificado gerenciado pelo Google, o Gerenciador de certificados não publicará nenhuma informação nos registros de 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
O gerenciamento de certificados TLS (SSL) gerenciados pelo Google para sites e aplicativos pode ser uma tarefa complexa e demorada que geralmente envolve configuração manual e manutenção regular. O Certificate Manager é um serviço criado para ajudar você a simplificar 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 autorização baseada em balanceador de carga ou com base em DNS. O Gerenciador de certificados oferece suporte a certificados RSA gerenciados pelo Google.
Por padrão, a AC 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 recorrerá à CA do Let's Encrypt. Por exemplo, a AC do Google pode se recusar a emitir um certificado para o domínio ou o registro de autorização da AC proíbe explicitamente a AC do Google de emitir certificados para esse domínio.
Não há suporte para a 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ó são compatíveis com a 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 Certificate Authority Service como emissor do certificado. Para mais informações sobre pools de CA, 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. Você é responsável por emitir e renovar manualmente os certificados autogerenciados.
Com o Gerenciador de certificados, também é possível implantar certificados autogerenciados regionais em proxies do proxy seguro da Web 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 solicitar um nome de host especificado em um mapa de certificado, o balanceador de carga exibirá 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 nomes de domínio distintos, como domínios ou subdomínios. Por exemplo, é possível fazer upload de um certificado ECDSA e 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
Com o Gerenciador de certificados, é possível comprovar a propriedade de domínios para os quais você quer emitir certificados gerenciados pelo Google, conforme descrito na tabela a seguir.
| Autorização do balanceador de carga | Autorização de DNS | |
|---|---|---|
| Complexidade da configuração | não requer outras etapas 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 de 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 da 443 e camadas de CDN na frente do proxy de destino. |
| Velocidade de provisionamento | Só será possível provisionar certificados depois que o balanceador de carga estiver totalmente configurado e atender ao 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 CA do Let's Encrypt. Com ele, é possível especificar vários parâmetros que regem a emissão e a expiração de certificados, 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, inclui 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, a âncora de confiança e entidades de certificado intermediárias.
Lojas de confiança
Um repositório de confiança representa a configuração da chave secreta de confiança no Gerenciador de certificados para uso em cenários de autenticação TLS mútua. Ele encapsula uma única âncora de confiança e, opcionalmente, um ou mais certificados intermediários.
Âncoras de confiança
Uma âncora de confiança representa um único certificado raiz para uso em cenários de autenticação TLS mútua. Ele é encapsulado 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 armazenamento de confiança encapsulado 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 para cada solicitação de conexão, além da lista de certificados intermediários especificados na própria solicitação.
Certificados que exigem uma lista de permissões
Opcionalmente, se você precisar usar um certificado autoassinado,
expirado ou inválido, ou se você não tiver acesso aos certificados raiz e
intermediário, poderá adicionar esse certificado à configuração de confiança no
campo allowlistedCertificates. Você não precisa de 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 de chave privada seja estabelecida e as restrições no campo SAN do certificado sejam atendidas.
Lógica de seleção de certificados
Em um nível alto, o balanceador de carga seleciona um certificado da seguinte maneira:
- O 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 que o cliente fornece e nas entradas do mapa de certificado configuradas. Os fatores que determinam qual certificado o balanceador de carga seleciona são os seguintes:
Correspondência exata de nome do host: se o cliente informar um nome de host que corresponde exatamente a uma entrada no mapa de certificados provisionados, o balanceador de carga vai 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 vai 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 pré-configurada do mapa de certificado principal: o balanceador de carga seleciona uma entrada de mapa de certificado principal pré-configurada na ausência de correspondência de nome do host ou de uma entrada correspondente do mapa de certificado provisionada.
Falha no handshake: o handshake falha quando o balanceador de carga não encontra 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 provisionadas ou não fornece um nome de host.
- Uma entrada correspondente do mapa de certificado principal não será encontrada ou se você não tiver configurado uma entrada do mapa de certificado principal.
Prioridade do certificado
O balanceador de carga seleciona um certificado dentro de uma entrada de mapa de certificado com base no seguinte:
- Tipo de certificado. Se o cliente conectado oferecer suporte aos certificados ECDSA mais seguros, o balanceador de carga vai priorizá-los em vez dos certificados RSA. Se o cliente não indicar suporte a certificados ECDSA, o balanceador de carga vai disponibilizar um certificado RSA.
- Tamanho do certificado. O balanceador de carga prioriza certificados do menor para o maior.
Nomes de domínio curinga
As regras a seguir se aplicam aos nomes de domínio com caracteres curinga:
- Somente certificados gerenciados pelo Google com autorização de DNS e certificados gerenciados pelo Google com CA Service são compatíveis com nomes de domínio com caracteres curinga. Os certificados gerenciados pelo Google com autorização do balanceador de carga não são compatíveis com nomes de domínio com caracteres curinga.
- Uma correspondência exata tem precedência sobre um caractere curinga quando ambos estã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 comwww.myorg.example.comsempre selecionará a entrada dewww.myorg.example.com, mesmo que uma entrada para*.myorg.example.comtambém exista. - 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 uma parahost1.hosts.myorg.example.com.
Public CA
Para usar o recurso de AC pública do Gerenciador de certificados, é preciso conhecer os seguintes conceitos:
Cliente ACME. O cliente do ambiente de gerenciamento automático de certificados (ACME, na sigla em inglês) usa o protocolo ACME (em inglês). 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 do ACME que está usando com a CA pública do Gerenciador de certificados ao projeto do Google Cloud de destino usando vinculação de conta externa. Para fazer isso, é preciso registrar cada conta ACME usando um secret vinculado ao projeto do Google Cloud correspondente. 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ê prove seu controle sobre os domínios listados nesse certificado. Você pode provar o controle do domínio solucionando desafios. Public CA autorizará os nomes de domínio depois que você comprovar seu controle dos domínios de destino.
Depois de conseguir as autorizações necessárias, você pode solicitar certificados válidos apenas por um período específico. Após esse período, é necessário revalidar o nome de domínio resolvendo um dos três tipos de desafio para continuar solicitando certificados.
Tipos de desafio
Public CA oferece suporte aos seguintes tipos de desafio:
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 da negociação do protocolo de camada de aplicativo TLS (ALPN, na sigla em inglês). É necessário 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 a extensão do desafio ACME TLS-ALPN.
Desafio de DNS. exige a adição de um registro DNS específico em um local definido para comprovar 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 de DNS, subdomain1.myorg.example.com e subdomain2.myorg.example.com serão cobertos automaticamente pelo certificado 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 os desafios que não são de DNS.
Lógica da solução do desafio
A lógica do 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. A localização 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 após a conclusão desse processo. O cliente pode solicitar um certificado com esse nome de domínio. Você precisa resolver apenas um desafio por nome de domínio.