Certificados TLS de 47 dias: prazos e o que automatizar

Resposta curta. A votação SC-081 do CA/Browser Forum, aprovada em 11 de abril de 2025, reduz em três etapas a validade máxima dos certificados TLS publicamente confiáveis. Certificados emitidos a partir de 15 de março de 2026 podem durar até 200 dias; a partir de 15 de março de 2027, até 100 dias; e a partir de 15 de março de 2029, até 47 dias. O prazo pelo qual uma CA pode reutilizar uma validação de domínio diminui nas mesmas datas: 200 dias, depois 100 e depois 10. Na prática, todo certificado precisa ser emitido e implantado por automação (ACME). Convém que a renovação siga a janela de ARI da CA, e você precisa de um monitoramento que avise enquanto ainda há tempo de corrigir uma renovação com falha. CAs privadas não são afetadas.

O cronograma

As regras estão nas seções 6.3.2 e 4.2.1 dos Baseline Requirements (versão 2.3.1, outubro de 2026). A votação SC-081v3 foi proposta pela Apple e apoiada pela Sectigo, pelo Google Chrome e pela Mozilla. Ela foi aprovada com 25 votos de CAs a favor, nenhum contra e 5 abstenções, e os quatro fabricantes de navegadores votaram a favor.

Alguns detalhes que importam quando você planeja com base nesses números:

• Os limites são tetos que as CAs aplicam no momento da emissão. Um certificado emitido em 14 de março de 2026 ainda podia ter validade de 398 dias. Nada obriga você a substituí-lo antes que ele expire, mas o substituto terá vida curta.
• A “validade” inclui os dois extremos. Os BR a definem como o período de notBefore até notAfter, inclusive, e recomendam um dia de folga: os certificados não deveriam (“SHOULD NOT”) passar de 199, 99 e 46 dias.
• O limite de reutilização da validação é a mudança maior. Hoje uma CA pode reutilizar por meses a prova de que você controla example.com. A partir de 2029, a prova deve ter no máximo 10 dias, então quase toda emissão precisa de uma nova validação de domínio, e o desafio DNS ou HTTP também precisa ser automatizado.
• Os detalhes da organização em certificados OV e EV (nome da empresa, endereço) podem ser reutilizados por 398 dias, em vez de 825.
• Escopo. Os BR regem os certificados TLS de servidor emitidos por CAs publicamente confiáveis. Certificados da sua própria CA interna, certificados de cliente e certificados S/MIME seguem outras regras ou nenhuma.

O que as CAs emitem hoje

Em 20 de outubro de 2026, os certificados servidos por alguns sites grandes estavam assim. A saída vem do script lifetimes.sh da seção de monitoramento:

letsencrypt.org        Let's Encrypt              2026-09-04  ->  2026-12-03  (90 days)
www.google.com         Google Trust Services      2026-09-28  ->  2026-12-21  (84 days)
github.com             Sectigo Limited            2026-09-01  ->  2026-11-29  (90 days)
www.microsoft.com      Microsoft Corporation      2026-01-22  ->  2027-01-17  (360 days)
www.amazon.com         Amazon                     2026-01-19  ->  2027-01-11  (358 days)
www.digicert.com       DigiCert Inc               2026-10-11  ->  2026-11-26  (47 days)

Dois deles ainda usam certificados de quase um ano, emitidos em janeiro de 2026, pouco antes de o limite de 200 dias entrar em vigor. A DigiCert já serve um certificado de 47 dias no próprio site. O plano publicado pela Let’s Encrypt avança mais rápido do que os BR exigem:

• 13 de maio de 2026: o perfil opcional tlsserver emite certificados de 45 dias.
• 10 de fevereiro de 2027: o perfil padrão classic emite certificados de 64 dias, com período de reutilização de autorizações de 10 dias.
• 16 de fevereiro de 2028: o classic emite certificados de 45 dias, com período de reutilização de autorizações de 7 horas.

O diretório ACME em produção lista os perfis que você já pode solicitar hoje:

"meta": {
  "profiles": {
    "classic": "https://letsencrypt.org/docs/profiles#classic",
    "shortlived": "https://letsencrypt.org/docs/profiles#shortlived",
    "tlsserver": "https://letsencrypt.org/docs/profiles#tlsserver"
  }
},
"renewalInfo": "https://acme-v02.api.letsencrypt.org/acme/renewal-info"

O que automatizar

Com certificados de 398 dias, uma renovação manual por ano era incômoda, mas suportável. Com certificados de 47 dias e reutilização da validação por 10 dias, a renovação manual vira uma tarefa sujeita a erros pelo menos oito vezes por ano para cada nome, e perto de doze se você renovar em dois terços da vida útil. O trabalho se divide em quatro partes.

1. Emissão via ACME. Use um cliente ACME (RFC 8555) para todo certificado de uma CA pública. A maioria das CAs comerciais também oferece endpoints ACME, muitas vezes com vinculação de conta externa (external account binding). Se algum certificado ainda chega por e-mail, por download em um portal ou por um chamado, coloque-o no topo da lista.

2. Validação que roda sem supervisão. Escolha um desafio que funcione sem intervenção humana:

• O http-01 precisa da porta 80 acessível em todo host que serve o nome.
• O dns-01 precisa de acesso à API do seu provedor de DNS. Restrinja o escopo do token aos registros _acme-challenge, quando o provedor permitir.
• O tls-alpn-01 roda inteiramente na porta 443.

Dois métodos mais novos foram escritos exatamente para essa situação. O “DNS Labeled with Account ID”, o desafio ACME dns-account-01 (BR §3.2.2.4.21), permite que várias contas ACME validem o mesmo nome sem disputar um único registro _acme-challenge. O “DNS TXT Record with Persistent Value” (§3.2.2.4.22, votação SC-088) permite publicar uma única vez um registro permanente:

_validation-persist.example.com IN TXT "authority.example; accounturi=https://authority.example/acct/123; persistUntil=1782424856"

A CA pode considerar cada verificação desse registro válida por no máximo 10 dias. Mas é a própria CA que verifica o registro de novo, então ninguém precisa mexer no DNS a cada renovação. Pergunte à sua CA se ela oferece suporte a esse método antes de depender dele.

3. Renovação que segue a CA. Renove cedo e deixe a CA definir o momento:

• Renove em cerca de dois terços da vida útil. Isso corresponde ao dia 30 de um certificado de 45 dias. A Let’s Encrypt afirma que “renovar em um intervalo fixo de 60 dias não será mais suficiente”. Desde a versão 4.0, o certbot renova quando resta um terço da vida útil, e não mais quando restam 30 dias fixos.
• Use o ARI (RFC 9773), tratado na próxima seção. A CA informa a cada cliente quando renovar e pode antecipar essa janela quando precisa revogar certificados em massa.
• Solicite o perfil explicitamente se quiser certificados de 45 dias antes que o padrão da sua CA mude.

4. Implantação em todas as cópias. Renovar o arquivo no disco não encerra o trabalho. Liste todos os lugares para onde um certificado é copiado:

• balanceadores de carga e CDNs que recebem certificados por upload;
• secrets do Kubernetes;
• keystores Java e pacotes PKCS#12;
• appliances, servidores de e-mail, bancos de dados e brokers de mensagens;
• aplicativos móveis que fixam um certificado folha.

Cada cópia precisa de um hook de recarga ou de uma integração que busque o novo certificado. Fixar um certificado folha ou a chave dele em um aplicativo se torna inviável nesse ritmo. Em vez disso, fixe uma chave da CA ou, melhor ainda, não fixe nada.

Este teste roda o certbot 5.8.0 com um servidor ACME Pebble 2.10.1 local, cujo perfil tlsserver emite certificados de 45 dias. Ele mostra que a solicitação do perfil e a configuração de renovação funcionam conforme documentado:

$ certbot certonly --standalone --non-interactive --agree-tos --register-unsafely-without-email \
    --server https://localhost:14000/dir -d app.example.test --preferred-profile tlsserver
Account registered.
Requesting a certificate for app.example.test
Successfully received certificate.
This certificate expires on 2026-12-04.
$ openssl x509 -in /etc/letsencrypt/live/app.example.test/cert.pem -noout -startdate -enddate
notBefore=Oct 20 11:47:52 2026 GMT
notAfter=Dec  4 11:47:51 2026 GMT
$ grep -E "preferred_profile|server" /etc/letsencrypt/renewal/app.example.test.conf
preferred_profile = tlsserver
server = https://localhost:14000/dir
$ certbot renew --non-interactive
Processing /etc/letsencrypt/renewal/app.example.test.conf
Certificate not yet due for renewal

O certbot guarda o perfil na configuração de renovação, então toda renovação posterior volta a solicitá-lo. A flag --preferred-profile existe desde o certbot 4.0. Se o diretório da CA não listar o perfil indicado, o certbot recorre ao perfil padrão da CA. Com --required-profile, a emissão ou a renovação falha nesse caso. Os perfis vêm do draft-ietf-acme-profiles, que aguardava revisão do IESG em outubro de 2026. Outros clientes além do certbot usam nomes próprios para essas flags.

Informações de renovação do ACME (ARI)

O ARI (RFC 9773, junho de 2025) transforma o momento da renovação, antes um palpite do lado do cliente, em uma pergunta à CA. Para cada certificado, o cliente monta um identificador a partir do Authority Key Identifier (identificador da chave da autoridade) e do número de série do certificado:

url = renewalInfo || '/' || base64url(AKI keyIdentifier) || '.' || base64url(Serial)

Em seguida, ele consulta essa URL periodicamente, sem autenticação. A resposta traz uma suggestedWindow (janela sugerida), e um cabeçalho Retry-After indica quando perguntar de novo. Você mesmo pode fazer essa consulta para qualquer certificado da Let’s Encrypt:

#!/bin/bash
set -e
host="$1"
openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out cert.pem
aki=$(openssl x509 -in cert.pem -noout -ext authorityKeyIdentifier | grep -o -E '([0-9A-F]{2}:){19}[0-9A-F]{2}' | tr -d ':')
serial=$(openssl x509 -in cert.pem -noout -serial | cut -d= -f2)
# The DER INTEGER content keeps a leading 00 byte when the high bit is set.
[ $(( 16#${serial:0:1} )) -ge 8 ] && serial="00$serial"
b64url() { python3 -c 'import sys,base64; print(base64.urlsafe_b64encode(bytes.fromhex(sys.stdin.read().strip())).decode().rstrip("="))'; }
id="$(printf %s "$aki" | b64url).$(printf %s "$serial" | b64url)"
ari=$(curl -s https://acme-v02.api.letsencrypt.org/directory | grep -o '"renewalInfo": *"[^"]*"' | cut -d'"' -f4)
openssl x509 -in cert.pem -noout -issuer -startdate -enddate
echo "GET $ari/$id"
curl -s -D - "$ari/$id" | grep -i -E '^retry-after|^\{|"'

issuer=C=US, O=Let's Encrypt, CN=YE2
notBefore=Sep  4 14:34:32 2026 GMT
notAfter=Dec  3 14:34:31 2026 GMT
GET https://acme-v02.api.letsencrypt.org/acme/renewal-info/uVnyjs8i8IbTN0j_dhQYuoLYVYc.BUOTO-OGs6KzrdU08hA7yLZf
retry-after: 25769
{
  "suggestedWindow": {
    "start": "2026-11-02T17:18:36Z",
    "end": "2026-11-04T12:29:25Z"

A janela abre 59 dias após o início deste certificado de 90 dias, em cerca de dois terços da vida útil. Convém que o cliente escolha um momento aleatório dentro da janela, o que distribui as renovações ao longo do tempo. Se a CA precisar revogar certificados em massa, ela move a janela para o passado, e clientes bem-comportados renovam em questão de horas, em vez de falhar quando o certificado expira. Ao renovar, o cliente envia o identificador do certificado antigo no campo replaces do novo pedido (order).

Suporte a ARI nos clientes mais comuns, segundo as notas de versão de cada um:

Monitoramento que detecta uma renovação com falha

A automação falha em silêncio: um token da API de DNS expirado, uma mudança no firewall que bloqueia a porta 80, um hook de recarga que parou de funcionar. Com um certificado de 47 dias renovado no dia 30, você tem cerca de 17 dias entre a primeira renovação com falha e a interrupção do serviço. Dispare o alerta logo no início desse intervalo.

De fora. Verifique todos os nomes públicos, não só os que você lembra. O blackbox exporter do Prometheus expõe a expiração da cadeia servida como probe_ssl_earliest_cert_expiry:

probe_ssl_earliest_cert_expiry 1.795737599e+09
probe_success 1
probe_tls_version_info{version="TLS 1.3"} 1

Estas duas regras de alerta passam no promtool check rules (Prometheus 3.5.0). A primeira dispara quando a renovação está atrasada; a segunda, quando uma interrupção está próxima:

groups:
  - name: certificates
    rules:
      - alert: CertificateRenewalOverdue
        # Fires when less than a third of a 47-day lifetime (about 16 days) is left:
        # the renewal job should have replaced the certificate by now.
        expr: probe_ssl_earliest_cert_expiry - time() < 16 * 86400
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"
      - alert: CertificateExpiresSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 7 * 86400
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "{{ $labels.instance }}: certificate expires in {{ $value | humanizeDuration }}"

Em um script. O comando openssl x509 -checkend N termina com status 1 se o certificado expirar dentro de N segundos, o que basta para um cron job ou uma etapa de CI:

$ openssl x509 -in cert.pem -noout -enddate
notAfter=Nov 26 23:59:59 2026 GMT
$ openssl x509 -in cert.pem -noout -checkend $((30 * 86400)); echo "exit status: $?"
Certificate will not expire
exit status: 0
$ openssl x509 -in cert.pem -noout -checkend $((45 * 86400)); echo "exit status: $?"
Certificate will expire
exit status: 1

A tabela do levantamento no início desta página veio deste script:

#!/bin/bash
for host in "$@"; do
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null | openssl x509 -out /tmp/c.pem 2>/dev/null || { echo "$host: no certificate"; continue; }
  nb=$(openssl x509 -in /tmp/c.pem -noout -startdate | cut -d= -f2)
  na=$(openssl x509 -in /tmp/c.pem -noout -enddate | cut -d= -f2)
  issuer=$(openssl x509 -in /tmp/c.pem -noout -issuer -nameopt multiline | grep -E "organizationName" | head -1 | cut -d= -f2 | sed 's/^ *//')
  days=$(( ($(date -d "$na" +%s) - $(date -d "$nb" +%s) + 1) / 86400 ))
  printf '%-22s %-26s %s  ->  %s  (%s days)\n' "$host" "$issuer" "$(date -u -d "$nb" +%F)" "$(date -u -d "$na" +%F)" "$days"
done

Do lado da CA. Os logs de Certificate Transparency registram todos os certificados emitidos para os seus domínios. Um monitor de CT mostra as renovações que aconteceram e os certificados que você não esperava. Veja Certificate Transparency para desenvolvedores ou consulte o histórico de um domínio com a ferramenta de histórico de CT. Para ver o quanto um conjunto de domínios está preparado, a calculadora de vida útil de certificados aplica o cronograma a cada um dos seus certificados.

CAA e vinculação à conta

Uma reutilização mais curta da validação significa mais validações, e cada uma delas verifica os seus registros CAA. A partir de 15 de março de 2027 (votação SC-098), as CAs também devem respeitar os parâmetros accounturi e validationmethods da RFC 8657. Com eles, você pode restringir a emissão à sua própria conta ACME e ao tipo de desafio escolhido:

example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"

O gerador de registros CAA monta esses registros. Lembre-se de que um registro CAA desatualizado vai bloquear as suas próprias renovações, que agora acontecem pelo menos oito vezes por ano, em vez de uma.

Erros comuns

• Um intervalo fixo de renovação. “Renovar a cada 60 dias” já falha com certificados de 45 dias. Renove com base em uma fração da vida útil ou no ARI.
• Renovar sem recarregar. O arquivo novo fica no disco enquanto o servidor continua servindo o certificado antigo, carregado na memória, até ele expirar. Teste o hook de implantação, não só a renovação.
• Esquecer as cópias. O servidor de origem renova automaticamente, mas a CDN ou o balanceador de carga ainda tem um certificado carregado manualmente.
• Alertar com 7 dias de antecedência. Com certificados de 47 dias, um alerta uma semana antes da expiração não deixa tempo para depurar um problema na API de DNS ou no firewall. Dispare o alerta quando a renovação estiver atrasada.
• Fixar as chaves dos certificados folha em aplicativos móveis ou clientes de API. Toda renovação com uma chave nova quebra esses clientes.
• Supor que a PKI privada precisa acompanhar. Sua CA interna pode manter uma política própria. Vidas úteis curtas continuam sendo uma boa ideia lá, mas são uma escolha sua.

Fontes

• CA/Browser Forum, Baseline Requirements v2.3.1: §1.2.2 (datas relevantes), §3.2.2.4.21–22 (novos métodos de DNS), §4.2.1 (períodos de reutilização), §6.3.2 (validade).
• Votação SC-081v3 (aprovada em 11 de abril de 2025, em vigor desde 16 de maio de 2025).
• RFC 9773: ACME Renewal Information (ARI). RFC 8555: protocolo ACME. draft-ietf-acme-profiles.
• Let’s Encrypt, redução da vida útil dos certificados para 45 dias e perfis.
• Notas de versão do certbot, do Caddy, do lego, do acme.sh e do cert-manager.
• RFC 8659 (CAA) e RFC 8657 (parâmetros accounturi e validationmethods do CAA).

A saída dos comandos foi gerada em 20 de outubro de 2026 em node:24.22.0-trixie (OpenSSL 3.5.7, curl 8.14.1), certbot/certbot:v5.8.0 com ghcr.io/letsencrypt/pebble:2.10.1, quay.io/prometheus/blackbox-exporter:v0.25.0 e prom/prometheus:v3.5.0.