Renovação dos certificados SSL/TLS: automação, casos rebeldes e limiar de compra

⚡TL;DR

• As renovações não consomem a quota da Let's Encrypt de 50 certificados por domínio registado. Este limite mede a entrada de novos nomes, não a dimensão de um parque. Acreditar no contrário distorce todo o dimensionamento.
• O que quebra uma renovação de certificado SSL quase nunca é o ACME, mas sim os endpoints que nenhum script recarrega: appliances com interface web, keystores com palavra-passe interativa, terminações TLS geridas sem API.
• Um inventário faz-se por par (host, porta), não por nome de host. No mesmo endereço IP, ldap.google.com devolve a um cliente com a configuração por defeito dois números de série diferentes nas portas 389 e 636, e um scanner que se esquece do SNI regista um terceiro número de série, estável e falso.
• O ACME, o ARI e as seis fases do ciclo de vida são aqui dados como conhecidos: são tratados no guia de gestão do ciclo de vida dos certificados.

A renovação de um certificado SSL raramente falha onde se espera. O modo de falha mais comum não é um erro de emissão bem visível num log: é um certbot renew que corre a verde durante semanas enquanto o serviço continua a apresentar o certificado antigo. Duas linhas de openssl detetam-no: o número de série lido no disco contra o que é realmente servido na porta. Nada nos logs do cliente ACME o fará por si. As saídas reais estão mais abaixo.

O contexto endurece a mecânica. A 21 de julho de 2026, um certificado TLS público não pode ultrapassar 200 dias de validade, e o mesmo limite aplica-se à reutilização da validação de controlo do domínio. Os patamares seguintes chegam em março de 2027 e depois em março de 2029, e o segundo separa validade e revalidação. O porquê deste calendário é tratado no nosso artigo sobre a redução para 47 dias. Aqui, falamos do como: o que quebra concretamente quando a frequência aumenta, e o que se faz para o evitar.

Este playbook destina-se às equipas que gerem entre 50 e 1.000 certificados num parque heterogéneo, sem uma equipa de PKI dedicada. Vai encontrar comandos executados e as respetivas saídas reais, as armadilhas que os acompanham e os pontos em que não conseguimos medir nada, assumidos como tal. Nenhuma comparação de fornecedores. Um único critério de compra, quantificado, e não tem a ver com o número de certificados.

Expiração dos certificados SSL em 2026: o patamar em vigor e o que muda para os seus scripts

A 21 de julho de 2026, o patamar aplicável é o que entrou em vigor a 15 de março de 2026. Resume-se a três tetos: 200 dias de validade máxima, 200 dias de reutilização da validação de controlo do domínio (DCV) e 398 dias de reutilização das informações de identidade do subscritor (SII). É o teto rígido dos Baseline Requirements do CA/Browser Forum.

Na prática, as autoridades de certificação emitem abaixo desse valor. O texto recomenda não ultrapassar 199 dias e só proíbe acima de 200, pelo que toda a gente fica com a margem operacional. A DigiCert deixou de aceitar pedidos de certificados TLS públicos com validade superior a 199 dias a 24 de fevereiro de 2026, cerca de três semanas antes do prazo. A Sectigo seguiu-a a 12 de março de 2026: 199 dias de validade para qualquer certificado TLS emitido ou reemitido, 198 dias de reutilização da DCV.

O que vem a seguir já tem data. A 15 de março de 2027, a validade máxima e a reutilização da DCV passam ambas para 100 dias. A 15 de março de 2029, a validade desce para 47 dias e a reutilização da DCV para 10 dias. Já o SII fica fixado em 398 dias em todo o calendário: o seu único degrau é o de 15 de março de 2026.

Atenção ao atalho mais difundido: em 2029, quem desce para 10 dias é a reutilização da prova de controlo do domínio, não a validade. Os dois contadores separam-se, e é precisamente aí que tudo muda para os seus scripts. Hoje, uma validação bem-sucedida cobre várias renovações consecutivas. Em 2029, cada reemissão trará consigo uma revalidação completa, porque a prova anterior terá expirado há muito. Automatizar a emissão já não chega. A validação terá de estar automatizada em permanência, ou seja, as permissões de escrita no DNS ou o acesso à porta 80 terão de estar sempre disponíveis, e não apenas no dia em que alguém planeia uma alteração.

Inventariar um parque de certificados: quatro fontes, quatro pontos cegos

Nenhuma fonte de inventário vê o parque inteiro. Os logs de transparência listam o que foi emitido publicamente, o disco e os repositórios listam o que está instalado, o varrimento de rede lê o que é servido, e as API dos fornecedores cobrem o que as outras três não veem. É preciso cruzá-las e, sobretudo, saber o que cada uma deixa escapar.

Os logs de transparência mostram o que foi emitido, não o que está em funcionamento

Os logs de Certificate Transparency registam qualquer certificado emitido por uma autoridade pública para os seus domínios. Não dizem onde está instalado nem se ainda está em serviço. A consulta ingénua cabe numa linha:

curl -s 'https://crt.sh/?q=%25.captaindns.com&output=json' | jq -r '.[].name_value' | sort -u

No nosso domínio, devolveu 12 valores únicos em 54 segundos. Uma execução anterior tinha devolvido três HTTP 502 consecutivos antes de ser bem-sucedida à quarta tentativa. O comando não tem nada de errado: o crt.sh responde assim.

O que se segue foi encontrado na execução, não deduzido. O -s esconde a falha: o jq recebe HTML e devolve jq: parse error: Invalid numeric literal at line 1, column 7, e sem set -o pipefail o script continua como se nada fosse. Os 54 segundos são um tempo de resposta nominal para 142 certificados, não uma limitação de taxa. O %25 codifica o wildcard %, que cobre os subdomínios mas não o apex. O campo name_value contém quebras de linha quando o certificado tem vários SAN: 142 objetos JSON produziram 158 linhas para 12 valores únicos, o que torna o sort -u obrigatório. Por fim, os certificados expirados vêm incluídos por defeito: 76 das 142 entradas.

A versão reforçada corrige tudo isto:

curl -sS --fail --retry 8 --retry-all-errors --retry-delay 5 --max-time 180 \
  -o crt.json 'https://crt.sh/?q=%25.captaindns.com&output=json&exclude=expired' \
&& jq -r '.[].name_value' crt.json | sed 's/^\*\.//' | tr 'A-Z' 'a-z' | sort -u

Saída real: código 0 em 41,9 segundos, novas tentativas incluídas, 66 entradas contra 142 sem o filtro do servidor, e 11 nomes. Foram testadas e rejeitadas duas variantes, e são elas que mais ensinam. Sem -o, com a saída no stdout, o curl concatena o corpo do 502 com o do 200 bem-sucedido: 8.342 bytes que começam por <html><head><title>502 Bad Gateway</title> seguidos do JSON válido, e o jq falha. Com -o, o curl rebobina o ficheiro a cada tentativa. E --fail --retry 8 sem --retry-all-errors não volta a tentar: o curl 8.7.1 devolve curl: (56), um código que não consta da lista de erros que o curl repete por defeito. Falha em 0,12 segundos.

Resta o ponto cego estrutural: a transparência só vê a PKI pública. Os seus certificados internos não aparecem lá.

O disco e os repositórios mostram o que está instalado, não o que é servido

Ler um ficheiro PEM, um keystore Java ou o repositório de certificados da máquina no Windows diz o que está instalado na máquina. Não diz o que o serviço apresenta à rede.

Para o PEM, basta openssl x509 -in fullchain.pem -noout -subject -dates -serial. Para os outros dois, honestidade em primeiro lugar: não conseguimos executar os comandos correspondentes. A nossa máquina de teste não tem JDK e não corre Windows. Em vez de uma saída inventada, aqui fica o registo da tentativa:

$ keytool -list -v -keystore /Library/Keychains/System.keychain
The operation couldn't be completed. Unable to locate a Java Runtime.

$ file /usr/bin/keytool
/usr/bin/keytool: Mach-O universal binary with 2 architectures

$ pwsh -NoProfile -Command 'Get-ChildItem Cert:\LocalMachine\My'
Get-ChildItem: Cannot find drive. A drive with the name 'Cert' does not exist.

Estas duas falhas desmontam, cada uma, um falso positivo de disponibilidade. A máquina expõe de facto um binário /usr/bin/keytool, mas é um binário substituto da Apple que redireciona para o site do Java: um which keytool que responde não prova nada no macOS. E instalar o PowerShell 7 no macOS ou no Linux não dá acesso nenhum ao repositório de certificados, porque o fornecedor Certificate é um componente do Windows que não consta da lista de PSProvider. Este script só se valida no sistema de destino.

As armadilhas contam tanto como os comandos. O keytool pede a palavra-passe de forma interativa, e passá-la com -storepass expõe-na no histórico e no ps: prefira -storepass:file. Desde o JDK 9, o formato por defeito é PKCS12, e não JKS. No Windows, LocalMachine\My exige uma consola aberta em modo de administrador; caso contrário, a lista volta truncada sem mensagem de erro, e um binding do IIS pode apontar para uma impressão digital diferente da que está instalada.

O varrimento de rede nunca verá os seus servidores de correio

Um varrimento de rede lê o que é realmente servido, o que faz dele a fonte mais fiável. A partir de um posto comum ou da maioria das clouds, nunca verá os seus servidores de correio: a porta 25 de saída está filtrada.

A prova cabe em três linhas, num único host. smtp.gmail.com resolvia, no momento do teste, para um único endereço, e os front-ends da Google alternam entre si: seja qual for o endereço devolvido pela resolução, as três portas dão o mesmo contraste. A porta 587 em STARTTLS e a porta 465 em TLS implícito aceitam a ligação e devolvem o certificado; na porta 25, a ligação expira. A máquina está acessível, a porta é que está bloqueada. Repetido contra sete MX públicos de seis operadores diferentes, dois da Google, depois Proton, OVH, Riseup, Yandex e GMX, o mesmo comando expira sete vezes em sete.

A porta 25 está filtrada do nosso lado, à saída. A nuance importa, porque a conclusão inversa anda por todo o lado. A Google não fecha nada. AWS, GCP, Azure e OVH bloqueiam a porta 25 de saída por defeito, tal como a quase totalidade dos acessos residenciais. Um varrimento de parque lançado a partir de uma máquina deste tipo produz, portanto, um resultado mecanicamente incompleto.

O mesmo sintoma esconde, porém, duas causas distintas, e a segunda não vem da sua rede. A partir do mesmo posto, pop.gmail.com expira na porta 110 quando pop.gmx.net responde, e imap.gmx.net responde na 143, com STARTTLS validado, tal como na 993; a 995 passa em todo o lado. As portas em texto simples não estão, portanto, filtradas à saída, ao contrário da 25: são os hosts da Google que descartam esses pacotes sem resposta, porque não servem POP3 nem IMAP em texto simples. Política do fornecedor de um lado, filtragem da rede do outro: duas causas de "inacessível", um único sintoma. Antes de concluir que uma porta está filtrada, teste um segundo operador.

Um scanner de inventário tem, portanto, de distinguir três estados, e não dois: certificado lido, certificado em falha e host não alcançado. Um "inacessível" contado como "nada a assinalar" é o pior resultado possível, porque o painel fica verde para serviços que nunca foram medidos. E a questão não é teórica nos MX: se o certificado mudar antes de o registo TLSA correspondente ser publicado, a RFC 7672 proíbe a entrega da mensagem através desse servidor e obriga o remetente a passar para o MX seguinte ou a adiar a entrega.

As nossas próprias ferramentas esbarram no mesmo limite: o monitor de uptime da CaptainDNS só aceita os esquemas HTTP e HTTPS. SMTP, IMAPS e LDAPS ficam fora do seu âmbito.

As API dos fornecedores veem o que as outras três fontes associam mal

Resta a quarta fonte, a menos espetacular: as API dos fornecedores. O AWS Certificate Manager, a Cloudflare ou uma CDN que termina o TLS por si detêm certificados que mais nada associa corretamente ao seu parque. Os logs de transparência veem-nos sem dizer quem os opera, o disco não os contém e o varrimento de rede atribui-os à infraestrutura do fornecedor em vez do seu serviço. A API é o único sítio onde estas terminações geridas existem com a respetiva data de expiração e modo de renovação.

O seu ponto cego é simétrico: cada API só cobre o que está alojado nesse fornecedor e pressupõe permissões de leitura que a equipa responsável pelo inventário nem sempre tem. Três fornecedores são três consultas, três conjuntos de credenciais e três formatos de resposta a reconciliar.

Um inventário indexa-se por um par (host, porta), não por um nome

Mesmo nome, mesmo endereço IP, dois certificados. ldap.google.com resolve para um único endereço IPv4, 216.239.32.58. Um cliente com a configuração por defeito lê aí o número de série 84D4296C na porta 389 em STARTTLS, e E97CCECB na porta 636 em TLS implícito. Três execuções idênticas, três vezes o mesmo resultado.

Primeira armadilha: o SNI. Sem ele, as duas portas devolvem a sentinela da Google, CN=invalid2.invalid com OU=No SNI provided - please fix your client., número B3E9BADC: um scanner sem SNI regista um valor perfeitamente estável e perfeitamente falso, sempre sem erro.

No entanto, não é a porta em si que explica a diferença entre a 389 e a 636. O listener da 389 tem os dois certificados e escolhe consoante os algoritmos de assinatura anunciados pelo cliente:

openssl s_client -starttls ldap -connect ldap.google.com:389 -servername ldap.google.com \
  -sigalgs 'RSA-PSS+SHA256:rsa_pkcs1_sha256' </dev/null 2>/dev/null | openssl x509 -noout -serial

serial=E97CCECBFFF70F940963C3B2C1F06634

A 389 devolve, portanto, a pedido, o certificado que se julgava exclusivo da 636. O inverso falha: ECDSA+SHA256 forçado na 636 provoca um tls alert handshake failure (alerta 40), sem nenhum certificado. A 636 só tem o RSA, e é isso que salva a indexação por par (host, porta). Mas a configuração TLS do scanner é uma variável de entrada, tal como a porta: dois scanners com algoritmos de assinatura diferentes inventariam dois números de série diferentes no mesmo par, sem gerar o mínimo erro. Fixe e documente a configuração TLS do scanner; caso contrário, o inventário não é reproduzível de uma execução para a outra.

Noutros casos, o comportamento inverte-se: no Gmail, as portas 465 e 587 servem o mesmo certificado, 6D09D839.... Nada disto se adivinha, e um inventário indexado pelo nome de host conta mal nos dois sentidos: funde certificados distintos ou duplica o mesmo.

A folha de cálculo de auditoria para descarregar no fim do artigo retoma estas colunas: uma linha por par (host, porta), o modo TLS, o estado do último varrimento com os seus três valores possíveis, o método de instalação, o de recarregamento, o responsável designado e a classe de automação. Três linhas de exemplo mostram o preenchimento esperado; o resto está em branco.

Delegar _acme-challenge sem entregar as chaves da zona

Delegar _acme-challenge por CNAME dá ao cliente ACME permissão de escrita numa zona de validação dedicada, e nada mais. A sua zona de produção não muda: os mesmos registos, a mesma API fechada.

O que a delegação por CNAME é, e o que não é

A RFC 8555 não menciona o CNAME. A palavra não aparece em parte alguma do texto, verificámos. A delegação não é, portanto, uma recomendação da norma ACME: é documentada e suportada pela Let's Encrypt, cuja validação DNS-01 segue as regras DNS habituais e aceita que um CNAME ou uma delegação NS reencaminhe a resposta ao desafio para outra zona. No plano regulamentar, os Baseline Requirements citam explicitamente o registo CNAME entre os suportes válidos do método de validação "DNS Change", na secção 3.2.2.4.7.

A distinção cabe numa linha: suportada pelo ecossistema, ausente da norma.

A vantagem é clara. O cliente ACME recebe credenciais que só escrevem numa zona de validação, muitas vezes alojada noutro sítio. Se o servidor que faz as renovações for comprometido, o atacante não ganha nenhum poder sobre os seus registos MX, A ou TXT de produção. Ao analisar 32 domínios públicos, encontrámos várias delegações reais deste tipo: fastmail.com aponta para fastmail.com.acme-challenge.fmhosted.com, github.com para github.com.acme.github.net, reddit.com para um destino dcv.cloudflare.com, eff.org e digitalocean.com para fastly-validations.com.

Verificar uma delegação: três etapas, nunca uma só

Uma única consulta não prova nada. A verificação completa exige três, e é a terceira que transforma uma dúvida em prova.

Etapa 1, o CNAME existe:

dig +noall +answer _acme-challenge.fastmail.com CNAME

_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

É tudo o que este comando diz: há um CNAME escrito. Não prova que a delegação funciona.

Etapa 2, seguir a cadeia até ao TXT e ler o status:

dig +noall +answer +comments _acme-challenge.fastmail.com TXT

Três casos reais, e é aqui que a maioria dos artigos se engana:

CASO A - fastmail (CNAME presente, destino sem TXT ativo)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59352
_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

CASO B - reddit (CNAME presente, destino existente)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8461
_acme-challenge.reddit.com. 292 IN CNAME reddit.com.7ee8918f112aca0f.dcv.cloudflare.com.

CASO C - captaindns.com (nenhuma delegação)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27534
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

É preciso cruzar dois sinais, nunca um só. Um CNAME na secção ANSWER com um NXDOMAIN significa que a delegação está escrita, mas que o destino não existe neste momento, porque o TXT só é criado no momento do challenge. É o estado normal entre duas renovações: das sete delegações públicas que consultámos, seis estavam nesta situação. A verdadeira falha é um NOERROR com ANSWER: 0, ou seja, nenhuma delegação. Uma monitorização que alerte para o NXDOMAIN de _acme-challenge produzirá ruído permanente e enganar-se-á seis vezes em sete.

Etapa 3, verificar ao nível autoritativo e confirmar que a zona de destino está ativa:

ns=$(dig +short NS fastmail.com | head -1)
dig +noall +answer +comments @"$ns" _acme-challenge.fastmail.com CNAME
dig +noall +answer +comments acme.github.net SOA

O SOA de acme.github.net responde NOERROR, ao passo que a consulta TXT sobre _acme-challenge.github.com devolvia NXDOMAIN: a delegação está saudável, só falta a resposta ao desafio porque não há renovação em curso. Pelo contrário, um SOA em NXDOMAIN ou em SERVFAIL na zona de destino indica uma delegação definitivamente partida, tipicamente uma conta de validação eliminada ou um domínio expirado.

O nome começa por um underscore, que algumas interfaces de administração engolem ou duplicam: verifique o FQDN devolvido na resposta DNS, não o que o painel mostra; uma consulta CNAME na ferramenta DNS Lookup mostra-o sem abrir um terminal. Um CNAME em _acme-challenge é incompatível com qualquer outro registo com o mesmo nome, pelo que um TXT de validação antigo esquecido torna a zona inválida. Os TTL observados vão de 3.600 a 120 segundos consoante o domínio: depois de uma correção, um resolvedor pode servir a resposta antiga, NXDOMAIN incluído, durante todo esse tempo, e esta é a principal causa das falhas de validação logo após uma alteração. O head -1 só testa um servidor autoritativo. Por fim, consultar a zona de destino não prova que o cliente tem lá permissão de escrita: só uma emissão real o prova.

O limite de um único delegado por domínio, e o draft que o levanta

O DNS só permite um CNAME por nome. _acme-challenge.captaindns.com só pode, portanto, ser delegado a um único cliente de cada vez. Multi-CDN, multirregião, migração sem interrupção, certificado de reserva emitido por uma segunda autoridade: estas quatro necessidades batem todas na mesma parede, e não existe nenhuma solução limpa do lado do DNS.

Um draft em curso no IETF ataca o problema. O draft-ietf-acme-dns-account-label-03, Active Internet-Draft do grupo de trabalho ACME, revisão 03 de 15 de maio de 2026, em fase de last call do grupo de trabalho no momento da nossa verificação, define um challenge chamado dns-account-01. O princípio: prefixar o nome de validação com um resumo (digest) da URL da conta ACME, segundo a construção "_" || base32(SHA-256(ACCOUNT_URL)[0:10]) || "._acme-challenge". Cada conta obtém assim o seu próprio nome de validação, e vários clientes podem validar em paralelo no mesmo domínio.

É um draft, não uma norma. Não tem número de RFC, o conteúdo pode mudar na próxima revisão, e não anunciamos qualquer disponibilidade junto de uma autoridade de certificação. Vale a pena acompanhar se a sua arquitetura é multifornecedor, mas não o inclua num plano de implementação.

A renovação de um certificado SSL não acaba na emissão: o recarregamento é o verdadeiro elo fraco

O certbot renew escreve o novo certificado no disco. Não recarrega o nginx, nem o postfix, nem o haproxy. Entre o momento em que a emissão é bem-sucedida e aquele em que o serviço apresenta o novo certificado, há um recarregamento, e é aí que a cadeia parte com mais frequência, sem que nenhum log dê sinal. A defesa do lado do cliente chama-se deploy hook, e o guia de gestão do ciclo de vida dos certificados dedica-lhe a sua fase 3; o controlo que se segue verifica, de fora, se funcionou realmente.

O controlo pós-renovação e os seus cinco falsos positivos

O único controlo que conta compara o número de série lido no disco com o que é realmente servido na rede:

HOST=api.captaindns.com
FILE=/etc/letsencrypt/live/$HOST/fullchain.pem

disk=$(openssl x509 -in "$FILE" -noout -serial | cut -d= -f2)
served=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
         | openssl x509 -noout -serial | cut -d= -f2)

echo "disco  =$disk"
echo "servido=$served"
[ "$disk" = "$served" ] \
  && echo "OK: o certificado servido é o do disco" \
  || echo "ALERTA: o serviço serve um certificado ANTIGO -> reload necessário"

Os dois ramos foram mesmo executados, com dois números de série distintos:

CASO 1 - concordância
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servido=05DFD8366DC6A73780F3707BC7E13F91E0EC
OK: o certificado servido é o do disco

CASO 2 - divergência
disco  =05DFD8366DC6A73780F3707BC7E13F91E0EC
servido=05B499411D7820A6C0EC7A0626E1BA25CF67
ALERTA: o serviço serve um certificado ANTIGO -> reload necessário

Este controlo tem as suas armadilhas, e a primeira é tola. O cut -d= -f2 não é decorativo: o openssl mostra serial=05DF... e, sem ele, a comparação falha. Compare o número de série, nunca a data de expiração: dois certificados renovados no mesmo dia podem partilhar o notAfter. O ficheiro fullchain.pem contém vários certificados e o openssl x509 -in só lê o primeiro, pelo que um ficheiro ordenado ao contrário leva a comparar o intermédio e faz o teste falhar sempre. Atrás de um balanceador de carga que termina o TLS, o certificado instalado no disco da origem não tem nenhuma relação com o que é servido ao público: o controlo torna-se um falso positivo permanente, e é preciso apontá-lo a partir do exterior do balanceador. Por fim, para identificar o ficheiro em vez da emissão, substitua -serial por -fingerprint -sha256.

Este controlo não tem nada de específico da porta 443. Repetimo-lo fora da web: em TLS implícito na porta 465 e depois em STARTTLS na porta 587, com o mesmo número de série 6D09D839... dos dois lados. Um parque de correio verifica-se exatamente da mesma forma, com a opção de ligação adequada.

A impressão digital SPKI SHA-256 oferece um controlo complementar, a montante. É apresentada tanto pelo nosso SSL Certificate Checker como pelo CSR Parser, o que permite provar que um dado CSR produziu de facto o certificado servido. A comparação é manual: nada a faz automaticamente por si.

Todos os seus front-ends servem o mesmo certificado?

Um ciclo sobre os endereços IP do serviço responde à pergunta em poucos segundos:

HOST=debian.org
for ip in $(dig +short A "$HOST" | grep -E '^[0-9]'); do
  printf '%-16s ' "$ip"
  openssl s_client -connect "$ip:443" -servername "$HOST" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial | cut -d= -f2
done

Em debian.org, os quatro endereços devolvidos deram todos o mesmo número de série, 057EB3AB.... Parque homogéneo deste lado. O essencial do truque está no -servername indicado quando a ligação é feita a um IP: sem ele, obtém o certificado por defeito do front-end, e não o do vhost pretendido. O grep -E '^[0-9]' filtra as linhas de CNAME que o dig +short intercala, comportamento observado em www.google.com devido a uma reescrita do resolvedor local.

O ciclo só cobre o IPv4: acrescente uma passagem por dig +short AAAA com -connect "[$ip]:443". O outro limite é mais traiçoeiro. Atrás de um anycast (um mesmo endereço anunciado a partir de vários pontos do globo), estes quatro endereços pertencem ao mesmo ponto de presença visto a partir do seu posto: está a testá-lo quatro vezes, e não aos N outros espalhados pelo mundo.

Diagnosticar uma porta mal identificada numa linha de erro

Não vale a pena adivinhar o modo de uma porta: o openssl indica-o na mensagem de erro. Um wrong version number significa que falta o -starttls: o servidor espera um diálogo em texto simples antes da negociação. Pelo contrário, um Didn't find STARTTLS in server response, trying anyway... seguido de unexpected eof while reading significa que o -starttls está a mais, numa porta já encriptada: o openssl tenta mesmo assim, espera um banner em texto simples de um servidor que só espera TLS, e a ligação morre num EOF.

O comando equivalente num MX na porta 25 escreve-se assim:

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 \
  -servername gmail-smtp-in.l.google.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -serial

Não validado a partir do nosso posto, porta 25 de saída filtrada; sintaxe validada de forma idêntica na 587. Por isso, não publicamos nenhuma saída para este comando. Mesmo assim, vale a pena assinalar três armadilhas: o 2>/dev/null engole o erro real e deixa-o com um Could not find certificate from <stdin> seja qual for o problema, o </dev/null evita que a sessão fique aberta, e o -servername deve conter o nome do MX, não o do domínio de correio.

DANE e TLSA: o único caso em que a ordem das operações é normativa

O recarregamento tem um último andar, reservado aos MX que publicam registos TLSA. Aí, a ordem das operações deixa de ser uma boa prática e passa a ser uma obrigação. A RFC 7671, secção 8.1, descreve a rotação em quatro tempos: publicar o registo TLSA do futuro certificado ao lado do do certificado atual, esperar pelo menos dois TTL para que as caches se esvaziem, instalar então o novo certificado e verificar que funciona e, por fim, retirar o registo que ficou obsoleto. Dois TTL, não 48 horas: a RFC raciocina em TTL, e os seus TTL não são os nossos.

No SMTP, a RFC 7672 torna-o uma obrigação formal. Em caso de dessincronização, a entrega através desse servidor é proibida, e o remetente passa para o MX seguinte ou adia a entrega.

O modo de falha é assimétrico, e é isso que o torna temível. Do lado do operador em falta, nenhum alerta: a ligação é abortada pelo cliente, os remetentes que não validam DANE continuam a entregar, a monitorização continua verde. A RFC 7672 usa a palavra "unwittingly" para descrever esse domínio parceiro que fica mal configurado sem o saber. Do lado do remetente que valida, não é silencioso, mas adiado: as mensagens acumulam-se na fila de espera, com avisos de atraso e, depois, eventuais devoluções quando expiram. O destinatário final, esse, não recebe nem a mensagem nem a mínima notificação.

Resta uma condição que a secção 8.1 estabelece sem a sublinhar: a utilização, o seletor e o tipo de correspondência têm de se manter inalterados. Se alterar um destes três parâmetros, aplica-se a secção 8.3, e a regra inverte-se.

Os casos rebeldes ao ACME: o que não se deixa automatizar

Uma parte do parque resiste, e não por razões de protocolo. O ACME consegue emitir para quase tudo. O que emperra é a instalação, o recarregamento ou o nível de validação exigido.

A PKI interna e os certificados de dois anos

As autoridades internas escapam ao calendário do CA/Browser Forum, por isso nada as leva a encurtar nem a automatizar. A instância pública de demonstração do FreeIPA mostra-o bem: no levantamento de 21 de julho de 2026, ipa.demo1.freeipa.org servia um certificado válido de 23 de abril de 2025 a 24 de abril de 2027, ou seja, dois anos, numa cadeia assinada por uma raiz privada.

Visto de um posto externo, o openssl devolve verify error:num=19 self-signed certificate in certificate chain. Este código confunde-se muitas vezes com outro: verify error:num=20 unable to get local issuer certificate. Não descrevem a mesma situação. O 19 significa que o servidor envia mesmo a sua raiz privada na cadeia, mas que esta não está no seu repositório local. O 20 significa que o intermédio não é enviado de todo e que o openssl não consegue subir a cadeia. Nos dois casos, o diagnóstico é o mesmo: problema de repositório de confiança, não problema de certificado. A correção também: -CAfile internal-ca.pem.

Existem pontes para trazer estes parques de volta ao ACME. Nenhuma se implementa sem contrapartida, e mais vale conhecê-la antes.

• acme2certifier, com licença GPLv3, coloca uma fachada ACME à frente do Microsoft ADCS através de MS-WCCE ou dos Certificate Enrollment Web Services. A revogação não é suportada e a cadeia da autoridade tem de ser carregada à mão. É um projeto comunitário mantido por uma única pessoa, e ativo: versão 0.44 a 18 de julho de 2026.
• O step-ca é um ponto único de falha na configuração por defeito, por causa da sua base de dados embutida Badger, que não gere a concorrência. A documentação descreve uma implementação com várias instâncias, à custa de uma base de dados MySQL ou PostgreSQL externa e da gestão remota dos provisioners.
• O HashiCorp Vault expõe um servidor ACME desde a versão 1.14.0, com um tempo de vida limitado a 90 dias. É um servidor, não um cliente, e a nuance muda tudo numa arquitetura.
• EJBCA Community Edition: é a própria Keyfactor que o escreve no README do repositório oficial, "EJBCA Community Edition is not intended for production use."

Os certificados que o ACME não consegue emitir

O nível de validação estendida não se obtém por ACME. Pressupõe uma verificação de identidade jurídica (categoria de atividade, jurisdição de registo, número de registo comercial) que nenhum challenge automatizado produz.

O caso aparece em produção. No mesmo levantamento, na porta 465, posteo.de servia um certificado de validação estendida válido de 18 de fevereiro de 2026 a 24 de fevereiro de 2027, ou seja, 371 dias. E, no entanto, sem qualquer violação do teto de 200 dias. O certificado foi emitido antes de 15 de março de 2026, e a regra não é retroativa. Não tiramos daí nenhuma conclusão sobre as práticas de renovação deste operador.

O campo estreita-se ainda mais. Os certificados de marca VMC e CMC, usados pelo BIMI, descodificam-se com o nosso analisador dedicado, mas não são certificados TLS de servidor. Já os certificados de cliente, nomeadamente os que servem para autenticação mútua, seguem uma cadeia de emissão e uma distribuição que nada têm a ver com o ACME.

Os endpoints que nenhum script recarrega

Eis o verdadeiro teto da automação, e o único número que conta para decidir uma compra. Passe o seu parque em revista e conte o seguinte.

Os appliances de rede administráveis apenas por interface web. Os balanceadores de carga físicos, cuja atualização de certificado passa por um formulário. As impressoras, os equipamentos industriais, as câmaras e tudo o que tenha um servidor HTTPS esquecido desde a instalação. Os keystores Java protegidos por uma palavra-passe interativa, que bloqueiam de imediato qualquer execução não supervisionada. Os repositórios do Windows, onde instalar um certificado não chega, porque um binding do IIS pode continuar a apontar para outra impressão digital. As terminações TLS geridas num fornecedor que não expõe nenhuma API.

O ponto comum não é a emissão: o ACME consegue emitir para todos estes nomes. São a instalação e o recarregamento que continuam manuais. Um script pode obter o certificado em poucos segundos e depois ficar à espera de que uma pessoa aceda a uma interface para o instalar. Com 200 dias de validade, essa pessoa intervém duas vezes por ano e ninguém se queixa. Com 47 dias, intervém oito vezes por ano e por endpoint no mínimo absoluto, se renovar no fim da validade, e onze a doze vezes se renovar aos dois terços, como recomendado. O custo passa a ser uma linha de orçamento.

Meça-o agora, enquanto a frequência ainda é baixa: número de endpoints envolvidos, minutos realmente gastos por rotação, responsável designado. Estas três colunas valem mais do que todas as comparações de ferramentas.

Cadência, perfis curtos e o que realmente limita um ciclo de renovação

Um ciclo de renovação não é limitado pela dimensão do parque. É limitado pela cadência a que cada nome é reemitido e por dois ou três limites de taxa que nada têm de intuitivo.

Quando renovar: a regra dos dois terços tem uma exceção

A regra geral é simples: renovar quando resta um terço do tempo de vida total. Ou seja, 30 dias antes do fim da validade para um certificado de 90 dias. Mas a documentação da Let's Encrypt prevê uma exceção explícita para os certificados válidos por menos de dez dias: nesses, a renovação é recomendada a meio da vida.

O perfil shortlived cai precisamente na exceção. Vale 160 horas, ou seja, 6,67 dias. O meio da vida fica, portanto, nas 80 horas, o que dá 2,1 emissões por semana e por nome.

Este 2,1 é um modelo, não um valor publicado pela Let's Encrypt. As suas cinco hipóteses, sem rodeios. A validade de 160 horas está documentada. A semana reduzida a 168 horas fixas é uma aproximação: o mecanismo real é um token bucket com recarga contínua. A renovação a uma fração fixa e determinística, sem jitter nem nova tentativa, é uma hipótese de modelação. Um certificado equivale a um nome, quando o shortlived aceita até 25 nomes: agrupar divide o número de certificados na mesma proporção. E o cálculo pressupõe zero falhas.

Ressalva mais importante: com o ARI, que é o modo nominal, a cadência não segue uma fração fixa, mas sim a janela sugerida pelo servidor, cuja posição e largura não são publicadas. Qualquer cadência expressa em fração do tempo de vida descreve, portanto, uma rede de segurança, não o regime normal.

Quanto aos "cerca de trinta nomes por domínio em perfil curto" que circulam, esse número divide uma quota que as renovações não consomem por uma cadência que não se aplica a este perfil: não o reproduzimos.

O que a Let's Encrypt considera uma renovação

Dois mecanismos, dois regimes de isenção. Confundi-los é o erro que sai mais caro em produção.

Com o ARI, o pedido newOrder designa explicitamente o certificado que substitui. Na realidade, há três condições: essa designação, pelo menos um identificador em comum com o certificado cessante e um certificado cessante que ainda não tenha sido substituído uma primeira vez. A isenção é então total. Todos os limites de taxa deixam de se aplicar, sem exceção, e o conjunto de SAN pode até mudar, já que a identidade do certificado cessante vai no campo dedicado.

Com a deteção por conjunto exato, o regime é mais estreito. O conjunto de identificadores tem de ser estritamente idêntico, sem que maiúsculas, minúsculas ou a ordem tenham qualquer efeito (nuance que muitos artigos invertem). A isenção cobre então apenas New Orders per Account e New Certificates per Registered Domain.

O corolário merece ser afixado na parede: alargar um certificado SAN para lhe acrescentar um subdomínio consome a quota dos 50 por domínio registado, ao passo que a renovação idêntica não consome nenhuma. Escrever "50 certificados por semana por domínio" sem esta precisão é descrever um teto de parque que não existe. Este limite mede um débito de entrada de novos nomes.

Os limites que mordem, por ordem de perigo

Há cinco limites de taxa a conhecer, e não se equivalem. Aqui estão, do mais perigoso ao menos incómodo.

O primeiro é o único que um ciclo legítimo consegue esgotar sozinho: 5 falhas de autorização por identificador, por conta e por hora, recarga de uma falha a cada 12 minutos, sem aumento possível e, sobretudo, aplicável às renovações. O segundo conta as falhas consecutivas e põe o identificador em pausa ao fim de 1.152 falhas seguidas. É um contador de série, não um débito, e recarrega um token por identificador e por dia: um dia com cinco falhas só consome quatro em termos líquidos, e a pausa só chega ao fim de 288 dias; a 120 falhas por dia, chega ao fim de 10 dias, e com uma só por dia, nunca. Estes valores não saem de um cálculo caseiro: a documentação da Let's Encrypt publica a tabela. Não misture os dois limites.

Segue-se o verdadeiro teto de um ciclo sem ARI: 5 certificados por conjunto exato de identificadores a cada 7 dias, recarga de um certificado a cada 34 horas, sem aumento possível. Uma cadência de 2,1 passa com folga, e a margem absorve as novas tentativas. Mais abaixo na classificação, 10 contas por endereço IP a cada 3 horas só morde se cada nó criar a sua própria conta em vez de partilhar uma. O último nem sequer é uma quota, mas uma restrição de perfil: o shortlived fica limitado a 25 nomes por certificado, contra 100 no classic. Passar para o perfil curto obriga, portanto, a dividir os grandes certificados SAN, e essas divisões são emissões novas, não renovações.

Os limites de taxa da Let's Encrypt que afetam um ciclo de renovação

Valores documentados na página oficial de rate limits, consultada a 21 de julho de 2026. Estas isenções e estes tetos são próprios da Let's Encrypt e não se aplicam às outras autoridades de certificação.

5

Falhas de autorização por identificador, por conta e por hora

Recarga de uma falha a cada 12 minutos, sem aumento possível, aplicável às renovações.

5

Certificados por conjunto exato de identificadores a cada 7 dias

Recarga de um certificado a cada 34 horas, sem aumento possível.

50

Novos certificados por domínio registado a cada 7 dias

Débito de entrada de novos nomes, recarga de um certificado a cada 202 minutos. As renovações estão isentas.

1.152

Falhas consecutivas antes da pausa do identificador

Contador de série reposto a zero assim que uma validação é bem-sucedida; saída através do portal de self-service.

O guia de integração da própria Let's Encrypt acrescenta dois conselhos de operação: acima de 10.000 nomes, renovar em pequenos lotes em vez de grandes pacotes, e espalhar de uma vez por todas as datas de renovação. O formulário de aumento de quota só abrange dois limites, demora algumas semanas a ser tratado e nunca repõe um contador a zero: é uma ferramenta de planeamento, não um recurso de emergência.

Tudo o que precede descreve a política da Let's Encrypt, e nada mais. No AWS Certificate Manager, o número estruturante não é uma quantidade de certificados, mas um débito: o FinalizeOrder limitado a um pedido por segundo; estas quotas estão documentadas no guia do utilizador.

O verdadeiro modo de falha: dois cenários, e nenhum é uma quota

Os incidentes de renovação que vemos não se parecem com uma quota de emissão ultrapassada. Parecem-se com estes dois cenários, que partilham uma característica desagradável: agravam-se sozinhos.

Cenário 1, o ciclo de falhas. Uma credencial DNS expira, uma delegação parte-se, a porta 80 fecha-se após uma alteração de regra de rede. O cliente ACME volta a tentar, muitas vezes de forma agressiva, porque essa é a configuração por defeito de muitas instalações. À sexta falha na mesma hora sobre o mesmo identificador, qualquer pedido com esse nome é recusado, e a recarga desce para uma falha a cada 12 minutos. Um incidente que se resolveria em dez minutos transforma-se numa avaria de várias horas, não por causa do problema de origem, mas por causa do comportamento do cliente perante o problema. Entretanto, o contador de falhas consecutivas sobe rumo às 1.152 do segundo limite. A defesa resume-se a dois ajustes: um backoff exponencial do lado do cliente e um alerta sobre a falha de validação, em vez de apenas sobre a aproximação da expiração.

Cenário 2, a renovação que deixa de o ser. Sem ARI, acrescentar ou retirar um único nome de um certificado SAN faz-lhe perder o estatuto de renovação e devolve o pedido à quota dos nomes novos. Ora, muitos parques geram os seus conjuntos de SAN a partir de um inventário dinâmico: controlador de ingress do Kubernetes, ambientes efémeros, plataformas de pré-visualização. Nenhum pedido volta a ser uma renovação, e um parque que até é estável consome o débito reservado aos nomes novos.

O que torna este segundo cenário real é o estado dos clientes a 21 de julho de 2026. O Certbot lê o ARI, mas não envia o campo replaces: a sua implementação continua só de leitura, pelo que todos os seus pedidos assentam na deteção por conjunto exato. O lego envia replaces desde a v4.16.0, mas, desde a v5.1.0, ignora o ARI se os SAN tiverem mudado. O cert-manager consegue enviá-lo, atrás do feature gate ACMEUseARI, classificado como Alpha e desativado por defeito, disponível desde a v1.21.0, lançada a 8 de julho de 2026. O acme.sh envia-o desde a versão 3.1.4, lançada a 17 de julho de 2026, ou seja, quatro dias antes de verificarmos este ponto. A proteção existe na norma desde junho de 2025. Quase em lado nenhum está efetivamente em uso.

Monitorização da expiração dos certificados SSL: duas coisas a vigiar, não uma

A monitorização da expiração e a da falha de renovação são dois sistemas distintos. O primeiro vê a consequência, com semanas de atraso. O segundo vê a causa, no próprio dia. Um parque bem equipado tem os dois, e não dependem do mesmo componente.

Limiares que não sobrevivem aos certificados curtos

Um limiar de alerta fixado em 30 dias torna-se absurdo num certificado de 47 dias. Dispara logo no 17.º dia de vida do certificado, ou seja, durante mais de metade da sua existência. O alerta é permanente, logo invisível, logo inútil. O limiar tem de passar a ser relativo ao tempo de vida: uma fração, não uma constante.

Mais vale aplicar esta exigência às nossas próprias ferramentas. O SSL Certificate Checker da CaptainDNS usa um limiar de "expira em breve" fixado em 30 dias, e os patamares de alerta da nota de postura são D-30, D-14, D-7, D-3 e D-1. Um limiar relativo do tipo max(15, tempo de vida / 3) está previsto na especificação interna, mas não está implementado. Num parque em perfil curto, estes valores têm de ser recalculados por si.

O que deve disparar um alerta além da expiração

Além da data de expiração, seis sinais merecem um alerta. O último da lista é o mais útil de todos.

• Uma mudança de número de série assinala uma renovação efetiva, ou seja, uma boa notícia que convém, ainda assim, ver passar.
• Uma mudança de emissor pode denunciar uma troca de autoridade não prevista.
• Uma cadeia que ficou incompleta quebra a validação apenas em parte dos clientes, o que a torna difícil de reproduzir.
• Um nome de host que deixou de corresponder aparece depois de uma migração.
• Um protocolo ou uma chave que se tornaram fracos indicam uma configuração que regrediu.
• E, sobretudo, a falha de validação ACME: o único sinal que chega a tempo de evitar a avaria.

Pelo contrário, dois reflexos só produzem ruído. Nunca alertar para um NXDOMAIN de _acme-challenge, pela razão explicada acima. E não alertar para uma simples mudança de impressão digital sem mudança de estado visível, sob pena de colher falsos positivos a cada troca de front-end.

Os nossos limites, ditos com franqueza, porque mudam a forma de ler os parágrafos anteriores. A nota de postura é um opt-in pago por monitor. A sua cadência por defeito é de 86.400 segundos, ou seja, uma passagem por dia: falar de "monitorização contínua" seria falso. Não há nenhuma descoberta de parque, nenhuma enumeração através dos logs de transparência: vigia o que declara, uma URL de cada vez. E não há nenhum STARTTLS, logo nada sobre os seus servidores de correio.

A partir de quando vale a pena pagar por uma ferramenta?

O limiar de compra não se conta em certificados. Conta-se em endpoints que nenhum script consegue recarregar. Um parque de 800 certificados inteiramente geridos por um controlador de ingress não justifica qualquer despesa; um parque de 60 certificados, dos quais 25 estão em appliances com interface web, justifica-a de imediato.

Classifique o seu parque em três colunas e depois conte a terceira.

Classe	O que o script faz	O que continua manual
Automatizável de ponta a ponta	Emissão, instalação, recarregamento, verificação do número de série servido	Nada em regime nominal
Semiautomatizável	Emissão e gravação do ficheiro	Instalação ou recarregamento manual, muitas vezes numa consola
Não automatizável	Apenas a emissão	Início de sessão numa interface web, importação do ficheiro, reinício

O ponto de viragem lê-se na terceira linha, multiplicada pela frequência futura. Um endpoint não automatizável custa, no regime de 47 dias, oito intervenções por ano no mínimo absoluto, o de uma renovação no fim da validade, e onze a doze se renovar aos dois terços, como recomendado; o guia do ciclo de vida modela um pouco menos de oito com outra hipótese de calendário, sem que a ordem de grandeza mude. Contra duas hoje. Faça o produto com os seus minutos medidos, não estimados, e compare com o preço de uma licença: o cálculo não exige benchmark nem concurso.

O modelo de limiar fornecido no fim do artigo torna estas hipóteses modificáveis uma a uma: número de endpoints não recarregáveis, cadência de rotação por patamar de validade, minutos por rotação, custo horário total e preço de referência. Cada valor pré-preenchido indica o seu estatuto, documentado, derivado ou recolhido numa data, pelo que substituir as nossas hipóteses pelas suas demora um minuto.

Precisamente, os preços. No AWS Marketplace, levantamento de 21 de julho de 2026, a ficha AppViewX AVX ONE CLM mostra dois patamares públicos num contrato de um mês: 2.100 USD por mês para 100 certificados de servidor e 4.200 USD por mês para 250 certificados de servidor. O mesmo fornecedor publica 5.000 USD e 9.100 USD por mês na sua ficha PKIaaS, o que impede apresentar os 2.100 USD como "o" preço público do fornecedor. A ficha Venafi Certificate Management Service não tem nenhum preço e remete para uma oferta privada mediante orçamento. A ficha DigiCert mostra um valor de 5.000 USD para um contrato de doze meses, mas precisa que está reservada a compras por oferta privada. Este levantamento refere-se às fichas consultadas nesse dia, num único marketplace, e à noção de preço que qualquer pessoa pode subscrever publicamente. Não diz nada sobre tarifas negociadas, nem sobre os fornecedores ausentes deste levantamento.

Uma palavra sobre o mercado, formulada como constatação de ausência. Não há nenhum Magic Quadrant dedicado à gestão do ciclo de vida dos certificados referenciado em gartner.com: a consultora trata o tema num "Buyers' Guide for PKI and Certificate Life Cycle Management" publicado a 29 de maio de 2025 e num espaço de avaliações de utilizadores, o Peer Insights. Quanto aos números que circulam nos argumentos comerciais, são atribuíveis e nada mais: num comunicado de 2 de julho de 2025, a DigiCert indica que 45% dos inquiridos no seu inquérito "Trust Pulse" declaram ter sofrido uma interrupção de serviço ligada a um incidente de certificado, e que 31% referem perdas entre 50.000 e 250.000 dólares. O comunicado não indica o número de inquiridos, nem o seu perfil, nem os países abrangidos, nem o período de recolha, e não encontrámos nenhum relatório que detalhe essa metodologia nessa data. São declarações de inquiridos num inquérito encomendado por um ator da categoria, não uma medição.

Retenha o gesto, não os números: conte a terceira coluna, multiplique pelos seus minutos, compare.

🎯 Plano de ação: a sequência a seguir

Oito ações, por esta ordem. As três primeiras fazem-se uma vez; as seguintes tornam-se reflexos de operação.

1. Inventariar por par (host, porta), cruzando os logs de transparência, o disco e os repositórios e, depois, o varrimento de rede. Lance esse varrimento a partir de uma rede que não filtre as portas de saída; caso contrário, os seus servidores de correio nunca aparecerão.
2. Tratar "host não alcançado" como uma falha do inventário, com uma linha explícita no relatório. Um inacessível silencioso contado como sucesso é o que torna um painel falso.
3. Delegar _acme-challenge por CNAME e depois verificar a delegação em três etapas: o CNAME existe, a cadeia resolve-se, a zona de destino responde em SOA. E não alertar para os NXDOMAIN fora do período de renovação.
4. Verificar, após cada renovação, que o número de série servido é o do disco, incluindo fora da 443. É o controlo que apanha o recarregamento esquecido, e custa duas linhas de script.
5. Pôr um backoff exponencial no cliente e alertar para a falha de validação. Sem isso, um incidente de dez minutos transforma-se num bloqueio de uma hora.
6. Verificar se o seu cliente envia replaces, ou aceitar depender da deteção por conjunto exato, o que equivale a congelar os seus SAN.
7. Passar os limiares de alerta de um valor fixo para uma fração do tempo de vida. Trinta dias não significam nada num certificado de 47 dias.
8. Contar os seus endpoints não recarregáveis antes de comparar ferramentas. Esse número decide a compra; o número de certificados, não.

Oito ações, dois ficheiros para descarregar e um único número a produzir: a quantidade de endpoints que ninguém sabe recarregar. É esse número que decide o que vem a seguir, não a dimensão do parque.

FAQ

É possível renovar automaticamente um certificado SSL?

Sim, e é o modo nominal com ACME há anos. A verdadeira questão está na cadeia completa: emissão, instalação, recarregamento do serviço e verificação. A extensão ARI permite, além disso, seguir a janela sugerida pela autoridade, mas o suporte do lado do cliente continua desigual a 21 de julho de 2026. O Certbot lê-a sem enviar o campo replaces, o cert-manager mantém-na atrás de um feature gate desativado por defeito e o acme.sh implementou-a na versão 3.1.4, a 17 de julho de 2026.

Como automatizar a renovação dos certificados SSL?

Bastam três peças. Um cliente ACME agendado, que obtém o certificado. Uma delegação de _acme-challenge por CNAME para uma zona de validação dedicada, o que evita confiar as chaves da sua zona de produção ao servidor que faz as renovações. E um controlo que compara o número de série lido no disco com o que é realmente servido na porta em causa. A terceira peça é a que se esquece, e é ela que deteta o recarregamento em falta.

Como renovar um certificado SSL?

Uma renovação não é uma prorrogação: é uma reemissão completa, com uma nova validação de controlo do domínio se a janela de reutilização tiver expirado. Na Let's Encrypt, um pedido é reconhecido como renovação de duas formas: designa, através do ARI, o certificado que substitui, ou contém exatamente o mesmo conjunto de identificadores que o certificado cessante. Nos dois casos, escapa aos limites de emissão para nomes novos.

Porque é necessário renovar um certificado SSL?

Porque um certificado público tem agora uma duração máxima rígida: 200 dias no patamar em vigor a 21 de julho de 2026, depois 100 dias em março de 2027 e 47 dias em março de 2029. O certificado não fica mais frágil com a idade; o CA/Browser Forum encurta as durações para limitar o tempo durante o qual uma chave comprometida ou uma prova de controlo do domínio caducada se mantém válida. A renovação é o preço dessa janela de exposição mais curta.

Como verificar se uma renovação entrou realmente em vigor?

Deixe o cliente ACME fazer a emissão e depois verifique o resultado através da rede, e não dos logs do cliente. O comando útil compara openssl x509 -in fullchain.pem -noout -serial com o número de série devolvido pelo openssl s_client no serviço. Se os dois forem diferentes, o certificado está renovado no disco, mas o serviço ainda serve o antigo: falta um recarregamento.

O que fazer se o meu certificado SSL expirar?

Num serviço web, a expiração nota-se de imediato: os navegadores bloqueiam. Num servidor de correio protegido por DANE, é mais traiçoeiro. A RFC 7672 proíbe a entrega através de um servidor cuja autenticação falha, e o remetente passa para o MX seguinte ou adia a entrega: do seu lado, nenhum alerta. Comece, por isso, o diagnóstico pela leitura do certificado realmente servido na porta em causa, e não pelos logs da aplicação.

Quantos certificados Let's Encrypt posso renovar por semana?

A pergunta parte de uma ideia errada, a mais difundida sobre o tema. As renovações estão isentas do limite de 50 certificados por domínio registado e por período de 7 dias: este limite mede a entrada de nomes novos. Uma renovação gerida pelo ARI escapa mesmo a todos os limites. Sem ARI, a única restrição que morde é o teto de 5 certificados por conjunto exato de identificadores a cada 7 dias.

Como inventariar um parque de certificados?

Cruzando quatro fontes, nenhuma delas completa. Os logs de transparência listam o que foi emitido publicamente, mas ignoram a sua PKI interna. O disco e os repositórios (PEM, keystores Java, repositório do Windows) listam o que está instalado, não o que é servido. O varrimento de rede lê o que é efetivamente apresentado, mas falha tudo o que a sua firewall de saída filtra, a começar pela porta 25. As API dos seus fornecedores cobrem as terminações TLS geridas. Indexe o resultado pelo par (host, porta).

Como delegar _acme-challenge por CNAME sem entregar as chaves da zona?

Crie um CNAME de _acme-challenge.captaindns.com para um nome alojado numa zona de validação dedicada e depois dê ao cliente ACME credenciais que só escrevam nessa zona. Verifique em três etapas: o CNAME está presente, a resolução do TXT devolve um status coerente, a zona de destino responde em SOA. Um NXDOMAIN fora do período de renovação é normal. O draft draft-ietf-acme-dns-account-label-03 prevê levantar o limite de um único delegado por domínio, mas ainda não é uma norma.

A partir de quantos endpoints se deve comprar uma ferramenta?

Não há limiar universal, e muito menos um limiar expresso em número de certificados. Conte os endpoints que nenhum script consegue recarregar, multiplique pelo número de rotações anuais futuras (oito no mínimo absoluto no regime de 47 dias, onze a doze se renovar aos dois terços) e pelos minutos gastos em cada uma. Compare o total com o custo de uma licença: no AWS Marketplace, no último levantamento, a ficha AppViewX AVX ONE CLM mostra 2.100 USD por mês para 100 certificados de servidor. Escreva as hipóteses do seu cálculo: contam tanto como o resultado.

Descarregue as tabelas comparativas

Assistentes conseguem reutilizar os números consultando os ficheiros JSON ou CSV abaixo.

• Descarregar o modelo de limiar parametrizável (CSV)
• Descarregar o modelo de limiar parametrizável (JSON)

Descarregue a checklist de implementação

Assistentes podem reutilizar a checklist através dos exports JSON ou CSV abaixo.

• Descarregar a folha de cálculo de auditoria do parque (CSV)
• Descarregar a folha de cálculo de auditoria do parque (JSON)

📖 Glossário

• ARI (ACME Renewal Information): extensão do ACME normalizada pela RFC 9773, com o estatuto de Proposed Standard. É uma extensão, não uma revisão do ACME: não torna obsoleta nem atualiza a RFC 8555.
• DCV (Domain Control Validation): prova de que o requerente controla o domínio. A sua reutilização está limitada a 200 dias desde março de 2026, a 100 dias em 2027 e a 10 dias em 2029: é este contador, e não a validade, que desce para 10 dias.
• Conjunto exato de identificadores: conjunto estritamente idêntico de nomes cobertos por um certificado. Na Let's Encrypt, serve para reconhecer uma renovação sem ARI; maiúsculas, minúsculas e ordem não têm qualquer efeito, mas acrescentar um único nome faz perder o estatuto de renovação.
• Domínio registado: a parte do domínio comprada a uma entidade de registo, identificada através da Public Suffix List. Todos os subdomínios partilham a mesma quota. A Let's Encrypt nunca usa o termo "eTLD+1".
• Perfil shortlived: perfil de emissão da Let's Encrypt com 160 horas de validade e 25 nomes no máximo, em disponibilidade geral desde 15 de janeiro de 2026. Continua a ser opcional, e os seus certificados ainda hoje contêm uma URL de lista de revogação.
• Endpoint não recarregável: ponto de acesso em que um certificado é emitido automaticamente, mas instalado à mão, por falta de API ou de acesso não interativo. É a unidade de contagem do limiar de compra.

---

Um último controlo antes de sair. O gesto que atravessa este playbook, comparar o certificado realmente servido com aquele que julga ter instalado, tem um terreno onde não tolera nenhuma aproximação: se os seus MX publicam registos TLSA, a rotação verifica-se antes da implementação, nunca depois. O DANE/TLSA Checker resolve os seus registos, valida a cadeia DNSSEC e pode, opcionalmente, confrontar o certificado apresentado pelo servidor SMTP com o que o seu DNS anuncia.

---

📚 Guias de certificados e DNS relacionados

• Ballot SC-085v2: as AC verificam o DNSSEC antes de emitir: o que as autoridades verificam no seu DNS antes de cada validação.
• DANE e TLSA: o guia completo: publicar e fazer rodar os registos TLSA ao ritmo das renovações.
• HSTS e preload: o guia completo: porque é que a margem de manobra é nula quando um site em HSTS vê o seu certificado expirar.

Fontes

1. Let's Encrypt: Rate Limits
2. Let's Encrypt: Certificate Profiles
3. Let's Encrypt: Integration Guide
4. CA/Browser Forum: Baseline Requirements for TLS Server Certificates
5. draft-ietf-acme-dns-account-label: ACME DNS Labeled With ACME Account ID Challenge