É possível usar a Public Certificate Authority para provisionar e implantar certificados X.509 amplamente confiáveis depois de validar se o solicitante do certificado controla os domínios. A Public CA permite solicitar diretamente e de forma programática certificados TLS confiáveis publicamente que já estão na raiz de confiança dos repositórios de confiança usados pelos principais navegadores, sistemas operacionais e aplicativos. É possível usar esses certificados TLS para autenticar e criptografar o tráfego da Internet.
A Public CA permite gerenciar casos de uso de alto volume que outras ACs não conseguiram oferecer suporte. Se você for um Google Cloud cliente, poderá solicitar certificados TLS para seus domínios diretamente da Public CA.
A maioria dos problemas relacionados a certificados ocorre devido a erros ou supervisão humana. Por isso, recomendamos automatizar os ciclos de vida dos certificados. A Public CA usa o Automatic Certificate Management Environment (ACME) protocolo para o provisionamento, a renovação e a revogação automatizados de certificados. O gerenciamento automatizado de certificados reduz o tempo de inatividade que os certificados expirados podem causar e minimiza os custos operacionais.
A Public CA provisiona certificados TLS para vários Google Cloud serviços, como App Engine, Cloud Shell, Google Kubernetes Engine e Cloud Load Balancing.
Quem deve usar a Public CA
Você pode usar a Public CA pelos seguintes motivos:
- Se você estiver procurando um provedor de TLS com alta ubiquidade, escalonabilidade, segurança e confiabilidade.
- Se você quiser a maioria, se não todos, os certificados TLS para sua infraestrutura, incluindo cargas de trabalho locais e configurações de provedores de nuvem cruzada, de um único provedor de nuvem.
- Se você precisar de controle e flexibilidade sobre o gerenciamento de certificados TLS para personalizá-lo de acordo com os requisitos da sua infraestrutura.
- Se você quiser automatizar o gerenciamento de certificados TLS, mas não puder usar certificados gerenciados em Google Cloud serviços, como GKE ou Cloud Load Balancing.
Recomendamos que você use certificados confiáveis publicamente apenas quando os requisitos de negócios não permitirem outra opção. Considerando o custo histórico e a complexidade da manutenção de hierarquias de infraestrutura de chave pública (PKI), muitas empresas usam hierarquias de PKI públicas, mesmo quando uma hierarquia particular faz mais sentido.
A manutenção de hierarquias públicas e particulares se tornou muito mais simples com várias Google Cloud ofertas. Recomendamos que você escolha cuidadosamente o tipo certo de PKI para seu caso de uso.
Para requisitos de certificado não público, Google Cloud oferece duas soluções fáceis de gerenciar:
Anthos Service Mesh: Cloud Service Mesh inclui o provisionamento de certificados mTLS totalmente automatizado para cargas de trabalho em execução no GKE Enterprise usando a autoridade certificadora do Cloud Service Mesh (autoridade certificadora do Cloud Service Mesh).
Certificate Authority Service: Certificate Authority Service permite implantar, gerenciar e proteger ACs particulares personalizadas com eficiência sem gerenciar a infraestrutura.
Benefícios da Public CA
A Public CA oferece os seguintes benefícios:
Automação: como os navegadores da Internet visam o tráfego totalmente criptografado e a redução dos períodos de validade do certificado, há um risco de usar certificados TLS expirados. A expiração do certificado pode levar a erros no site e causar interrupções no serviço. A Public CA evita o problema de expiração do certificado, permitindo que você configure seu servidor HTTPS para obter e renovar automaticamente os certificados TLS necessários do nosso endpoint ACME.
Compliance: a Public CA passa por auditorias independentes regulares e rigorosas de controles de segurança, privacidade e compliance. Os selos Webtrust concedidos como resultado dessas auditorias anuais demonstram a conformidade do Public CA com todos os padrões relevantes do setor.
Segurança: a arquitetura e as operações da Public CA são projetadas para o mais alto nível de padrões de segurança e executam avaliações independentes regularmente para confirmar a segurança da infraestrutura subjacente. A Public CA atende ou excede todos os controles, práticas operacionais e medidas de segurança mencionados no artigo sobre segurança do Google.
O foco do Public CA na segurança se estende a recursos como a validação de domínio com várias perspectivas. A infraestrutura do Public CA é distribuída globalmente. Portanto, a Public CA exige um alto grau de concordância em perspectivas geograficamente diversas, o que oferece proteção contra ataques de sequestro de Border Gateway Protocol (BGP) e de servidor de nome de domínio (DNS).
Confiabilidade: o uso da infraestrutura técnica comprovada do Google torna a Public CA um serviço altamente disponível e escalonável.
Ubiquidade: a forte ubiquidade do navegador do Google Trust Services ajuda a garantir que os serviços que usam certificados emitidos pela Public CA funcionem na maior variedade possível de dispositivos e sistemas operacionais.
Soluções de TLS simplificadas para configurações híbridas: o Public CA permite criar uma solução de certificado TLS personalizada que usa o mesmo CA para diversos cenários e casos de uso. O Public CA atende com eficiência aos casos de uso em que as cargas de trabalho são executadas no local ou em um ambiente de provedor de nuvem cruzada.
Escala: os certificados costumam ser caros para serem obtidos e difíceis de provisionar e manter. Ao oferecer acesso a grandes volumes de certificados, a Public CA permite que você utilize e gerencie certificados de maneiras que antes eram consideradas impraticáveis.
Usar a Public CA com o Certificate Manager
Para usar o recurso de Public CA do Certificate Manager, é necessário 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. O cliente ACME precisa oferecer suporte à vinculação de contas externas (EAB) para trabalhar com a Public CA.
Vinculação de contas externas (EAB). É necessário vincular cada conta ACME que você está usando com o Public CA do Certificate Manager ao projeto Google Cloud de destino usando a vinculação de contas externas. Para fazer isso, registre cada conta ACME usando um secret vinculado ao projeto Google Cloud correspondente. Para mais informações, consulte Vinculação de contas externas.
Desafios da Public CA
Ao usar a Public CA para solicitar um certificado, o Certificate Manager pede que você comprove o controle sobre os domínios listados nesse certificado. É possível comprovar o controle do domínio resolvendo desafios. A Public CA autoriza os nomes de domínio depois que você comprova o controle dos 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, é 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 Public CA 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 Public CA recupere e verifique. Para mais informações, consulte Desafio HTTP.
Desafio de negociação de protocolo da camada de aplicativo TLS (ALPN). Exige 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. 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 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 o desafio de DNS, o cliente também poderá solicitar que os 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 não DNS.
Lógica de solução de desafios
A lógica de desafio da Public CA é a seguinte:
- A 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 à Public CA que preparou o desafio.
- A Public CA verifica se o token presente no local esperado corresponde ao valor esperado.
O nome de domínio é autorizado após a conclusão desse processo. O cliente pode solicitar um certificado com esse nome de domínio. É necessário resolver apenas um desafio por nome de domínio.