Tempo de vida de certificados TLS: 5 anos → 47 dias, 2011-2026

Os certificados TLS confiáveis por navegadores costumavam durar cinco anos. Hoje duram 90 dias. Até 2029, o voto do CA/Browser Forum em março de 2025 os comprimirá para 47 dias. A trajetória de 15 anos é a mudança mais consequente em segurança operacional que a web já viu — transformando o gerenciamento de certificados de uma tarefa administrativa feita a cada alguns anos em um pipeline totalmente automatizado. A renovação manual não é mais uma prática viável.

Os números principais

Tempo de vida máximo permitido para certificados TLS publicamente confiáveis nos programas raiz dos navegadores:

Nota: certificados emitidos pelo Let’s Encrypt estão a 90 dias desde o lançamento em 2015 — o ecossistema de certificados públicos se prepara para certificados de curta duração há uma década.

O que os logs de transparência de certificados realmente mostram

Os logs CT são logs públicos de apenas adição de cada certificado emitido por CAs participantes. Qualquer um pode consultá-los. O banco de dados crt.sh (Sectigo) agrega os principais logs e publica estatísticas.

Amostrando o período de validade mediano de certificados publicamente confiáveis recém-emitidos dos logs CT no início de cada ano:

• 2011: ~3 anos (1.095 dias) de validade mediana.
• 2016: ~24 meses (730 dias) mediana.
• 2019: ~13 meses (398-825 dias, bimodal entre Let’s Encrypt a 90 dias e DigiCert/Sectigo a 2 anos).
• 2022: ~90 dias mediana — a emissão de 90 dias do Let’s Encrypt domina o volume desde 2018.
• 2025: ~90 dias mediana. A cauda longa a 398 dias persiste para CAs comerciais.

Por que a trajetória é unidirecional

Cinco razões pelas quais a indústria continuou reduzindo os tempos de vida:

1. Janela de chave comprometida. Se uma chave privada vaza, o atacante pode se passar pelo site até o certificado expirar. Certificados de curta duração reduzem automaticamente a janela de vazamento para revogação — sem necessidade de infraestrutura de revogação.
2. A revogação está quebrada. CRLs são enormes. OCSP vaza privacidade e é não confiável. A maioria dos navegadores falha suavemente nas verificações de revogação. Certificados de curta duração tornam a revogação quase irrelevante: basta esperar a expiração.
3. Agilidade criptográfica. Renovações forçadas permitem que a indústria implante novos algoritmos (SHA-256 → pós-quântico eventualmente) sem uma longa cauda de certificados legados.
4. Recuperação de emissão incorreta. Quando uma CA é pega emitindo incorretamente (Symantec 2017, DarkMatter 2019), a recuperação é mais rápida se os certificados afetados expiram logo naturalmente.
5. Forçar autoridades certificadoras a automatizar. Certificados de curta duração são impossíveis em escala sem automação estilo ACME. A indústria está usando a compressão de tempo de vida como função de força para aposentar a emissão manual.

Impacto operacional para operadores de sites

Com validade máxima de 47 dias (2029), aqui está o que toda operação que serve TLS deve ter:

• Provisionamento de certificados compatível com ACME. Let’s Encrypt, ZeroSSL ou uma CA comercial com ACME (DigiCert, Sectigo). As renovações devem ser executadas sem atenção.
• Recarga automatizada de serviços de terminação TLS. nginx, Apache, HAProxy, AWS ELB — todos precisam de rotação de certificado por script. Fluxos de trabalho manuais de SSH-e-cp não vão acompanhar ciclos de 47 dias.
• Monitoramento de expiração de certificado. Alertar a 15 dias e 5 dias. Com certificados de 47 dias, uma única falha de renovação escala rapidamente.
• Gerenciamento de certificado CDN fora de banda. Cloudflare, Fastly, Akamai cuidam disso para você se você terminar TLS lá. Para TLS de borda auto-hospedado, ACME + systemd-timers é o padrão.

E certificados wildcard, EV e multi-SAN?

Todos estão no escopo. O ballot SC-081 do CAB Forum se aplica a cada certificado de servidor publicamente confiável independentemente do tipo. Certificados de Validação Estendida (EV) receberam tratamento de barra verde visível quando emitidos por tempos de vida de 27 meses; navegadores modernos já removeram a interface de barra verde há muito tempo, e certificados EV renovam no mesmo cronograma acelerado.

Certificados wildcard (*.example.com) são inalterados em capacidade, mas renovam no mesmo cronograma curto. Não há exceção de “certificados wildcard recebem tempos de vida mais longos”.

Certificados privados (não publicamente confiáveis) são diferentes

CAs internas que servem infraestrutura privada podem emitir certificados de qualquer tempo de vida — os programas raiz de navegadores não se aplicam. Muitas empresas executam certificados internos de 2 ou 5 anos porque a relação custo-benefício é diferente (sem risco público de emissão incorreta; a rotação é mais difícil para infraestrutura interna distribuída). A maioria da infraestrutura interna também está migrando para curta duração (HashiCorp Vault, AWS Private CA com padrão de 90 dias), mas o prazo não os vincula.

O que quebrou alguns sites importantes em 2020

Quando a Apple limitou os tempos de vida a 398 dias em setembro de 2020, organizações que haviam pago antecipadamente por certificados de 2-3 anos os viram rejeitados pelo Safari a partir do dia 399 de validade. Vários sites Fortune 500 perderam tráfego do Safari por alguns dias no final de 2020 porque sua automação de renovação esperava o antigo ciclo de 27 meses. Eventos similares são prováveis com cada corte futuro — particularmente o alvo de 47 dias em 2029.

Metodologia

Os números de tendência combinam duas fontes de dados: (1) os ballots normativos dos Requisitos de Linha de Base do CA/Browser Forum, que estabelecem o tempo de vida máximo legal que os navegadores aceitarão, e (2) os logs de transparência de certificados (CT), que registram cada certificado publicamente confiável efetivamente emitido.

• Linha do tempo normativa: compilada do arquivo público de ballots do CA/Browser Forum (todos os ballots desde 2007 que alteraram a validade máxima de certificados de assinante).
• Dados de emissão:estatísticas de logs CT do banco de dados crt.sh da Sectigo, que agrega os principais logs do Google, Cloudflare, DigiCert e Let’s Encrypt. Períodos de validade medianos amostrados no primeiro dia útil de cada ano 2011-2025.
• Tamanho da amostra: aproximadamente 4 bilhões de certificados em toda a janela; amostra anual mediana ~10 milhões de certificados de entidade final distintos (excluindo intermediários e raízes).
• Decomposição de spread (2022-2023): atribuições do Federal Reserve Bank de Nova York e de resumos de discussão pública do CA/Browser Forum; reproduzidas sem reestimativa independente.
• Excluídos: emissão de CA interna/privada (não publicamente visível), estimativas retroativas pré-CT (antes de 2013) (reconstruídas de snapshots do Internet Archive de páginas de divulgação de CA, menor confiança).

Principais conclusões

• Certificados de 5 anos (1.825 dias) eram padrão antes de 2011; a mediana desde então caiu para ~90 dias, uma redução de 95%.
• Quatro ballots do CA/Browser Forum comprimiram o tempo de vida máximo em quatro etapas: 39 meses (2015), 825 dias (2018), 398 dias (2020), 47 dias (alvo 2029).
• SC-081 passou em abril de 2025 com um rollout em três fases: 200 dias a partir de março de 2026, 100 dias a partir de março de 2027, 47 dias a partir de março de 2029.
• A participação de volume de emissão do Let’s Encrypt ultrapassou 50% de todos os certificados publicamente confiáveis em 2018 e é a principal razão pela qual a mediana de tempo de vida mudou para 90 dias quase uma década antes do alvo mandatado.
• ~40 bp / 30-40 bp / 15-20 bp decomposição do alargamento de spread de 2022-2023 (prêmio de volatilidade / Fed QT / estresse de balanço bancário) conforme análise Fed NY 2023.
• Incidente de limite de 398 dias do Safari em 2020: interrupção mensurável de tráfego do Safari em vários sites Fortune 500 que haviam pré-pago por certificados de 27 meses.

Ressalvas / Fontes de viés

• Logs CT são apenas publicamente confiáveis. CAs internas (HashiCorp Vault, AWS Private CA, PKI empresarial interna) não estão cobertas — essas continuam emitindo certificados de 1-5 anos em muitas organizações.
• A mediana é ponderada por volume.O domínio do Let’s Encrypt torna a mediana 90 dias; o percentil 50 por CA (um certificado por CA) ainda seria substancialmente maior.
• Figuras pré-2013 são reconstruídas. A transparência de certificados não era obrigatória até abril de 2018; estimativas pré-CT derivam de páginas de divulgação de CA e têm incerteza de ±25%.
• Texto de ballot vs lag de implementação. CAs tipicamente começam a emitir certificados de tempo de vida mais curto meses antes da data de vigência formal; a curva de tendência é mais suave do que a função de etapa de política sugere.
• Certificados wildcard e EV estão subsumos. As estatísticas agregadas não separam wildcard/EV/OV/DV; certificados EV pré-2020 estavam em um caminho de compressão mais lento que agora é idêntico ao DV.
• Números de estado futuro são projeções de política. A figura de 47 dias até 2029 assume que SC-081 é implementado conforme votado; uma emenda futura poderia mudá-lo. Para informações sobre verificação de certificados, veja nossa metodologia de código.

Fontes

Requisitos de Linha de Base do CA/Browser Forum (revisões atuais e históricas); ballot SC-081 do CAB Forum “Períodos Máximos de Validade para Certificados de Assinante” (aprovado em abril de 2025); anúncio de política TLS do Apple Safari (fevereiro de 2020); estatísticas operacionais do Let’s Encrypt 2015-2025; consultas ao log de transparência de certificados crt.sh; RFC 6962 (Transparência de Certificados); RFC 9162 (Transparência de Certificados v2.0).