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

⚡TL;DR

• As renovações não consomem a cota da Let's Encrypt de 50 certificados por domínio registrado. Esse limite mede a entrada de novos nomes, não o tamanho de um parque. Acreditar no contrário distorce todo o dimensionamento.
• O que quebra uma renovação de certificado SSL quase nunca é o ACME, e sim os endpoints que nenhum script recarrega: appliances com interface web, keystores com senha interativa, terminações TLS gerenciadas sem API.
• Um inventário se mantém por par (host, porta), não por nome de host. No mesmo endereço IP, ldap.google.com devolve a um cliente padrão dois números de série diferentes nas portas 389 e 636, e um scanner que esquece o SNI registra um terceiro serial, estável e falso.
• ACME, ARI e as seis fases do ciclo de vida são aqui tratados como conhecidos: eles estão 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 em um log: é um certbot renew que roda verde durante semanas enquanto o serviço continua apresentando o certificado antigo. Duas linhas de openssl detectam isso: o número de série lido no disco contra aquele realmente servido na porta. Nada, nos logs do cliente ACME, fará isso por você. As saídas reais estão mais abaixo.

O contexto endurece a mecânica. Em 21 de julho de 2026, um certificado TLS público não pode ultrapassar 200 dias de validade, e o mesmo limite se aplica à reutilização da validação de controle do domínio. Os patamares seguintes caem em março de 2027 e depois em março de 2029, e o segundo desacopla validade e revalidação. O porquê desse calendário está no nosso artigo sobre a redução para 47 dias. Aqui, falamos do como: o que quebra concretamente quando a frequência sobe, e o que se coloca no lugar.

Este playbook é para equipes que gerenciam entre 50 e 1.000 certificados em um parque heterogêneo, sem um time de PKI dedicado. Você vai encontrar comandos executados e suas saídas reais, as armadilhas que os acompanham, e os pontos em que não conseguimos medir nada, ditos como tais. Nenhum comparativo de fornecedores. Um único critério de compra, quantificado, e ele não diz respeito ao número de certificados.

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

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

Na prática, as autoridades certificadoras emitem abaixo disso. O texto recomenda não ultrapassar 199 dias e só proíbe acima de 200, de modo que a margem operacional é adotada por todo mundo. A DigiCert deixou de aceitar pedidos de certificados TLS públicos com validade superior a 199 dias em 24 de fevereiro de 2026, cerca de três semanas antes do prazo. A Sectigo seguiu em 12 de março de 2026: 199 dias de validade para todo certificado TLS emitido ou reemitido, 198 dias de reutilização da DCV.

O que vem depois já está datado. Em 15 de março de 2027, a validade máxima e a reutilização da DCV passam ambas a 100 dias. Em 15 de março de 2029, a validade cai para 47 dias e a reutilização da DCV para 10 dias. Já o SII permanece fixado em 398 dias ao longo de todo o calendário: seu único degrau é o de 15 de março de 2026.

Cuidado com o atalho mais difundido: em 2029, não é a validade que cai para 10 dias, é a reutilização da prova de controle do domínio. Os dois contadores se separam, e é exatamente 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 arrastará consigo uma revalidação completa, porque a prova anterior já terá expirado havia muito tempo. Automatizar a emissão não bastará mais. Será preciso que a validação esteja automatizada permanentemente, ou seja, que as permissões de escrita no DNS ou o acesso à porta 80 estejam disponíveis de forma contínua, e não apenas no dia em que alguém agenda uma mudança.

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

Nenhuma fonte de inventário enxerga 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, a varredura de rede lê o que é servido, e as APIs dos provedores cobrem o que as outras três não veem. É preciso cruzá-las, e sobretudo saber o que cada uma deixa passar.

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

Os logs de Certificate Transparency registram todo certificado emitido por uma autoridade pública para os seus domínios. Eles não dizem nem onde ele está implantado, nem se ainda está em uso. A consulta ingênua cabe em uma linha:

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

No nosso domínio, ela devolveu 12 valores únicos em 54 segundos. Uma execução anterior tinha retornado três HTTP 502 consecutivos antes de completar na quarta tentativa. Nada quebrado no comando: o crt.sh responde assim mesmo.

O que vem a seguir foi encontrado na execução, não deduzido. O -s mascara a falha: o jq recebe HTML e retorna jq: parse error: Invalid numeric literal at line 1, column 7, e sem set -o pipefail o script segue como se nada tivesse acontecido. Os 54 segundos são um tempo de resposta nominal para 142 certificados, não uma limitação de taxa. O %25 codifica o curinga %, 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 padrão: 76 das 142 entradas.

A versão endurecida corrige tudo isso:

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. Duas variantes foram testadas e descartadas, e são elas que mais ensinam. Sem o -o, com saída para o stdout, o curl concatena o corpo do 502 com o do 200 bem-sucedido: 8.342 bytes que começam com <html><head><title>502 Bad Gateway</title> seguidos do JSON válido, e o jq falha. Com o -o, o curl rebobina o arquivo a cada tentativa. E --fail --retry 8 sem --retry-all-errors não repete: o curl 8.7.1 devolve curl: (56), código ausente da lista de erros que o curl repete por padrão. Falha em 0,12 segundo.

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

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

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

Do lado do PEM, openssl x509 -in fullchain.pem -noout -subject -dates -serial basta. Para os outros dois, honestidade em primeiro lugar: não conseguimos executar os comandos correspondentes. Nossa máquina de teste não tem JDK e não roda Windows. Em vez de uma saída inventada, aqui está o registro 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.

Essas duas falhas desmontam, cada uma, um falso positivo de disponibilidade. A máquina expõe de fato 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á nenhum acesso ao repositório de certificados, já que o provedor Certificate é um componente do Windows, ausente da lista de PSProvider. Esse script só se valida no seu alvo.

As armadilhas contam tanto quanto os comandos. O keytool pede a senha de forma interativa, e passá-la com -storepass a expõe no histórico e no ps: prefira -storepass:file. Desde o JDK 9, o formato padrão é PKCS12, não JKS. No Windows, LocalMachine\My exige um console aberto em modo administrador, sem o que 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.

A varredura de rede nunca verá os seus servidores de email

Uma varredura de rede lê o que é realmente servido, o que faz dela a fonte mais confiável. A partir de uma máquina comum ou da maioria das nuvens, ela nunca verá os seus servidores de email: a porta 25 de saída é filtrada ali.

A prova cabe em três linhas, em um único host. smtp.gmail.com resolvia, no momento do teste, para um único endereço, e os servidores de borda do Google giram: qualquer que seja 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 conexão e devolvem o certificado; na porta 25, a conexão expira. A máquina está acessível, o que está bloqueado é a porta. Repetido contra sete MX públicos de seis operadores diferentes, dois no Google, depois Proton, OVH, Riseup, Yandex e GMX, o mesmo comando expira sete vezes em sete.

A porta 25 é filtrada do nosso lado, na saída. A nuance importa, porque a conclusão inversa circula por toda parte. O Google não fecha nada. AWS, GCP, Azure e OVH bloqueiam a porta 25 de saída por padrão, assim como a quase totalidade dos acessos residenciais. Uma varredura de parque disparada de uma máquina desse tipo produz, portanto, um resultado mecanicamente incompleto.

O mesmo sintoma, porém, cobre duas causas distintas, e a segunda não vem da sua rede. Da mesma máquina, pop.gmail.com expira na porta 110 enquanto pop.gmx.net responde nela, e imap.gmx.net responde na 143, com STARTTLS validado, assim como na 993; a 995 passa em todos os casos. As portas em texto claro não estão, portanto, filtradas na saída, ao contrário da 25: são os hosts do Google que descartam esses pacotes sem resposta, porque não servem nem POP3 nem IMAP em texto claro. Política do provedor 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 precisa, portanto, distinguir três estados, não dois: certificado lido, certificado com falha e host não alcançado. Um "inacessível" contado como um "nada a relatar" é o pior resultado possível, porque o painel continua verde sobre serviços que nunca foram medidos. E a questão não é teórica nos MX: se o certificado mudar antes que o registro TLSA correspondente seja publicado, a RFC 7672 proíbe a entrega da mensagem por esse servidor e obriga o remetente a passar para o MX seguinte ou a adiar a entrega.

Nossas próprias ferramentas caem sob o mesmo limite: o monitor de uptime da CaptainDNS só aceita os esquemas HTTP e HTTPS. SMTP, IMAPS e LDAPS ficam fora do seu escopo.

As APIs dos provedores enxergam o que as outras três fontes vinculam mal

Resta a quarta fonte, a menos espetacular: as APIs dos provedores. AWS Certificate Manager, Cloudflare ou uma CDN que termina o TLS por você mantêm certificados que nada mais consegue vincular corretamente ao seu parque. Os logs de transparência os veem sem dizer quem os opera, o disco não os contém, e a varredura de rede os atribui à infraestrutura do provedor em vez de ao seu serviço. A API é o único lugar onde essas terminações gerenciadas existem com sua data de expiração e seu modo de renovação.

Seu ponto cego é simétrico: cada API só cobre o que vive naquele provedor, e pressupõe permissões de leitura que a equipe que inventaria nem sempre tem. Três provedores significam três consultas, três conjuntos de credenciais e três formatos de resposta a reconciliar.

Um inventário se indexa 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 padrão lê ali 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 do Google, CN=invalid2.invalid com OU=No SNI provided - please fix your client., número B3E9BADC: um scanner sem SNI registra um valor perfeitamente estável e perfeitamente falso, sempre sem erro.

A porta em si, porém, não é a causa da diferença entre 389 e 636. O listener da 389 detém os dois certificados e decide conforme os algoritmos de assinatura que o cliente anuncia:

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, sob demanda, o certificado que se acreditava exclusivo da 636. O inverso falha: ECDSA+SHA256 forçado na 636 dispara 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 tanto quanto a porta: dois scanners com algoritmos de assinatura diferentes inventariam dois números de série diferentes no mesmo par, sem levantar o menor erro. Congele e documente a configuração TLS do scanner, senão o inventário não é reproduzível de uma execução para outra.

Em outros lugares, o comportamento se inverte: no Gmail, as portas 465 e 587 servem o mesmo certificado, 6D09D839.... Nada disso se adivinha, e um inventário indexado pelo nome de host conta errado nos dois sentidos: ele funde certificados distintos ou duplica o mesmo.

A planilha de auditoria disponível para download no fim do artigo traz essas colunas: uma linha por par (host, porta), o modo TLS, o estado da última varredura com seus três valores possíveis, o método de implantação, o de recarregamento, o responsável nomeado e a classe de automação. Três linhas de exemplo mostram o preenchimento esperado, o restante está em branco.

Delegar _acme-challenge sem entregar as chaves da zona

Delegar _acme-challenge por CNAME dá ao cliente ACME uma permissão de escrita sobre uma zona de validação dedicada, e nada mais. Sua zona de produção não se mexe: mesmos registros, mesma API fechada.

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

A RFC 8555 não menciona o CNAME. A palavra não aparece em lugar nenhum do seu texto, verificação feita. A delegação não é, portanto, uma recomendação do padrão ACME: ela é documentada e suportada pela Let's Encrypt, cuja validação DNS-01 segue as regras DNS ordinárias e aceita que um CNAME ou uma delegação NS encaminhe a resposta ao desafio para outra zona. Do lado normativo, os Baseline Requirements citam explicitamente o registro CNAME entre os suportes válidos do método de validação "DNS Change", na seção 3.2.2.4.7.

A distinção cabe em uma linha: suportada pelo ecossistema, ausente do padrão.

O benefício, esse, é claro. O cliente ACME recebe credenciais que só escrevem em uma zona de validação, muitas vezes hospedada em outro lugar. O comprometimento do servidor que renova não dá, então, nenhum poder sobre os seus registros MX, A ou TXT de produção. Varrendo 32 domínios públicos, encontramos várias delegações reais desse tipo: fastmail.com aponta para fastmail.com.acme-challenge.fmhosted.com, github.com para github.com.acme.github.net, reddit.com para um alvo 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 é a 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 esse comando diz: um CNAME está escrito. Ele não prova que a delegação funciona.

Etapa 2, seguir a cadeia até o 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 seção ANSWER com um NXDOMAIN significa que a delegação está escrita mas que o alvo não existe neste instante, porque o TXT só é criado no momento do challenge. Esse é o estado normal entre duas renovações: das sete delegações públicas que consultamos, seis estavam nessa situação. A falha de verdade é um NOERROR com ANSWER: 0, ou seja, nenhuma delegação. Um monitoramento que alerta sobre o NXDOMAIN de _acme-challenge produzirá ruído permanente, e vai errar seis vezes em sete.

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

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 enquanto a consulta TXT em _acme-challenge.github.com devolvia NXDOMAIN: a delegação está saudável, apenas a resposta ao desafio está ausente por não haver renovação em curso. Um SOA em NXDOMAIN ou em SERVFAIL na zona de destino, ao contrário, sinaliza uma delegação quebrada de vez, tipicamente uma conta de validação excluída ou um domínio expirado.

O nome começa com um underscore, que algumas interfaces de administração engolem ou prefixam em dobro: verifique o FQDN devolvido na resposta DNS, não o que o painel exibe; uma consulta CNAME na ferramenta DNS Lookup mostra isso sem abrir um terminal. Um CNAME em _acme-challenge é incompatível com qualquer outro registro sob o mesmo nome, de modo que um TXT de validação antigo esquecido ali deixa a zona inválida. Os TTL observados vão de 3600 a 120 segundos conforme o domínio: depois de uma correção, um resolvedor pode servir a resposta antiga, NXDOMAIN incluído, durante todo esse tempo, e essa é a causa número um das falhas de validação logo após uma mudança. O head -1 só testa um servidor autoritativo. Por fim, consultar a zona de destino não prova que o cliente tem permissão de escrita nela: só uma emissão real prova isso.

O limite de um único delegatário por domínio, e o draft que o remove

O DNS só autoriza um CNAME por nome. _acme-challenge.captaindns.com só pode, portanto, ser delegado a um único cliente por vez. Multi-CDN, multirregião, migração sem interrupção, certificado reserva emitido por uma segunda autoridade: essas quatro necessidades esbarram todas no mesmo muro, e não existe nenhuma solução limpa do lado do DNS.

Um rascunho em andamento 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 último chamado 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. Ele não tem número de RFC, seu conteúdo pode mudar na próxima revisão, e não anunciamos nenhuma disponibilidade em autoridade certificadora alguma. Vale acompanhar se a sua arquitetura é multiprovedor, mas não colocar em um plano de implantação.

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

O certbot renew escreve o novo certificado no disco. Ele não recarrega nem o nginx, nem o postfix, nem o haproxy. Entre o momento em que a emissão dá certo e aquele em que o serviço apresenta o novo certificado, existe um recarregamento, e é aí que a cadeia mais quebra, sem que nenhum log acenda. A defesa do lado do cliente se chama deploy hook, e o guia de gestão do ciclo de vida dos certificados lhe dedica sua fase 3; a verificação que vem a seguir confere, de fora, que ele realmente funcionou.

A verificação pós-renovação, e seus cinco falsos positivos

A única verificação que conta compara o número de série lido no disco com aquele 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 de fato 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

Essa verificação tem suas armadilhas, e a primeira é boba. O cut -d= -f2 não é decorativo: o openssl exibe serial=05DF... e a comparação falha sem ele. Compare o número de série, nunca a data de expiração: dois certificados renovados no mesmo dia podem compartilhar o notAfter. O arquivo fullchain.pem contém vários certificados e o openssl x509 -in só lê o primeiro, de modo que um arquivo ordenado ao contrário faz comparar o intermediário e reprova o teste permanentemente. Atrás de um balanceador de carga que termina o TLS, o certificado depositado no disco da origem não tem nenhuma relação com o que é servido ao público: a verificação vira um falso positivo permanente, e é preciso mirá-la de fora do balanceador. Por fim, para identificar o arquivo em vez da emissão, troque -serial por -fingerprint -sha256.

Essa verificação não tem nada de específico à porta 443. Nós a repetimos fora da web: em TLS implícito na porta 465, depois em STARTTLS na porta 587, com o mesmo número de série 6D09D839... dos dois lados. Um parque de email se verifica exatamente da mesma forma, a não ser pela opção de conexão.

A impressão digital SPKI SHA-256 oferece uma verificação complementar, a montante. Ela é exposta tanto pelo nosso SSL Certificate Checker quanto pelo CSR Parser, o que permite provar que um determinado CSR de fato produziu o certificado servido. O cruzamento é manual: nada o faz automaticamente por você.

Todos os seus servidores de borda servem o mesmo certificado?

Um laço sobre os endereços IP do serviço responde à pergunta em alguns 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 desse lado. O cerne do truque está no -servername colocado embora a conexão seja com um IP: sem ele, você recupera o certificado padrão do servidor de borda, não o do vhost visado. O grep -E '^[0-9]' filtra as linhas de CNAME que o dig +short intercala, comportamento observado em www.google.com por causa de uma reescrita do resolvedor local.

O laço 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), esses quatro endereços pertencem ao mesmo ponto de presença visto da sua máquina: você o testa quatro vezes, e não os N outros espalhados pelo mundo.

Diagnosticar uma porta mal identificada em uma linha de erro

Não é preciso adivinhar o modo de uma porta: o openssl o diz na sua mensagem de erro. Um wrong version number significa que falta o -starttls: o servidor espera um diálogo em texto claro antes da negociação. Ao contrário, um Didn't find STARTTLS in server response, trying anyway... seguido de um unexpected eof while reading significa que o -starttls está sobrando, em uma porta já cifrada: o openssl tenta assim mesmo, espera um banner em texto claro de um servidor que só espera TLS, e a conexão morre em um EOF.

O comando equivalente em um MX na porta 25 se escreve 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 da nossa máquina, porta 25 de saída filtrada; sintaxe validada de forma idêntica na 587. Não publicamos, portanto, nenhuma saída para este. Três armadilhas merecem ainda assim ser sinalizadas: o 2>/dev/null engole o erro real e deixa você 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 levar o nome do MX, não o do domínio de email.

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 registros TLSA. Ali, a ordem das operações deixa de ser uma boa prática para virar uma obrigação. A RFC 7671, seção 8.1, descreve a rotação em quatro tempos: publicar o registro TLSA do futuro certificado ao lado do registro do certificado atual, esperar pelo menos dois TTL para que os caches se esvaziem, implantar então o novo certificado e verificar que ele funciona, e por fim retirar o registro que ficou obsoleto. Dois TTL, não 48 horas: a RFC raciocina em TTL, e os seus TTL não são os nossos.

Para o SMTP, a RFC 7672 faz disso uma obrigação formal. Em caso de dessincronização, a entrega fica proibida por esse servidor, 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 conexão é abortada pelo cliente, os remetentes que não validam DANE continuam entregando, o monitoramento segue verde. A RFC 7672 emprega a palavra "unwittingly" para descrever esse domínio parceiro que se vê mal configurado sem saber. Do lado do remetente que valida, não é silencioso, mas adiado: as mensagens se acumulam na fila, com avisos de atraso e depois eventuais bounces no vencimento. O destinatário final, esse, não recebe nem a mensagem nem a menor notificação.

Resta uma condição que a seção 8.1 estabelece sem destacar: o uso, o seletor e o tipo de correspondência devem permanecer inalterados. Se você modificar um desses três parâmetros, é a seção 8.3 que se aplica, e a regra se inverte.

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 sabe emitir para quase tudo. O que trava é 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, então nada as pressiona a encurtar nem a automatizar. A instância pública de demonstração do FreeIPA mostra isso bem: na coleta 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, em uma cadeia assinada por uma raiz privada.

Visto de uma máquina externa, o openssl retorna verify error:num=19 self-signed certificate in certificate chain. Esse código costuma ser confundido com outro: verify error:num=20 unable to get local issuer certificate. Eles não descrevem a mesma situação. O 19 significa que o servidor envia sim a sua raiz privada na cadeia, mas que ela está ausente do seu repositório local. O 20 significa que o intermediário não é enviado de forma alguma 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 esses parques de volta ao ACME. Nenhuma se implanta sem contrapartida, e é melhor conhecê-la antes.

• acme2certifier, sob licença GPLv3, coloca uma fachada ACME diante do Microsoft ADCS via MS-WCCE ou os Certificate Enrollment Web Services. A revogação não é suportada e a cadeia da autoridade precisa ser carregada à mão. É um projeto comunitário tocado por um mantenedor, ativo: versão 0.44 em 18 de julho de 2026.
• step-ca é um ponto único de falha na sua configuração padrão, por causa do seu banco embarcado Badger, que não lida com concorrência. A documentação descreve uma implantação multi-instância, ao preço de um banco MySQL ou PostgreSQL externo e da gestão remota dos provisioners.
• 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 em uma arquitetura.
• EJBCA Community Edition: a Keyfactor escreve isso ela mesma no README do repositório oficial, "EJBCA Community Edition is not intended for production use."

Os certificados que o ACME não consegue entregar

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

O caso aparece em produção. Na mesma coleta, 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, ainda assim, nenhuma 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 desse operador.

O campo se estreita ainda mais. Os certificados de marca VMC e CMC, usados pelo BIMI, são decodificados pelo nosso analisador dedicado mas não são certificados TLS de servidor. Já os certificados de cliente, em especial os que fazem 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 que vem a seguir.

Os appliances de rede administráveis apenas por interface web. Os balanceadores de carga em hardware, cuja atualização de certificado passa por um formulário. As impressoras, os equipamentos industriais, as câmeras e tudo o que embarca um servidor HTTPS esquecido desde a instalação. Os keystores Java protegidos por uma senha interativa, que travam de imediato qualquer execução não supervisionada. Os repositórios do Windows, onde instalar um certificado não basta, já que um binding do IIS pode continuar apontando para outra impressão digital. As terminações TLS gerenciadas em um provedor que não expõe nenhuma API.

O ponto comum não é a emissão: o ACME sabe emitir para todos esses nomes. É a instalação e o recarregamento que continuam manuais. Um script pode obter o certificado em alguns segundos, e depois esperar que um humano acesse uma interface para instalá-lo. Com 200 dias de validade, esse humano intervém duas vezes por ano e ninguém reclama. Com 47 dias, ele intervém oito vezes por ano e por endpoint no mínimo absoluto, renovando no vencimento, e onze a doze vezes renovando aos dois terços, como recomendado. O custo vira uma linha de orçamento.

Meça isso agora, enquanto a frequência ainda está baixa: número de endpoints envolvidos, minutos realmente gastos por rotação, responsável nomeado. Essas três colunas valem por todos os comparativos de ferramentas.

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

Um ciclo de renovação não é limitado pelo tamanho do parque. Ele é limitado pela cadência com que cada nome reemite, 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 vencimento 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: para esses, a renovação é recomendada na metade da vida.

O perfil shortlived cai exatamente na exceção. Ele vale 160 horas, ou seja, 6,67 dias. Sua metade de vida fica, portanto, em 80 horas, o que dá 2,1 emissões por semana e por nome.

Esse 2,1 é um modelo, não um valor publicado pela Let's Encrypt. Suas cinco hipóteses, de forma clara. A validade de 160 horas é documentada. A semana reduzida a 168 horas fixas é uma aproximação: o mecanismo real é um balde de tokens com recarga contínua. A renovação em uma fração fixa e determinística, sem jitter nem nova tentativa, é uma hipótese de modelagem. Um certificado igual a um nome, ao passo que o shortlived aceita até 25 nomes: agrupar divide o número de certificados na mesma proporção. E o cálculo pressupõe zero falha.

Ressalva mais importante: com o ARI, que é o modo nominal, a cadência não segue uma fração fixa e sim a janela sugerida pelo servidor, cuja posição e largura não são publicadas. Toda cadência em fração de 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 por aí, isso divide uma cota que as renovações não consomem por uma cadência que não se aplica a esse perfil: não repetimos esse número.

O que a Let's Encrypt chama de renovação

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

Via ARI, o comando newOrder designa explicitamente o certificado que ele substitui. Três condições, na verdade: essa designação, ao menos um identificador em comum com o certificado que sai, e um certificado que sai que ainda não tenha sido substituído uma primeira vez. A isenção é então total. Todos os limites de taxa caem, sem exceção, e o escopo dos SAN pode até mudar, já que a identidade do certificado que sai é carregada pelo campo dedicado.

Via detecção por conjunto exato, o regime é mais estreito. O conjunto de identificadores deve 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 pregado na parede: ampliar um certificado SAN para acrescentar um subdomínio consome a cota dos 50 por domínio registrado, ao passo que a renovação idêntica não consome nenhuma. Escrever "50 certificados por semana por domínio" sem essa precisão equivale a descrever um teto de parque que não existe. Esse limite mede uma vazão de entrada de novos nomes.

Os limites que mordem, por ordem de periculosidade

Cinco limites de taxa precisam ser conhecidos, e eles não se equivalem. Ei-los do mais perigoso ao menos incômodo.

O primeiro é o único que um ciclo legítimo pode esgotar sozinho: 5 falhas de autorização por identificador, por conta e por hora, recarga de uma falha a cada 12 minutos, nenhum aumento possível, e sobretudo aplicação às renovações. O segundo conta as falhas consecutivas e coloca o identificador em pausa ao fim de 1.152 falhas seguidas. É um contador de sequência, não uma vazão, e ele recarrega um token por identificador e por dia: um dia com cinco falhas só consome quatro em termos líquidos, e a pausa só ocorre ao fim de 288 dias; a 120 falhas por dia, ela cai ao fim de 10 dias, e com uma só por dia, nunca. Esses valores não saem de um cálculo caseiro, a documentação da Let's Encrypt publica a tabela. Não funda os dois limites.

Vem em seguida 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, nenhum aumento. Uma cadência de 2,1 passa confortavelmente, 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 sua própria conta em vez de compartilhar uma. O último nem sequer é uma cota, e sim uma restrição de perfil: o shortlived limita-se 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 dizem respeito a um ciclo de renovação

Valores documentados na página oficial de rate limits, consultada em 21 de julho de 2026. Essas isenções e esses tetos são próprios da Let's Encrypt e não se generalizam para as outras autoridades certificadoras.

5

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

Recarga de uma falha a cada 12 minutos, nenhum 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, nenhum aumento possível.

50

Novos certificados por domínio registrado a cada 7 dias

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

1152

Falhas consecutivas antes da pausa do identificador

Contador de sequência zerado assim que uma validação é concluída, saída pelo portal de autoatendimento.

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 cota diz respeito apenas a dois limites, leva algumas semanas para ser processado e nunca zera um contador: ferramenta de planejamento, não 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 e sim uma vazão, o FinalizeOrder limitado a uma requisição por segundo, e essas cotas estão documentadas no guia do usuário.

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

Os incidentes de renovação que vemos não se parecem com uma cota de emissão estourada. Eles se parecem com estes dois cenários, que compartilham uma característica desagradável: eles se agravam sozinhos.

Cenário 1, o ciclo de falha. Uma credencial DNS expira, uma delegação quebra, a porta 80 se fecha depois de uma mudança de regra de rede. O cliente ACME tenta de novo, muitas vezes de forma agressiva porque esse é o ajuste padrão de muitas configurações. Na sexta falha dentro da hora sobre o mesmo identificador, todo comando que carregue esse nome é recusado, e a recarga cai para uma falha a cada 12 minutos. Um incidente resolvível em dez minutos vira uma pane de várias horas, não por causa do problema de origem, mas por causa do comportamento do cliente diante do problema. E o contador de falhas consecutivas sobe nesse meio-tempo rumo às 1.152 do segundo limite. A defesa cabe em 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 ser uma. Sem ARI, acrescentar ou retirar um único nome de um certificado SAN faz com que ele perca seu status de renovação e joga o comando de volta na cota dos nomes novos. Ora, muitos parques geram seus conjuntos de SAN a partir de um inventário dinâmico: controlador de ingress do Kubernetes, ambientes efêmeros, plataformas de preview. Nenhum comando é mais uma renovação, e um parque estável passa a consumir a vazão reservada aos nomes novos.

O que torna esse segundo cenário real é o estado dos clientes em 21 de julho de 2026. O Certbot lê o ARI mas não envia o campo replaces: sua implementação continua somente leitura, então todos os seus comandos se apoiam na detecçã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 mudaram. O cert-manager sabe enviá-lo, atrás do feature gate ACMEUseARI, classificado como Alpha e desativado por padrão, disponível desde a v1.21.0 lançada em 8 de julho de 2026. O acme.sh o envia desde a versão 3.1.4, lançada em 17 de julho de 2026, ou seja, quatro dias antes de verificarmos este ponto. A proteção existe na norma desde junho de 2025. Ela é efetiva em quase lugar nenhum.

Monitoramento da expiração dos certificados SSL: duas coisas a monitorar, não uma

O monitoramento da expiração e o 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 mesmo dia. Um parque corretamente instrumentado tem os dois, e eles não dependem do mesmo componente.

Limiares que não sobrevivem aos certificados curtos

Um limiar de alerta fixado em 30 dias fica absurdo em um certificado de 47 dias. Ele dispara já no 17º dia de vida do certificado, ou seja, durante mais da metade da sua existência. O alerta é permanente, portanto invisível, portanto inútil. O limiar precisa virar relativo ao tempo de vida: uma fração, não uma constante.

Vale aplicar essa 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. Em um parque com perfil curto, esses valores precisam ser recalculados por você.

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 sinaliza uma renovação efetiva, ou seja, uma boa notícia que mesmo assim precisa ser vista.
• 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 não corresponde mais aparece depois de uma migração.
• Um protocolo ou uma chave que ficaram fracos indicam uma configuração que regrediu.
• E sobretudo, a falha de validação ACME: o único sinal que chega cedo o bastante para evitar a pane.

Em compensação, dois reflexos só produzem ruído. Nunca alertar sobre um NXDOMAIN de _acme-challenge, pela razão exposta acima. E não alertar sobre 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 servidor de borda.

Nossos limites, ditos com franqueza, porque eles mudam a forma de ler os parágrafos anteriores. A nota de postura é um opt-in pago por monitor. Sua cadência padrão é de 86.400 segundos, ou seja, uma passagem por dia: falar em "monitoramento contínuo" seria falso. Não há nenhuma descoberta de parque, nenhuma enumeração via logs de transparência: você monitora o que declara, uma URL por vez. E não há nenhum STARTTLS, portanto nada sobre os seus servidores de email.

A partir de quando é preciso pagar por uma ferramenta?

O limiar de compra não se conta em certificados. Ele se conta em endpoints que nenhum script consegue recarregar. Um parque de 800 certificados inteiramente pilotados por um controlador de ingress não justifica nenhuma despesa; um parque de 60 certificados dos quais 25 vivem em appliances com interface web a justifica na hora.

Classifique o seu parque em três colunas, 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 arquivo	Instalação ou recarregamento manual, muitas vezes por um console
Não automatizável	Somente a emissão	Login em uma interface web, importação do arquivo, reinício

O ponto de virada se lê na terceira linha, multiplicada pela frequência que vem. 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 vencimento, e onze a doze renovando 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 ao preço de uma licença: o cálculo não exige nem benchmark nem licitação.

O modelo de limiar fornecido no fim do artigo torna essas 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 traz o seu status, documentado, derivado ou coletado em uma data, de modo que substituir as nossas hipóteses pelas suas leva um minuto.

Falando nisso, os preços. Na AWS Marketplace, coleta de 21 de julho de 2026, a ficha AppViewX AVX ONE CLM exibe dois patamares públicos em contrato de um mês: US$ 2.100 por mês para 100 certificados de servidor e US$ 4.200 por mês para 250 certificados de servidor. O mesmo fornecedor publica US$ 5.000 e US$ 9.100 por mês na sua ficha PKIaaS, o que impede apresentar os US$ 2.100 como "o" preço público do fornecedor. A ficha Venafi Certificate Management Service não traz nenhum preço e remete a uma oferta privada sob orçamento. A ficha DigiCert exibe um valor de US$ 5.000 para um contrato de doze meses, deixando claro que é reservada às compras sob oferta privada. Essa coleta se refere às fichas consultadas naquele dia, em um único marketplace, e à noção de preço publicamente contratável. Ela nada diz sobre tarifas negociadas, nem sobre fornecedores ausentes dessa coleta.

Uma palavra sobre o mercado, formulada como constatação de ausência. Nenhum Magic Quadrant dedicado à gestão do ciclo de vida dos certificados está referenciado em gartner.com: a consultoria trata o tema por um "Buyers' Guide for PKI and Certificate Life Cycle Management" publicado em 29 de maio de 2025 e por um espaço de avaliações de usuários, o Peer Insights. Quanto aos números que circulam nos argumentos de venda, eles são atribuíveis e nada mais: em um comunicado de 2 de julho de 2025, a DigiCert indica que 45% dos respondentes da sua pesquisa "Trust Pulse" declaram ter sofrido uma interrupção de serviço ligada a um incidente de certificado, e que 31% relatam perdas entre 50.000 e 250.000 dólares. O comunicado não especifica o número de respondentes, nem o perfil deles, nem os países cobertos, nem o período de coleta, e não encontramos nenhum relatório detalhando essa metodologia naquela data. São declarações de respondentes de uma pesquisa encomendada por um ator da categoria, não uma medição.

Guarde 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, nesta ordem. As três primeiras são feitas uma vez; as seguintes viram reflexos de operação.

1. Inventariar por par (host, porta), cruzando os logs de transparência, o disco e os repositórios, e depois a varredura de rede. Dispare essa varredura de uma rede que não filtre as portas de saída, senão os seus servidores de email nunca vão aparecer.
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, depois verificar a delegação em três etapas: o CNAME existe, a cadeia se resolve, a zona de destino responde em SOA. E não alertar sobre 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, inclusive fora da 443. É a verificação que pega o recarregamento esquecido, e ela custa duas linhas de script.
5. Colocar um backoff exponencial no cliente e alertar sobre a falha de validação. Sem isso, um incidente de dez minutos vira um bloqueio de uma hora.
6. Verificar se o seu cliente envia replaces, ou aceitar depender da detecçã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 querem dizer nada em um 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 arquivos para baixar, e um único número a produzir: a quantidade de endpoints que ninguém sabe recarregar. É ele que decide o que vem depois, não o tamanho do parque.

FAQ

É possível renovar automaticamente um certificado SSL?

Sim, e esse é 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 ainda seguir a janela sugerida pela autoridade, mas seu suporte do lado do cliente continua desigual em 21 de julho de 2026. O Certbot a lê sem enviar o campo replaces, o cert-manager a mantém atrás de um feature gate desativado por padrão, o acme.sh a implementou na versão 3.1.4 em 17 de julho de 2026.

Como automatizar a renovação dos certificados SSL?

Três blocos bastam. 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 renova. E uma verificação que compara o número de série lido no disco com aquele realmente servido na porta em questão. O terceiro bloco é o que se esquece, e é ele que detecta o recarregamento faltante.

Como renovar um certificado SSL?

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

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

Deixe o cliente ACME fazer a emissão, depois verifique o resultado pela rede em vez de pelos logs do cliente. O comando útil compara openssl x509 -in fullchain.pem -noout -serial com o número de série retornado por openssl s_client no serviço. Se os dois divergirem, 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?

Em um serviço web, a expiração aparece imediatamente: os navegadores bloqueiam. Em um servidor de email protegido por DANE, é mais traiçoeiro. A RFC 7672 proíbe a entrega por um servidor cuja autenticação falha, e o remetente passa para o MX seguinte ou adia a entrega: do seu lado, nenhum alerta. Comece então o diagnóstico por uma leitura do certificado realmente servido na porta em questão, não pelos seus logs de aplicação.

Quantos certificados Let's Encrypt posso renovar por semana?

A pergunta parte de uma ideia falsa, a mais difundida do assunto. As renovações estão isentas do limite dos 50 certificados por domínio registrado e por período de 7 dias: esse limite mede a entrada de nomes novos. Uma renovação pilotada por ARI escapa até de 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, das quais nenhuma é 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. A varredura de rede lê o que é efetivamente apresentado, mas perde tudo o que o seu firewall de saída filtra, a começar pela porta 25. As APIs dos seus provedores cobrem as terminações TLS gerenciadas. 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 hospedado em uma zona de validação dedicada, 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 retorna 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ê remover o limite de um único delegatário por domínio, mas ainda não é uma norma.

A partir de quantos endpoints é preciso comprar uma ferramenta?

Não existe limiar universal, e muito menos limiar expresso em número de certificados. Conte os endpoints que nenhum script consegue recarregar, multiplique pelo número de rotações anuais que virão (oito no mínimo absoluto no regime de 47 dias, onze a doze renovando aos dois terços) e pelos minutos gastos em cada um. Compare o total ao custo de uma licença: na AWS Marketplace, na última coleta, a ficha AppViewX AVX ONE CLM exibe US$ 2.100 por mês para 100 certificados de servidor. Escreva as hipóteses do seu cálculo, elas contam tanto quanto o resultado.

Baixe as tabelas comparativas

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

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

Baixe a checklist de implementação

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

• Baixar a planilha de auditoria do parque (CSV)
• Baixar a planilha de auditoria do parque (JSON)

📖 Glossário

• ARI (ACME Renewal Information): extensão do ACME normalizada pela RFC 9773, de status Proposed Standard. É uma extensão, não uma revisão do ACME: ela não torna obsoleta nem atualiza a RFC 8555.
• DCV (Domain Control Validation): prova de que o solicitante controla o domínio. Sua reutilização está limitada a 200 dias desde março de 2026, 100 dias em 2027 e 10 dias em 2029: é esse contador, e não a validade, que cai para 10 dias.
• Conjunto exato de identificadores: conjunto estritamente idêntico de nomes cobertos por um certificado. Na Let's Encrypt, ele serve para reconhecer uma renovação sem ARI; o uso de maiúsculas e minúsculas e a ordem não têm efeito algum, mas acrescentar um único nome faz perder o status de renovação.
• Domínio registrado: a parte do domínio comprada junto a um registrador, identificada via a Public Suffix List. Todos os subdomínios compartilham a mesma cota. A Let's Encrypt nunca emprega 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. Ele continua opcional, e 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.

---

Uma última verificação antes de sair. O gesto que atravessa este playbook, comparar o certificado realmente servido com aquele que você acha que implantou, tem um terreno em que não tolera nenhuma aproximação: se os seus MX publicam registros TLSA, a rotação se verifica antes da implantação, nunca depois. O DANE/TLSA Checker resolve os seus registros, 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 conferem no seu DNS antes de cada validação.
• DANE e TLSA: o guia completo: publicar e rotacionar os registros TLSA no ritmo das renovações.
• HSTS e preload: o guia completo: por que a margem de manobra é nula quando um site em HSTS vê 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