O Gerenciador de certificados usa um mecanismo de mapeamento flexível que oferece controle granular sobre quais certificados podem ser atribuídos e 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
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 de destino e proxies SSL de destino. Para mais informações sobre as diferenças entre esses tipos de proxy, consulte Uso de proxies de destino.
Para mais informações sobre os tipos de certificados que o Gerenciador oferece suporte, consulte Visão geral da implantação.
Certificados
Por padrão, um certificado representa uma única Transport Layer Security X.509 Certificado TLS (SSL) emitido para nomes de domínio ou domínios específicos caracteres curinga.
O Gerenciador de certificados oferece suporte aos seguintes tipos de certificado:
- Os certificados gerenciados pelo Google são certificados pelo Google Cloud coleta e gerencia para você.
- Os certificados autogerenciados são aqueles que você recebe, provisiona e renove-se.
Quando você emite um certificado usando uma CA publicamente confiável, a CA publica informações sobre o domínio associado aos registros da Transparência dos certificados, são acessíveis ao público. 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ê usa o Certificate Authority Service para emitir seus certificado gerenciado pelo Google. O Gerenciador de certificados não publica nenhum. para os 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
Como gerenciar certificados TLS (SSL) gerenciados pelo Google para seus sites e aplicativos pode ser uma tarefa complexa e demorada que muitas vezes 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 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 RSA certificados 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 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 (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 ACs públicas aprovadas pelo Google. emitir seus certificados, você pode configurar o Gerenciador de certificados para usar um Pool de ACs do Certificate Authority Service como emissor do certificado. Para mais informações sobre pools de ACs, consulte Como criar pools de CA.
Certificados autogerenciados
Caso seus requisitos de negócios não permitam que você use serviços gerenciados pelo Google, , é possível fazer 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 implantações certificados autogerenciados Proxies e proxies Secure Web Proxy e regionais e balanceadores de carga de rede externos.
Mapas de certificados
Um mapa de certificado faz referência a uma ou mais entradas do mapa de certificado que atribuem certificados específicos para 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 de rede. É 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 carregamento de rede exibe 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 certificado
Uma entrada de mapa de certificado é uma lista de certificados exibidos para um determinado nome de domínio. 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 que você prove a propriedade de domínios para os quais emita certificados gerenciados pelo Google, conforme descrito nas tabela.
| Autorização do balanceador de carga | Autorização de DNS | |
|---|---|---|
| Complexidade da configuraçã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 do 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 que não sejam 443 e camadas CDN na frente do proxy de destino. |
| Velocidade de provisionamento | Só é possível provisionar certificados depois que o balanceador de carga é está totalmente configurada e veiculando tráfego de rede. | É possível provisionar certificados com antecedência antes que o proxy de destino seja 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 ao Gerenciador de certificados para usar um pool de ACs da sua própria instância do Certificate Authority Service emitir certificados gerenciados pelo Google em vez da CA do Google ou da CA do 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 o repositório de confiança, a âncora de confiança e o certificado intermediário entidades.
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 intermediário assinado por um certificado raiz ou intermediário referenciado na encapsulamento do repositório de confiança para uso na autenticação TLS mútua diferentes.
É 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ídas como parte da avaliação de confiança solicitação de conexão além da lista de certificados intermediários especificado na própria solicitação.
Certificados que exigem uma lista de permissões
Opcionalmente, se precisar usar um certificado que tenha sido autoassinado, você
expirou ou for inválido de outra forma, ou se você não tiver acesso à raiz e
e intermediários, é possível adicioná-los à 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 o certificado seja analisável, prova de chave privada posse é estabelecida, e as restrições no campo SAN do certificado sejam atendidos.
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. Nesta etapa, ele fornece ao balanceador de carga com 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 no nome do host fornecido pelo cliente e no mapa de certificado configurado de entradas de registro. Os fatores que determinam qual certificado é o certificado do 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 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 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 o seguinte:
- 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 não indicar suporte para certificados ECDSA, o balanceador de carga exibe 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 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 no
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 parawww.myorg.example.comsempre seleciona a entrada parawww.myorg.example.com, mesmo que uma uma entrada para*.myorg.example.comtambém existe. - Nomes de domínio curinga correspondem a apenas um nível de subdomínio. Para
exemplo, uma solicitação de conexão para
host1.myorg.example.comseleciona um certificado entrada no mapa 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). Vincule cada conta do ACME que está usando com o Gerenciador de certificados AC pública para o projeto de destino do Google Cloud usando vinculação de conta externa. Para isso, você deve registrar cada conta do ACME usando um secret vinculado ao projeto correspondente do Google Cloud. Para mais informações, consulte Conta externa vinculação.
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 no certificado. Você pode provar o controle do domínio solucionando 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 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
Public CA oferece suporte aos seguintes tipos de desafio:
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.
Desafio da negociação do protocolo de camada de aplicativo TLS (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 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 uma nome de domínio, o cliente só poderá solicitar o domínio validado a serem incluídos em um certificado. Se você usar o desafio de DNS, também pode 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 são cobertos automaticamente
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 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. O local depende do desafio.
- O cliente indica ao Public CA que preparou a desafio.
- O Public CA verifica se o token está presente no local 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ê só precisa resolver um desafio por nome de domínio.