O Gerenciador de certificados usa um mecanismo de mapeamento flexível que oferece controle granular sobre quais certificados você pode atribuir e como servi-los para cada nome de domínio no seu ambiente. O mecanismo inclui as seguintes entidades:
- Certificados
- Mapas de certificados
- Entradas do mapa de certificados
- 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 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 específicos ou curingas de domínio.
O Gerenciador de certificados oferece suporte aos seguintes tipos de certificados:
- Os certificados gerenciados pelo Google são certificados que Google Cloud recebe e gerencia para você.
- Certificados autogerenciados são certificados que você recebe, provisiona e renova.
Quando você emite um certificado usando uma AC confiável publicamente, ela 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 ACs de confiança pública e se aplica a certificados gerenciados pelo Google e autogerenciados. No entanto, se você usar o serviço de autoridade certificadora para emitir seu certificado gerenciado pelo Google, o Gerenciador de certificados não vai 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 a 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 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 importantes.
É possível verificar a propriedade do domínio relevante usando a autorização baseada em balanceador de carga ou 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 AC do Google para um domínio específico, o Gerenciador de certificados vai usar a AC 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 pode proibir explicitamente a AC do Google de emitir certificados para esse domínio.
Não há suporte para autenticação apenas do 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 só oferecem suporte à autorização com base no DNS e à obtenção de certificados da AC 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 depender de autoridades de certificação públicas aprovadas pelo Google para emitir certificados, configure o Certificate Manager para usar um pool de ACs do Certificate Authority Service como emissor de certificados. Para mais informações sobre os pools de ACs, consulte Como criar pools de ACs.
Certificados autogerenciados
Se os requisitos de negócios não permitirem o uso de certificados gerenciados pelo Google, será possível fazer upload de certificados emitidos por ACs externas com as chaves associadas. Você é responsável por emitir e renovar manualmente certificados autogerenciados.
O Gerenciador de certificados também permite implantar certificados autogerenciados regionais em proxies do 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 certificados também definem a lógica de seleção que o balanceador de carga segue ao estabelecer conexões do 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 vai fornecer os certificados mapeados para esse nome de host. Caso contrário, o balanceador de carga vai servir o certificado principal. Para mais informações, consulte Lógica de seleção de certificados.
Entradas do mapa de certificados
Uma entrada de mapa de certificado é 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 certificado ECDSA e um certificado 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 fornecido ao cliente durante o handshake.
Autorizações de domínio
O Gerenciador de certificados permite provar a propriedade dos 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 instalação | Não requer etapas de configuração adicionais ou mudanças na configuração de DNS. | Requer 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 ser 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 foi totalmente configurado e está servindo o 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 Certificate Manager use um pool de AC da sua própria instância do Certificate Authority Service para emitir certificados gerenciados pelo Google em vez da AC do Google ou da Let's Encrypt. Ele permite 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, 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 entidades de repositório de confiança, âncora de confiança e certificado intermediário.
Repositórios de confiança
Um repositório de confiança representa a configuração de segredo 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 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 assinado por um certificado raiz ou um certificado intermediário referenciado no repositório 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 uma loja de certificados 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 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 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 da chave privada seja estabelecida e as restrições no campo SAN do certificado sejam atendidas.
Lógica de seleção de certificado
De modo geral, 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 de 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 fornecer um nome de host que corresponda exatamente a uma entrada no mapa de certificados provisionado, o balanceador de carga vai selecionar o certificado correspondente.
Correspondência de nome de host com caractere curinga: se o nome de host do cliente não corresponder a nenhuma entrada, mas corresponder a um nome de host com caractere curinga em uma entrada do mapa de certificados, o balanceador de carga vai selecionar o certificado correspondente a essa entrada. Por exemplo, uma entrada curinga configurada como
*.myorg.example.comabrange subdomínios de primeiro nível no domíniomyorg.example.com.Sem 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 de handshake: o handshake falha se o balanceador de carga não encontrar um certificado correspondente devido aos 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 de mapa de certificado provisionadas ou não fornece um nome de host.
- Uma entrada de mapa de certificado principal correspondente não foi encontrada ou você não configurou uma entrada de mapa de certificado principal.
Prioridade do certificado
O balanceador de carga seleciona um certificado em uma entrada do mapa de certificados com base nesta informação:
- Tipo de certificado. Se o cliente de conexão oferecer suporte aos certificados ECDSA mais seguros, o balanceador de carga vai priorizar esses certificados em vez dos certificados RSA. Se o cliente não indicar suporte para certificados ECDSA, o balanceador de carga vai exibir um certificado RSA.
- Tamanho do certificado. O balanceador de carga prioriza os certificados do menor ao maior.
Nomes de domínio curinga
As regras a seguir se aplicam a nomes de domínio curinga:
- Somente certificados gerenciados pelo Google com autorização de DNS e certificados gerenciados pelo Google com o serviço de AC são compatíveis com nomes de domínio 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 de mapeamento de certificado para
www.myorg.example.come*.myorg.example.com, uma solicitação de conexão contrawww.myorg.example.comsempre seleciona a entrada parawww.myorg.example.com, mesmo que uma entrada para*.myorg.example.comtambém exista. - Os nomes de domínio com caractere curinga correspondem apenas a 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.
AC pública
Para usar o recurso de AC público do Gerenciador de certificados, você precisa conhecer os seguintes conceitos:
Cliente ACME. Um cliente do Ambiente de gerenciamento automático de certificados (ACME) é um cliente de gerenciamento de certificados que usa o protocolo ACME. Seu cliente ACME precisa oferecer suporte à vinculação de conta externa (EAB) para funcionar com a AC pública.
Vinculação de conta externa (EAB). É necessário vincular cada conta do ACME que você está usando com a AC pública do Certificate Manager ao projeto do Google Cloud de destino usando a vinculação de conta externa. Para fazer isso, registre cada conta do ACME usando um segredo vinculado ao projeto correspondente do Google Cloud. Para mais informações, consulte Vinculação de conta externa.
Desafios de ACs públicas
Quando você usa uma AC pública 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 resolvendo desafios. A AC pública autoriza os nomes de domínio depois que você prova o controle dos domínios de destino.
Depois de receber as autorizações necessárias, você poderá solicitar certificados válidos apenas por um período específico. Após esse período, será necessário validar novamente o nome de domínio resolvendo um dos três tipos de desafio para continuar solicitando certificados.
Tipos de desafio
A AC pública oferece suporte aos 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 que a AC pública o recupere e verifique. Para mais informações, consulte Desafio HTTP.
TLS-negociação do protocolo da camada de aplicativo (ALPN, na sigla em inglês). Requer que um servidor forneça um certificado específico durante uma negociação TLS na porta 443 para comprovar o controle sobre um domínio. Para mais informações, consulte Extensão de desafio ACME TLS-ALPN.
Desafio de DNS. Requer 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 Verificação DNS.
Se você usar o desafio HTTP ou o desafio 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 a verificação 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 a verificação DNS,
subdomain1.myorg.example.com e subdomain2.myorg.example.com serão automaticamente cobertos
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 não DNS.
Lógica de desafio da solução
A lógica do desafio da AC pública é a seguinte:
- A AC pública fornece um token aleatório.
- O cliente disponibiliza o token em um local bem definido. O local depende do desafio.
- O cliente indica à AC pública que preparou a contestação.
- A AC pública 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.