SC-081: por que certificados TLS vão durar só 47 dias até 2029

Em abril de 2025 o CA/Browser Forum aprovou, por 25 votos a 0, a ballot SC-081v3 — proposta originalmente pela Apple. Na prática, ela reescreve as TLS Baseline Requirements para reduzir, em fases, a validade máxima de certificados TLS publicamente confiáveis de 398 dias para apenas 47 dias até março de 2029.

Isso não é um ajuste cosmético. É uma mudança estrutural em como qualquer time que opera infraestrutura com TLS — sysadmins, DevOps, SRE, segurança — precisa pensar sobre o ciclo de vida de certificados.

O cronograma completo

O SC-081v3 reduz dois números em paralelo: a validade máxima do certificado e o período em que evidências de validação de domínio (DCV) podem ser reaproveitadas entre emissões.

O número final — 47 dias — não foi escolhido ao acaso: ele corresponde a um ciclo de renovação de 30 dias com um buffer de 17 dias para lidar com falhas antes da expiração de fato.

O corte no reuso de DCV é, para muitas operações, o detalhe mais disruptivo. Hoje é comum validar um domínio uma vez e reemitir certificados por até 398 dias sem repetir a validação. Na Fase 3, cada renovação vai exigir uma nova validação de domínio — o que só é operacionalmente viável com automação de ponta a ponta (tipicamente via ACME).

Por que o CA/Browser Forum fez isso

Três motivações concretas sustentam o SC-081:

• Janela de exposição menor em caso de comprometimento de chave. Uma chave privada vazada com um certificado de 398 dias fica útil para um atacante por até 398 dias, mesmo com revogação — porque a revogação via CRL/OCSP é notoriamente pouco confiável na prática (clientes fazem soft-fail, caches ficam desatualizados). Um certificado de 47 dias limita esse dano por construção, independente de revogação funcionar ou não.
• Menor dependência de revogação. Se o certificado expira rápido por padrão, o ecossistema depende menos de checagem de revogação em tempo real — historicamente um dos pontos mais frágeis do modelo de confiança TLS.
• Precedente já validado em escala. A Let's Encrypt provou, com certificados de 90 dias emitidos via ACME, que automação total é viável em produção para milhões de domínios. O SC-081 estende essa lógica para todo o ecossistema público.

Escopo: o que fica de fora

As TLS Baseline Requirements — e portanto o SC-081 — só regem certificados destinados a autenticar servidores acessíveis pela internet pública. PKI interna (certificados para uso exclusivamente dentro da rede corporativa, emitidos por uma CA privada) está fora do escopo formal.

Isso não significa que times internos devam ignorar a tendência: a mesma lógica de automação que o SC-081 força para certificados públicos é, cada vez mais, considerada boa prática para PKI interna também.

O impacto operacional é matemático

Compare o número de eventos de renovação por certificado, por ano, em cada fase:

• Hoje (398 dias): ~1 renovação/ano
• Fase 1 (200 dias): ~2 renovações/ano
• Fase 2 (100 dias): ~3-4 renovações/ano
• Fase 3 (47 dias): ~8 renovações/ano

Multiplique isso pelo número real de certificados em produção — incluindo os que ninguém lembra que existem, emitidos por um time que já rotacionou, apontando para um load balancer que ninguém documentou. Gestão manual de certificados, que já era frágil com um evento de renovação por ano, se torna estatisticamente insustentável em oito.

Como se preparar antes da Fase 1 (15/03/2026)

1. Descoberta primeiro. Você não pode automatizar a renovação de um certificado que não sabe que existe. Mapeie certificados em toda a infraestrutura — cloud, on-premise, Certificate Transparency Logs — antes de desenhar qualquer fluxo de automação.
2. Padronize em ACME onde possível. É o protocolo que a maioria das CAs públicas já suporta para emissão e renovação automatizada, e é o único caminho realista para sustentar renovações de DCV a cada 10 dias na Fase 3.
3. Trate expiração como incidente, não como tarefa de calendário. Alertas de "certificado vence em 30 dias" fazem pouco sentido quando o certificado inteiro dura 47. O monitoramento precisa ser contínuo e acoplado ao pipeline de deploy, não a um lembrete manual.
4. Automatize o deploy, não só a emissão. Renovar um certificado que não é redistribuído automaticamente para todos os pontos onde é consumido (load balancers, CDNs, containers) resolve só metade do problema.

O SC-081 não é uma ameaça — é uma confirmação de que o modelo antigo de certificado anual, gerenciado em planilha, já não tem mais lugar. As organizações que automatizarem descoberta, emissão, renovação e deploy antes de 2029 simplesmente não vão notar a transição. As que não automatizarem vão descobrir a diferença entre 1 e 8 janelas de risco por ano, uma renovação perdida de cada vez.