Três condições decidem como um site só por VPN deve obter o seu certificado: se controla uma zona DNS pública, se o nome do host pode aparecer em registos públicos e se a cada cliente pode ser dada uma âncora de confiança privada. A via pública e a privada produzem ambas um cadeado funcional e respondem a perguntas diferentes. Escolher uma sem resolver estas condições é como um site acaba com um certificado público que não queria, ou com um interno que metade dos clientes rejeita.

O certificado prova o nome; a VPN e o DNS interno fornecem o caminho.

Dois caminhos para um nome de confiança

Um emitente público com validação DNS-01 prova o controlo de um nome através de um registo TXT numa zona que controla, pelo que o serviço web nunca tem de aceitar uma ligação HTTP pública. Uma CA privada emite certificados folha para nomes internos e distribui a sua âncora de confiança através da gestão de dispositivos, pelo que nenhum registo público fica a conhecer o nome. Ambas são legítimas, e a escolha decorre dessas três condições e não da conveniência. Nenhum dos caminhos fornece a rota ou a entrada de resolução de que um cliente precisa.

Um certificado público também publica o nome do host nos registos de transparência de certificados. Se o nome em si for sensível, essa divulgação é uma decisão de conceção e não um efeito secundário descoberto mais tarde.

DNS-01 sem expor o serviço

O registo de desafio é uma entrada TXT sob um prefixo reservado na zona, e o emitente lê-o do DNS autoritativo. Escolha um cliente ACME e uma integração DNS que possam criar e remover esse registo, e autorize a atualização de forma estreita: uma credencial API de âmbito limitado para a zona, ou um host controlado usado apenas para validação. Dar ao servidor de aplicações uma credencial de registrador sem restrições para renovar um único certificado é muito mais autoridade do que a tarefa exige. Quando várias encomendas partilham um nome, mantenha os seus valores TXT separados para que a limpeza de uma não remova um valor de que outra ainda precisa.

Aguarde a propagação com uma verificação contra os servidores autoritativos em vez de uma espera fixa. O comportamento de propagação depende do fornecedor, e uma espera que funciona hoje não é prova sobre amanhã.

Clientes geridos e nomes deliberadamente privados

Os dispositivos geridos e os nomes deliberadamente privados encaixam bem numa CA interna. Distribua o emitente de confiança através da gestão de dispositivos e depois emita certificados folha para os nomes previstos. Verifique que armazém cada cliente usa realmente, porque uma única importação no sistema operativo não é uma afirmação universal sobre todos os navegadores e aplicações. A fixação da folha é outra opção onde é explicitamente suportada, com o custo de mais uma atualização de confiança sempre que a folha muda.

O canal de distribuição importa tanto como a chave: uma raiz que ninguém instala não protege nada.

A renovação faz parte da conceção

Seja qual for o caminho escolhido, a renovação exige um responsável e um procedimento. Atualizar a prova de validação, instalar o novo material e recarregar o ouvinte através do seu mecanismo suportado são três passos distintos, e só o primeiro é automatizado pela maioria dos clientes ACME. Um certificado que se renova corretamente mas nunca é carregado produz a mesma interrupção que um caducado.

O certificado não instala a rota VPN nem cria o registo DNS interno. Os clientes continuam a precisar de um resolver que associe o nome ao endereço privado e de uma rota para lá chegar. Teste o site pelo nome a partir de um cliente que tenha ambos.

Registe o emitente, o método de validação, o canal de distribuição de confiança e o mecanismo de recarregamento. Esses quatro são o plano de renovação.

Artigos relacionados