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 mais informações sobre os tipos de certificados que 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 aqueles que o Google Cloud recebe e gerencia para você.
- Os certificados autogerenciados são aqueles que você recebe, provisiona e renove-se.
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 padrão de emissão de certificados adotado por todas as CAs publicamente confiáveis e se aplica a Certificados gerenciados pelo Google e certificados autogerenciados. No entanto, se você usar o Certificate Authority Service emitir seu certificado gerenciado pelo Google; O Gerenciador de certificados não publica informações no registros de Transparência dos certificados.
Para mais informações, consulte Transparência dos certificados.
Para aprender a 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 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 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 O certificado gerenciado pelo Google é emitido ou renovado, e usa um certificado recém-gerado chave privada. Se você não consiga um certificado da CA do Google para um domínio específico, O Gerenciador de certificados usa a CA do Let's Encrypt. Para exemplo, a AC 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 AC do Google de emitir certificados do 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 Especificar as CAs que podem emitir seu certificado gerenciado pelo Google.
Os certificados regionais gerenciados pelo Google são compatíveis apenas com o DNS autorização e obter 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 nos processos aprovados pelo Google ACs públicas para emitir certificados, configure Gerenciador de certificados para usar um pool de ACs do Certificate Authority Service (em inglês) como emissor do certificado. Para mais informações sobre pools de ACs, consulte Como criar pools de CA.
Certificados autogerenciados
Caso seus requisitos comerciais não permitam que você use serviços gerenciados pelo Google, , é possível fazer o upload de certificados emitidos por CAs externas, juntamente com as chaves associadas. Você é responsável por emitir e renovar manualmente e 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, a carga de gateway de serviço da Web disponibiliza 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. Você pode definir diferentes conjuntos de certificados para diferentes nomes de domínio, como domínios ou subdomínios. Por exemplo, você pode fazer upload de um ECDSA e um RSA certificado e mapeie-os para o mesmo nome de domínio. Quando um cliente se conecta esse nome de domínio, o balanceador de carga negocia o tipo de certificado a ser exibido o 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 alterações no seu DNS configuração do Terraform. | Exige que você crie uma autorização de DNS e adicione a autorização registro CNAME à configuração do 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 que você especificar uma série de parâmetros que regem a emissão e o vencimento do certificado, bem como selecionar o algoritmo principal para certificados emitidos dessa forma.
Configurações de confiança
Uma configuração de confiança é um recurso que representa sua configuração de infraestrutura de chave pública (ICP) no Gerenciador de certificados para uso em cenários de autenticação TLS mútua. Ele 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.
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. 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 TLS mútuo em vários cenários de autenticação. 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.
É possível encapsular um ou mais certificados intermediários 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 precisar usar um certificado que tenha sido autoassinado, você
tiver expirado ou for inválido de outra forma, ou se você não tiver acesso à raiz e
e intermediários, adicione-os à configuração de confiança no
o campo allowlistedCertificates. Não é preciso ter uma loja de confiança para adicionar uma
para 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
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 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 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 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 correspondente do mapa de certificado provisionado.
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 do 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 conectado oferecer suporte ao método ECDSA mais seguro, certificados, o balanceador de carga os prioriza em relação aos 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 certificados dos menores para o 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 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 com caracteres 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 relacionadawww.myorg.example.comsempre seleciona a entrada parawww.myorg.example.com, mesmo que uma também existe 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. Um cliente do ambiente de gerenciamento automático de certificados (ACME) é um certificado de gerenciamento 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). É 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. O Public CA autoriza os nomes de domínio depois que você prova que e controle dos domínios de destino.
Depois de conseguir as autorizações necessárias, você pode solicitar certificados que sejam válidos apenas por um período de tempo específico. Após esse período, é necessário revalidar o nome de domínio resolvendo um dos três tipos de desafios 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 Local em um servidor HTTP (porta 80) para o Public CA recuperar e verificar. Para mais informações, consulte Desafio HTTP.
TLS-negociação do protocolo da camada de aplicativo (ALPN, na sigla em inglês). Requer um servidor para fornecer um certificado específico durante uma negociação TLS na porta 443 para comprovar o controle de um domínio. Para mais informações, consulte Extensão de 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 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 uma solicitação HTTP ou
O desafio TLS-ALPN que o cliente só pode solicitar para incluir myorg.example.com em
o certificado e não é possível validar *.myorg.example.com usando os desafios que não são de DNS.
Lógica de solução do desafio
A lógica do desafio de CA 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.