Let’s Encrypt ACME: automatizar certificados e gerir as renovações de forma segura

Processo ACME e funções de chave separadas

O ACME padroniza a comunicação entre um cliente e a entidade certificadora, não todo o ambiente operacional. O cliente começa por utilizar uma conta ACME e, em seguida, cria um pedido para um ou mais nomes de domínio. Para cada identificador, o servidor solicita uma autorização. Só quando esta for bem-sucedida é que o cliente pode finalizar o pedido com um pedido de assinatura de certificado (Certificate Signing Request, ou CSR) e obter o certificado emitido.

1. Crie uma chave de conta ou utilize uma conta ACME já existente e crie a ordem.
2. Para cada identificador solicitado, fornecer o desafio especificado e aguardar a autorização.
3. Gerar um par de chaves separado para o certificado, criar a CSR a partir desse par e finalizar a encomenda. A chave pública na CSR não pode coincidir com a chave da conta que autentica o pedido de finalização.
4. Recuperar o certificado e a cadeia de certificados, guardá-los de forma segura e distribuí-los aos pontos finais TLS previstos.

O Chave de conta ACME autentica o cliente para a conta junto do servidor ACME e assina as mensagens do protocolo. A chave privada utilizada na CSR, por outro lado, pertence à identidade TLS posterior. A RFC 8555 exige duas classes de chaves distintas: a chave pública da CSR não pode corresponder a uma chave de conta conhecida e, em particular, não pode ser idêntica à chave de conta que autentica a ordem de finalização. O cliente e o servidor têm de verificar esta separação.

No caso do DNS-01, acrescenta-se um terceiro componente sensível: a autorização para a API do DNS. A Let’s Encrypt salienta que a existência de credenciais completas de acesso à API do DNS num servidor web aumenta significativamente as consequências de um ataque. Como medida de segurança operacional, o token deve, por isso, poder alterar apenas os registos de desafio necessários; em alternativa, a validação do DNS pode ser realizada num sistema separado.

As chaves de conta, as chaves de certificado e o acesso ao DNS constituem domínios de confiança distintos. A utilização de pares de chaves diferentes para a conta e para o certificado é um requisito do protocolo; o seu armazenamento separado, direitos de acesso estritamente limitados e processos de rotação independentes são, além disso, medidas operacionais importantes. Desta forma, um token DNS comprometido não implica necessariamente acesso à chave privada do certificado nem à conta ACME.

A automatização não elimina os pré-requisitos incorretos. Uma porta inacessível, um encaminhamento incorreto, uma delegação de DNS inadequada ou direitos de acesso demasiado amplos continuam a ser problemas operacionais, mesmo que a criação de ordens seja automatizada. O ACME acelera o processo repetível; os operadores devem implementar de forma fiável no seu ambiente um conceito de direitos, a separação obrigatória entre as chaves da conta e do certificado, o armazenamento seguro, bem como o controlo dos certificados efetivamente emitidos.

O desafio certo para a infraestrutura

O Challenge determina a forma como uma entidade certificadora verifica o controlo sobre um identificador. Por isso, deve ser derivado do caminho de rede, da gestão do DNS e da terminação TLS, e não de uma preferência genérica por uma ferramenta de cliente. Os padrões HTTP-01, DNS-01 e TLS-ALPN-01 estabelecem diferentes tipos de controlo e, consequentemente, impõem requisitos distintos em termos de infraestrutura e autorizações.

No caso de um único site acessível ao público, é HTTP-01 geralmente o caminho mais direto. O cliente disponibiliza um recurso em /.well-known/acme-challenge/ pronto, que acede ao Let’s Encrypt através da porta 80. Se um domínio apontar para vários destinos A ou AAAA, este recurso tem de estar acessível em todos os sistemas que possam ser alvo da solicitação de validação. Caso contrário, ocorre um erro de validação que surge apenas ocasionalmente.

Certificados curinga para *.example.org por outro lado, exigem obrigatoriamente DNS-01. Para tal, o cliente publica um registo TXT em _acme-challenge.example.org. Isto é adequado para muitos subdomínios dinâmicos, servidores web distribuídos ou um equilibrador de carga, uma vez que nenhuma instância HTTP específica tem de fornecer o ficheiro de validação. No entanto, é necessário que a alteração do DNS seja fiável e possa ser automatizada.

Um proxy reverso sem a porta 80 disponível pode TLS-ALPN-01 utilizar, desde que controle a terminação TLS na porta 443 e que o cliente utilizado suporte este desafio. A validação é efetuada através de uma ligação TLS específica, e não através de um ficheiro Web normal. Este procedimento é, por isso, particularmente adequado para infraestruturas especializadas de proxy ou de alojamento, mas não como substituto geral do HTTP-01. Também neste caso, os caracteres curinga não são suportados.

Nenhum método é, de um modo geral, superior: o HTTP-01 reduz o acesso ao DNS num site simples; o DNS-01 permite a utilização de curingas e dissocia a validação do caminho web; o TLS-ALPN-01 recorre de forma específica aos controlos TLS existentes. O essencial é que o desafio escolhido funcione em percursos reais de failover, IPv4 e IPv6 e que as suas autorizações se adequem ao respetivo modelo operacional.

ARI, perfis e prazos mais curtos

Com Informações sobre a renovação da ACME (ARI), a lógica de renovação passa de uma data-limite definida localmente para um intervalo de tempo recomendado pelo servidor ACME. O cliente solicita esta informação para um certificado existente e seleciona um momento aleatório dentro desse intervalo. Desta forma, as renovações podem ser distribuídas ao longo do tempo e, em caso de eventos especiais, antecipadas de forma específica.

O ARI é uma extensão padronizada, mas não é uma funcionalidade automática de todos os clientes ou painéis de alojamento instalados. O Let’s Encrypt pode disponibilizar novas funcionalidades ACME retrocompatíveis no ponto de extremidade existente; o facto de uma instalação específica as utilizar depende da sua versão e implementação. Por isso, no caso de grandes parques de servidores, é necessário verificar se o cliente consulta o ARI, respeita o intervalo de tempo e não sincroniza novamente as renovações.

Além disso, o Let’s Encrypt atribui perfis de certificado aos pedidos. Se não for selecionado explicitamente um perfil, o perfil clássico é o padrão e tem, atualmente, uma validade de 90 dias. O perfil tlsserver tem uma validade de 45 dias, prazos mais curtos para autorizações e ordens em aberto, bem como um máximo de 25 nomes DNS. shortlived também utiliza prazos de validade curtos para os objetos, tem uma validade de cerca de 160 horas e suporta identificadores DNS e IP.

A seleção do perfil também pressupõe o suporte do cliente; não deve ser deduzida apenas a partir da documentação do servidor. Para além do período de validade e dos identificadores, os perfis diferem também noutras características. Por conseguinte, as aplicações e as ferramentas de inventário não devem pressupor tacitamente nem um procedimento uniforme nem a existência de um «Common Name» em todos os certificados.

Em termos matemáticos, a relação entre 90 dias e cerca de 160 horas corresponde a um fator de aproximadamente 13,5 no prazo de execução. Daí não decorre qualquer carga mensurável, mas sim uma consequência clara em termos de planeamento: qualquer perturbação na encomenda, distribuição ou recarga será, em certificados de curta duração muito mais cedo. Só fazem sentido para sistemas cuja cadeia de abastecimento completa seja monitorizada e cuja renovação não dependa de intervenções manuais. No caso das renovações coordenadas pela ARI, aplicam-se regras especiais relativas aos limites de consultas no Let’s Encrypt, sob condições documentadas.

Matriz de desafios e delegação segura de DNS

A escolha do desafio depende da infraestrutura disponível, e não de uma classificação geral. O HTTP-01 exige uma resposta acessível publicamente através da porta 80, o DNS-01 uma entrada TXT controlável e o TLS-ALPN-01 o controlo sobre a terminação TLS na porta 443. Os nomes com caracteres curinga só podem ser validados com o DNS-01.

Um site com um único servidor web fica, por isso, frequentemente bem servido com o HTTP-01. No entanto, se os registos DNS A ou AAAA apontarem para vários sistemas, cada destino efetivamente alcançado tem de fornecer o recurso esperado. Caso contrário, o resultado depende do ponto final que a validação alcançar. Um equilibrador de carga ou um repositório de desafios sincronizado centralmente só elimina este problema se abranger todos os caminhos.

Para o DNS-01, deve ser utilizado como Autorização mínima procurar garantir que o cliente ACME só possa alterar as entradas de desafio necessárias. A restrição que é efetivamente possível depende da API e do modelo de autorização do fornecedor de DNS; nem todos os serviços permitem direitos sobre um único nome TXT. Caso subsista apenas um acesso de âmbito alargado, a validação deve ser transferida para um sistema separado ou deve ser delegada uma zona de «Challenge» específica. Os dados de acesso devem ser armazenados num repositório protegido, separadamente das chaves de certificado e das chaves da conta ACME.

No caso de zonas de grande dimensão, uma zona de desafio separada pode restringir ainda mais os direitos. A delegação de _acme-challenge Através de CNAME ou NS, os dados de validação são transferidos para uma área de gestão própria. O cliente passa então a ter direitos de alteração apenas nessa área. Antes da utilização em produção, é necessário verificar o conteúdo do registo TXT e a resolução DNS: uma resposta correta da API não é suficiente se os resolvers ainda não detetarem a delegação ou o registo.

Automatizar de forma fiável a atualização e a distribuição

Resistente Gestão de Certificados não termina com a obtenção de um certificado. Num ambiente distribuído, um worker ACME central inicia a validação e armazena o certificado e a chave privada de forma segura. Só depois é que os artefactos são distribuídos pelos pontos finais TLS, onde são verificados e ativados de forma controlada. A chave do certificado utilizada na CSR deve ser diferente da chave da conta ACME de autenticação; a forma como ambas as chaves são posteriormente armazenadas separadamente, autorizadas e submetidas a rotação deve ser definida no conceito operacional.

A tabela seguinte descreve um conceito operacional recomendado para a cadeia de abastecimento. A RFC 8555 exige que a chave pública da CSR não corresponda a nenhuma chave de conta conhecida e, em particular, que não coincida com a chave de conta utilizada para autenticar a ordem de finalização. A separação organizacional concreta entre armazenamento, direitos de acesso e rotação baseia-se neste requisito do protocolo. O «Deploy Hook» do Certbot destina-se a ações após a emissão bem-sucedida. A segurança da transmissão, a verificação do destino e a verificação TLS externa devem ser adequadas à respetiva infraestrutura.

No que diz respeito a alterações nas integrações de painéis ou DNS, a cadeia produtiva não deve ser considerada como um sistema isolado. Em particular, no caso de uma gestão através de Atualizações do Plesk para fornecedores de alojamento web As funcionalidades disponíveis dependem do Panelstand, das extensões e dos serviços associados. A capacidade concreta do cliente ACME, por exemplo, no que diz respeito a extensões de protocolo adicionais, também depende da versão e deve ser verificada na combinação utilizada.

No Certbot, um «deploy hook» pode acionar o último passo, uma vez que só é executado após uma renovação bem-sucedida. O modelo seguinte pressupõe que o caminho local é um script executável e verificado, sem dados de acesso. O script deve idempotente trabalhar, registar erros e recarregar apenas os serviços que utilizam o certificado atualizado.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

O código de saída de certbot renew não constitui prova de um novo certificado: mesmo que não houvesse nada para renovar, o comando pode terminar com o estado 0. Por conseguinte, o sistema de monitorização deve determinar de forma independente qual o certificado que o ponto final público efetivamente fornece, quando expira e se a recarga foi bem-sucedida.

CAA, perfis e certificados para endereços IP

Um registo CAA é um Corrimão de exposição: Determina quais as entidades certificadoras autorizadas a emitir certificados para um domínio. Além disso, a diretiva pode definir o método de validação permitido e, através do parâmetro accounturi definir a conta ACME prevista. A chave de conta atual autentica o acesso a esta conta, mas pode ser alterada através do processo de alteração da chave ACME. A vinculação da conta não substitui, portanto, nem a proteção da chave de conta atual nem um conceito abrangente de autorizações.

A seguinte linha de registo permite que o Let’s Encrypt seja utilizado para o domínio apenas com a validação DNS-01. Esta opção só é adequada se a validação DNS-01 estiver configurada de forma automatizada e se a zona de desafio for gerida de forma fiável. Quem pretender utilizar posteriormente o HTTP-01 para um único site ou o TLS-ALPN-01 para um proxy reverso, bloqueia deliberadamente esta emissão com a restrição apresentada.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

A linha individual não descreve necessariamente a totalidade da Política da CAA da zona. Vários registos do mesmo tipo têm um efeito cumulativo: se um deles permitir a emissão, essa autorização mantém-se mesmo que outros registos tenham restrições mais rigorosas. No caso dos certificados curinga, é ainda necessário verificar se issuewild-existem registos. Na ausência desses registos, aplica-se issue também para caracteres curinga; existentes issuewild- Por outro lado, as entradas controlam a emissão de caracteres curinga de forma separada. Por isso, o que prevalece é sempre o conjunto completo e válido de registos associados ao nome verificado.

Os certificados para endereços IP públicos são um caso diferente dos certificados de domínio. O Let’s Encrypt suporta identificadores IP no perfil shortlived; como métodos de validação, podem ser considerados o HTTP-01 e o TLS-ALPN-01. O DNS-01 não consegue validar um endereço IP. A curta validade de cerca de 160 horas pressupõe, por isso, uma renovação, distribuição e controlo de entrega automatizados e contínuos.

O perfil «shortlived» é, portanto, adequado para interfaces acessíveis diretamente por IP apenas se cada etapa funcionar sem intervenções manuais. Não se trata de uma variante simplificada para sistemas que são mantidos ocasionalmente. Além disso, o cliente ACME utilizado e o ambiente de destino têm de suportar a escolha do perfil, bem como o «challenge» selecionado; a disponibilidade no serviço ACME não garante o suporte por parte de todas as versões do cliente.

Monitorização e resolução de problemas, em primeiro lugar no ambiente de teste

A resolução de problemas no ACME começa com o procedimento de validação efetivamente utilizado, e não com um novo pedido de certificado. Para alterações no cliente, no encaminhamento, na firewall ou no DNS, recomenda-se utilizar o ponto de extremidade de teste separado da Let’s Encrypt. O ambiente de teste tem limites próprios, significativamente mais elevados, mas não é ilimitado; os certificados de teste emitidos nesse ambiente não são publicamente confiáveis. Embora novas funcionalidades de protocolo possam estar disponíveis no ponto de extremidade ACME, a compatibilidade do cliente instalado deve, ainda assim, ser verificada separadamente.

No caso do HTTP-01, deve verificar-se, em primeiro lugar, se o domínio em questão está acessível publicamente através da porta 80 e se o ficheiro solicitado se encontra em /.well-known/acme-challenge/ no sistema de destino. A presença de vários registos A ou AAAA torna o teste mais complexo: cada ponto final efetivamente acessível tem de disponibilizar o ficheiro de desafio correspondente. As causas mais comuns são um encaminhamento de host virtual incorreto, um proxy a montante, uma regra de firewall ou contentores não sincronizados.

O TLS-ALPN-01, por outro lado, exige controlo sobre a terminação TLS na porta 443. Em caso de erro, deve verificar-se qual o balanceador de carga ou proxy que aceita a ligação, se este fornece o certificado necessário para o desafio e se um serviço TLS regular se sobrepõe ao processo. O facto de um ficheiro de certificado local ter sido gerado com sucesso não prova que o ponto final acedido publicamente o esteja a utilizar.

No DNS-01, o nome e o conteúdo do registo TXT encontram-se em _acme-challenge verificar separadamente. O registo deve estar publicado na zona delegada ou na zona de referência; além disso, a cadeia de delegação deve estar correta, caso seja utilizada uma zona de desafio separada. As tentativas repetidas que falham devido a erros de digitação, alterações ainda não visíveis ou delegação incorreta devem ser analisadas, em primeiro lugar, no ambiente de teste.

Eficaz Monitorização Não se limita a monitorizar a data de validade no repositório do ACME-Worker. Verifica de forma independente o nome de host fornecido, o prazo de validade restante do certificado aí apresentado e o sucesso da recarga após uma atualização. Deve também ser emitida uma alerta se uma renovação falhar ou se um terminal continuar a fornecer o certificado antigo, apesar da emissão ter sido bem-sucedida. No que diz respeito a alterações planeadas nos servidores de alojamento, o artigo complementa Planear as atualizações do cPanel e do WHM de forma segura o planeamento operacional necessário.

Limites de cota e renovações na carteira

Numa carteira de certificados, os limites de cota são uma condição de conceção da Automatização SSL. As renovações forçadas diariamente ou as tarefas iniciadas em simultâneo geram pedidos desnecessários e podem acionar limites. Isto aplica-se especialmente quando uma falha na infraestrutura afeta muitos domínios ao mesmo tempo: as repetições não resolvem a falta de ficheiros de desafio nem o DNS incorreto, mas aumentam o número de validações falhadas. Por isso, as falhas têm de ser isoladas antes da próxima execução em produção.

Informações sobre a renovação da ACME, em resumo ARI, substitui os limites locais rígidos por uma janela de renovação recomendada pelo servidor ACME para um certificado existente. O cliente compatível com ARI consulta as informações de renovação e seleciona um momento aleatório dentro dessa janela. Um agendador pode iniciar o cliente regularmente, mas não avalia ele próprio o ARI. O cliente deve considerar a janela recomendada e Retry-After ter em conta e, em caso de erros, respeitar os intervalos adequados de recuo e repetição. Por conseguinte, a execução mais frequente do agendador não deve conduzir a repetições descontroladas de tarefas que falharam.

No caso do Let’s Encrypt, as renovações coordenadas pelo ARI podem estar isentas dos limites de taxa, de acordo com os requisitos documentados. O novo pedido deve incluir, entre outros dados, pelo menos um identificador do certificado a substituir, e este não pode já ter sido substituído através do ARI. Isto não constitui uma autorização geral para quaisquer novos pedidos: as alterações ao âmbito do certificado devem ser tratadas separadamente, tanto do ponto de vista técnico como operacional.

Em particular, uma lista SAN reduzida ou alterada não implica automaticamente a renovação do certificado anterior. Um pedido que inclua apenas uma parte dos nomes anteriores pode gerar um certificado separado, enquanto o antigo continua a ser válido. Por isso, o inventário deve incluir o identificador do certificado, a lista completa de identificadores, os pontos finais associados e o processo de renovação. Antes de uma alteração planeada na SAN, é necessário decidir quais os serviços a serem atualizados e quando os certificados que já não são necessários devem ser removidos.

Quando existem vários trabalhadores, a atribuição clara de responsabilidades evita a duplicação de ordens para o mesmo stock. É aconselhável utilizar um programador central ou um bloqueio coordenado, registos rastreáveis e repetições escalonadas após uma falha. A seleção aleatória dentro de uma janela ARI não substitui este controlo, mas reduz sobretudo a simultaneidade das renovações regulares.

Escolher o modelo operacional adequado em função do risco

Para um único site acessível ao público, o HTTP-01 é, na maioria das vezes, o modelo de funcionamento mais simples. O servidor web tem de servir a porta 80 de forma fiável e disponibilizar o ficheiro de desafio no caminho esperado. Este modelo não é compatível com curingas e torna-se frágil quando vários destinos independentes respondem ao mesmo domínio. Por isso, faz sentido sobretudo quando o encaminhamento web, o armazenamento de certificados e a entrega de TLS se concentram num ponto claramente controlado.

O DNS-01 é o modelo adequado para curingas, subdomínios dinâmicos e pontos finais TLS distribuídos. O requisito não é apenas a possibilidade de acesso ao DNS, mas sim a alteração, de forma segura e automatizável, do registo TXT necessário. Um token com o âmbito mais restrito possível ou uma zona de desafio delegada reduz as consequências de um sistema comprometido. A granularidade que é possível alcançar depende da API do DNS. As delegações devem ser documentadas como dependências operacionais, monitorizadas e dotadas de um procedimento de recuperação.

O TLS-ALPN-01 é adequado para operadores que pretendem controlar de forma específica a terminação TLS na porta 443, por exemplo, num proxy reverso ou num balanceador de carga. Este método não constitui um substituto genérico do HTTP-01 nem suporta caracteres curinga. A sua aplicabilidade prática depende ainda da implementação específica do cliente e do proxy. Por isso, antes da sua utilização, é necessário verificar se o software é capaz de gerar o desafio, transmiti-lo e, após a conclusão, removê-lo corretamente.

O Perfil do shortlived é adequado apenas para sistemas com automatização completa de ponta a ponta. A Let’s Encrypt indica, para este caso, um período de validade de cerca de 160 horas, bem como identificadores DNS e IP; em comparação com o perfil padrão de 90 dias, isto aumenta significativamente, em termos matemáticos, a frequência de renovação necessária. Todo o processo, desde a encomenda até à distribuição, recarga e verificação externa, tem, por isso, de funcionar de forma fiável. A escolha de um perfil pressupõe, além disso, que o cliente ACME utilizado suporte efetivamente a seleção desse perfil.

Independentemente do modelo, é necessário um serviço profissional Gestão de Certificados um inventário completo, chaves geridas de forma segura e acessos ao DNS com autorizações mínimas. A chave da conta autentica o cliente para a conta ACME; a chave privada utilizada na CSR pertence à identidade TLS. A RFC 8555 proíbe a utilização da chave pública da conta num certificado: em particular, a chave na CSR não pode coincidir com a chave da conta que autentica a ordem de finalização. O armazenamento separado, a atribuição de autorizações e a rotação destas classes de chaves, bem como os acessos revogáveis e um mecanismo de retorno testado para o certificado anterior, fazem parte do conceito de direitos e de emergência.

Uma execução bem-sucedida do ACME não deve ser o único critério de sucesso. O controlo de entrega deve determinar, fora do worker, qual o certificado que um ponto final TLS genuíno apresenta. Para as etapas de distribuição e recarga, são adequadas ações que só sejam acionadas após uma renovação bem-sucedida; no Certbot, existe um «Deploy Hook» previsto para esse efeito. O seu script deve ser idempotente, registar erros e apenas recarregar os serviços que utilizam efetivamente o material renovado.