SC-081v3: certificados TLS de 47 dias, por que e como se preparar
Por CaptainDNS
Publicado em 19 de março de 2026
- SC-081v3 adotado: a validade máxima dos certificados TLS passa de 398 dias para 47 dias até março de 2029, em 3 fases (200d em 2026, 100d em 2027, 47d em 2029)
- A reutilização DCV também cai: de 398 dias para 10 dias, impondo uma revalidação de domínio quase contínua a cada renovação
- A automação não é mais opcional: sem ACME ou equivalente, a renovação manual a cada 47 dias é insustentável
- Descubra também como o SC-085v2 impõe a validação DNSSEC pelas CA, uma medida complementar que entrou em vigor no mesmo dia
O dia 15 de março de 2026 marca um ponto de virada para o ecossistema TLS. Dois ballots do CA/Browser Forum entram em vigor simultaneamente: SC-085v2, que impõe às autoridades de certificação a validação DNSSEC durante a emissão de certificados, e a primeira fase do SC-081v3, que reduz a validade máxima dos certificados TLS de 398 para 200 dias. A coincidência não é casual: os dois textos participam da mesma reformulação da confiança na web.
SC-081v3 foi adotado pelo CA/Browser Forum em abril de 2025 com apoio massivo: 25 votos a favor, 0 contra, 5 abstenções. A Apple, na origem da proposta, foi apoiada por Google, Mozilla e Microsoft. A mensagem é clara: a era dos certificados de um ano acabou. Até março de 2029, a validade máxima de um certificado TLS será de 47 dias, e a reutilização das provas de validação de domínio (DCV) será limitada a 10 dias.
Este artigo cobre o histórico completo das reduções de validade, o detalhe do ballot SC-081v3, as razões técnicas dessa mudança, os incidentes que aceleraram a decisão, a automação ACME, o papel do Let's Encrypt, o impacto nos certificados pagos, a interação com SC-085v2 e DNSSEC, e um guia prático para preparar a sua infraestrutura.
As renovações dos seus certificados estão automatizadas?
De 10 anos a 47 dias: a história da redução
A validade dos certificados TLS não parou de diminuir desde a criação do sistema. Cada redução provocou resistências, e depois uma adaptação rápida da indústria. O padrão é constante: um ator impõe uma mudança, o ecossistema se adapta, e ninguém volta atrás.
Antes de 2012: até 10 anos. As primeiras versões dos certificados SSL não impunham nenhum limite estrito de validade. Certificados de 8 a 10 anos circulavam. A revogação dependia de listas CRL raramente consultadas. O risco de comprometimento ao longo de um período tão longo era considerável, mas o custo dos certificados (várias centenas de dólares) incentivava a maximizar a sua validade.
2012: 5 anos (Baseline Requirements v1). O CA/Browser Forum publica a primeira versão dos Baseline Requirements. A validade máxima é fixada em 60 meses. É a primeira normalização global das práticas de emissão de certificados TLS.
2015: 39 meses. O Ballot 193 reduz a validade para 39 meses. A indústria se adapta sem incidentes maiores. Os certificados de 3 anos se tornam a norma para os clientes empresariais.
2018: 825 dias. Nova redução para 825 dias (cerca de 27 meses) via o Ballot 193 revisado. Os certificados de 2 anos se impõem. O Let's Encrypt, lançado em 2015, já havia popularizado os certificados de 90 dias e demonstrado que a automação funciona em grande escala.
2020: 398 dias (decisão unilateral da Apple). A Apple anuncia unilateralmente em fevereiro de 2020 que o Safari não aceitará mais certificados de mais de 398 dias emitidos após 1.o de setembro de 2020. Google e Mozilla seguem nas semanas seguintes. O CA/Browser Forum não precisou votar: os editores de navegadores impuseram a mudança via seus root programs. A indústria reclama, mas se adapta em poucos meses.
2023: Google propõe 90 dias. Em seu roteiro "Moving Forward, Together", o Google propõe reduzir a validade máxima para 90 dias. A proposta não é votada imediatamente, mas lança o debate.
2024: SC-081v1 retirado, v2 falha. A primeira versão do ballot é retirada antes da votação. SC-081v2 é submetido ao voto, mas não consegue a supermaioria necessária. Várias CA se opõem ao calendário considerado agressivo demais. Os ballots SC-22 e 185, que visavam reduções semelhantes, já haviam falhado nos anos anteriores.
Abril de 2025: SC-081v3 adotado. A terceira versão encontra o consenso. O calendário é distribuído em 4 fases entre 2026 e 2029, dando tempo à indústria para se adaptar. A votação: 25 a favor, 0 contra, 5 abstenções.
O padrão é claro: cada redução foi combatida, depois adotada, e depois considerada insuficiente alguns anos mais tarde. A direção é irreversível.
Ballot SC-081v3: o que muda concretamente
SC-081v3 não se limita a encurtar a validade dos certificados. Ele também reduz o período de reutilização das provas de validação de domínio (DCV reuse), forçando uma revalidação quase contínua.
As 4 fases da redução
| Fase | Data de entrada em vigor | Validade máx. certificado | Reutilização DCV máx. |
|---|---|---|---|
| Fase 0 (atual) | Antes de 15 de março de 2026 | 398 dias | 398 dias |
| Fase 1 | 15 de março de 2026 | 200 dias | 200 dias |
| Fase 2 | 15 de março de 2027 | 100 dias | 100 dias |
| Fase 3 | 15 de março de 2029 | 47 dias | 10 dias |
Entendendo a reutilização DCV
A validação de controle de domínio (DCV) é o processo pelo qual uma CA verifica que o solicitante controla o domínio. Atualmente, uma prova DCV pode ser reutilizada durante 398 dias: se você validar o seu domínio hoje, a CA pode emitir um novo certificado nos 398 dias seguintes sem pedir uma nova prova.
SC-081v3 reduz essa janela de reutilização em paralelo com a validade dos certificados. Na fase 3, a reutilização DCV cai para 10 dias. Concretamente, cada renovação de certificado exigirá uma nova validação de domínio, já que um certificado de 47 dias deve ser renovado antes da expiração e a prova DCV será válida por apenas 10 dias.
Por que 47 dias e não um número redondo?
O número 47 não é arbitrário. Ele corresponde a um ciclo de renovação de 30 dias com uma margem de 17 dias. A ideia: se o cliente ACME renovar o certificado 30 dias antes da expiração (como a maioria dos clientes recomenda), restam 17 dias de margem em caso de falha. Uma renovação por mês, com uma rede de segurança de mais de duas semanas.
O que não muda
SC-081v3 se aplica a todos os tipos de certificados TLS públicos: DV (Domain Validation), OV (Organization Validation) e EV (Extended Validation). Não há exceção para os certificados OV ou EV, ao contrário do que alguns comentaristas esperavam. A distinção DV/OV/EV se refere ao nível de verificação da identidade da organização, não à validade do certificado.
As tentativas que falharam
SC-081v3 não é a primeira tentativa de redução. Vários ballots falharam ao longo dos anos. O Ballot 185 (2017) propunha passar para 13 meses e foi rejeitado. O Ballot SC-22 tentou uma redução para 397 dias e falhou. SC-081v1 foi retirado antes da votação. SC-081v2 não obteve a supermaioria do lado das CA. A v3 conseguiu ao distribuir o calendário e adicionar uma margem suficiente a cada fase.
Por que certificados mais curtos?
A redução da validade dos certificados responde a vários problemas estruturais do ecossistema TLS. Nenhum deles pode ser resolvido pelos mecanismos atuais.
A revogação está quebrada
O mecanismo previsto para invalidar um certificado comprometido não funciona na prática. As listas de revogação (CRL) atingem centenas de megabytes: a CRL do Let's Encrypt ultrapassava 300 MB antes do abandono do OCSP. O OCSP (Online Certificate Status Protocol) sofre do problema do soft-fail: se o servidor OCSP não responde, o navegador aceita o certificado por padrão, tornando a verificação inútil. O Chrome substituiu o OCSP por CRLSets, uma lista compacta que cobre apenas cerca de 2% dos certificados revogados. O Let's Encrypt abandonou oficialmente o OCSP no final de 2024, reconhecendo o fracasso do mecanismo.
Com certificados de 47 dias, a revogação se torna menos crítica. Um certificado comprometido expira naturalmente em poucas semanas, limitando a janela de exploração sem depender de um mecanismo de revogação falho.
Criptoagilidade e migração pós-quântica
Certificados curtos facilitam a migração para novos algoritmos criptográficos. O NIST publicou em agosto de 2024 os padrões finais para a criptografia pós-quântica: ML-KEM (Key Encapsulation) e ML-DSA (Digital Signatures). A transição para esses algoritmos exigirá a substituição dos certificados existentes. Com certificados de 47 dias, o ecossistema inteiro migra em no máximo 47 dias, contra mais de um ano com certificados de 398 dias.
Janela de comprometimento reduzida
Um certificado comprometido de 398 dias pode ser explorado por mais de um ano. Com 47 dias, a janela máxima de exploração cai para menos de 7 semanas. É uma redução de 88%. Se uma chave privada for roubada, o atacante dispõe de poucas semanas em vez de mais de um ano para explorá-la.
A automação forçada reduz incidentes
Paradoxalmente, certificados mais curtos reduzem os incidentes ligados à expiração. O motivo: eles forçam a automação. Um certificado de 398 dias pode ser gerenciado manualmente (mal), esquecido e depois expirar abruptamente. Um certificado de 47 dias não deixa escolha: sem automação, a renovação é impossível de manter. As organizações que automatizam não sofrem mais incidentes de expiração.
Alinhamento com o modelo zero trust
O modelo Zero Trust se baseia na verificação contínua. Um certificado de 398 dias concede uma confiança implícita por mais de um ano, o que contradiz o princípio. Certificados curtos impõem uma reverificação frequente da identidade do servidor, alinhando a PKI web com os princípios Zero Trust.
Os incidentes que mudaram tudo
Vários incidentes maiores demonstraram as consequências de uma gestão manual de certificados. Cada incidente reforçou o argumento a favor da automação e da redução de validade.
Equifax (2017): 147,9 milhões de pessoas expostas
Em março de 2015, a Equifax deixa expirar um certificado SSL em um equipamento de inspeção de tráfego de rede. Esse certificado vencido havia 19 meses impede a detecção de uma intrusão ativa. Os atacantes exploram uma vulnerabilidade Apache Struts não corrigida durante 76 dias, exfiltrando os dados pessoais de 147,9 milhões de pessoas. O custo total ultrapassa 1,38 bilhão de dólares. A investigação revela que a empresa gerenciava mais de 300 certificados manualmente, sem inventário centralizado.
Ericsson/O2 UK (2018): 32 milhões de usuários sem rede
Em 6 de dezembro de 2018, um certificado intermediário Ericsson expira na infraestrutura de rede da O2 UK. A expiração provoca uma interrupção total da rede móvel para 32 milhões de assinantes durante mais de 12 horas. A SoftBank no Japão sofre uma interrupção idêntica no mesmo dia. O custo estimado ultrapassa 133 milhões de dólares. O certificado, com validade de 15 anos, havia sido instalado e esquecido.
Microsoft Teams (2020): 3 horas de interrupção mundial
Em 3 de fevereiro de 2020, o Microsoft Teams sofre uma interrupção de 3 horas em plena explosão de uso ligada à COVID-19. A causa: um certificado de autenticação expirado. O incidente atinge milhões de usuários em teletrabalho no momento em que o Teams se tornara uma ferramenta crítica para milhares de empresas.
Let's Encrypt (2021): a expiração de um certificado raiz histórico
Em 30 de setembro de 2021, o certificado raiz DST Root CA X3, usado pelo Let's Encrypt para compatibilidade com dispositivos antigos, expira. Milhões de dispositivos com Android 7.1 e versões anteriores perdem o acesso a sites que usam Let's Encrypt. O incidente ilustra a complexidade da gestão de certificados raiz e a necessidade de cadeias de confiança ágeis.
O ponto em comum desses incidentes: cada interrupção envolve um certificado gerenciado manualmente, esquecido ou cuja validade ultrapassava amplamente as necessidades operacionais.
ACME e a automação obrigatória
Com certificados de 47 dias e reutilização DCV de 10 dias, a renovação manual se torna fisicamente impossível para qualquer infraestrutura com mais de um punhado de certificados. O ACME (Automatic Certificate Management Environment) é o protocolo que torna a automação possível.
O protocolo ACME (RFC 8555)
O ACME padroniza o diálogo entre um cliente (seu servidor) e uma CA. O processo segue três etapas: o cliente prova que controla o domínio (challenge), a CA verifica a prova e depois emite o certificado. Existem três tipos de challenges:
- HTTP-01: o cliente coloca um arquivo em uma URL específica. A CA verifica que o arquivo está acessível. Simples, mas incompatível com certificados wildcard.
- DNS-01: o cliente publica um registro TXT em
_acme-challenge.captaindns.com. A CA consulta o DNS. Compatível com wildcard, ideal para ambientes automatizados. - TLS-ALPN-01: o cliente configura um certificado temporário com uma extensão ALPN específica. Útil quando você não controla nem o DNS nem o servidor web.
Clientes ACME
O ecossistema de clientes ACME é maduro e cobre todos os ambientes:
- Certbot: o cliente de referência, mantido pela EFF. Compatível com Linux, macOS, Windows. Plugins para Apache e NGINX.
- acme.sh: script shell puro, sem dependências. Mais de 150 APIs DNS suportadas para o challenge dns-01.
- Lego: cliente Go, popular em ambientes containerizados e pipelines CI/CD.
- Caddy: servidor web com ACME integrado. Obtém e renova certificados automaticamente, sem configuração.
- Traefik: reverse proxy cloud-native com ACME integrado. Gerencia certificados para todos os backends.
ACME na nuvem
Os principais provedores de nuvem integram a automação de certificados:
- AWS Certificate Manager (ACM): certificados gratuitos com renovação automática para os serviços AWS (ALB, CloudFront, API Gateway).
- Google Cloud Managed Certificates: renovação automática para os load balancers GCP.
- Azure App Service Managed Certificates: certificados gratuitos e renovados automaticamente.
- Cloudflare: certificados edge e origin gerenciados automaticamente, com suporte a certificados de 15 dias.
ACME renewal information (ARI, RFC 9773)
O ARI é uma extensão ACME que permite à CA comunicar ao cliente a janela ideal de renovação. Em vez de renovar sistematicamente com uma porcentagem fixa do tempo restante, o cliente consulta a CA para saber o momento ideal. Isso permite à CA distribuir a carga e sinalizar uma renovação antecipada em caso de comprometimento de chave. O Let's Encrypt suporta ARI desde 2024.
NGINX e o módulo ACME nativo
Em agosto de 2025, o NGINX publicou um módulo nativo ACME que permite ao servidor web obter e renovar seus certificados diretamente, sem cliente externo. Essa integração simplifica consideravelmente a implantação para os ambientes que usam NGINX como frontend.
Soluções empresariais
Para grandes organizações que gerenciam milhares de certificados, soluções CLM (Certificate Lifecycle Management) orquestram a renovação em escala:
- HashiCorp Vault PKI: motor PKI integrado ao Vault, com emissão e rotação automatizadas.
- Venafi / CyberArk: plataforma CLM enterprise (a CyberArk adquiriu a Venafi por 1,54 bilhão de dólares em 2024).
- Keyfactor: plataforma de gestão do ciclo de vida dos certificados e identidades de máquina.
- Sectigo Certificate Manager: CLM com ACME integrado, cobrindo certificados públicos e privados.
Let's Encrypt como pioneiro
O Let's Encrypt não esperou o SC-081v3 para empurrar a indústria na direção de certificados curtos. A autoridade de certificação gratuita e automatizada detém cerca de 63,9% de participação de mercado dos certificados TLS web e emite mais de 10 milhões de certificados por dia. Sua influência no ecossistema é considerável.
Certificados de 6 dias em produção
Desde janeiro de 2026, o Let's Encrypt oferece certificados de 6 dias em disponibilidade geral. Esses certificados ultracurtos visam ambientes altamente automatizados (CDN, plataformas de nuvem, CI/CD) onde a renovação é totalmente pilotada por ACME. O objetivo: provar que validades muito curtas funcionam em escala industrial.
Rumo a certificados de 45 dias por padrão
O Let's Encrypt anunciou um plano de transição para certificados de 45 dias por padrão. O calendário prevê uma fase opt-in a partir de maio de 2026, seguida de uma mudança para o padrão de 45 dias em fevereiro de 2028. Essa antecipação do calendário SC-081v3 (que impõe 47 dias em março de 2029) dá ao ecossistema um ano de vantagem para validar os pipelines de automação.
O abandono do OCSP
No final de 2024, o Let's Encrypt anunciou o abandono progressivo do OCSP, concluído em 2025. O motivo: o OCSP não funciona (soft-fail nos navegadores, problemas de privacidade, carga no servidor). Essa escolha acelerou a reflexão da indústria sobre a revogação e reforçou o argumento dos certificados curtos. Se a revogação não funciona, a única alternativa é limitar a validade dos certificados.
O Let's Encrypt prova todos os dias que a automação em grande escala é viável. Mais de 400 milhões de sites usam seus certificados. A passagem para 47 dias não será um problema para os ambientes já automatizados: será um não-evento.
Impacto nos certificados pagos e no ecossistema CA
SC-081v3 transforma o modelo econômico das autoridades de certificação e questiona o valor agregado dos certificados pagos.
OV e EV: ainda válidos, mas mais curtos
Os certificados OV (Organization Validation) e EV (Extended Validation) continuam disponíveis. A validação de organização (verificação da identidade da empresa, endereço, número de registro) continua trazendo um valor distinto da simples validação de domínio. Mas a validade do certificado é reduzida da mesma forma: 200 dias em 2026, 100 dias em 2027, 47 dias em 2029. Um certificado EV de 47 dias impõe o mesmo ritmo de renovação que um certificado DV.
O pivot para assinaturas e CLM
As CA pagas pivotam seu modelo econômico. Em vez de vender certificados unitários com validade fixa, elas oferecem assinaturas anuais incluindo renovações ilimitadas e um cliente ACME integrado. DigiCert, Sectigo e GlobalSign oferecem plataformas CLM (Certificate Lifecycle Management) que automatizam a renovação ACME para certificados OV e EV.
A consolidação do mercado CA
A aquisição da Venafi pela CyberArk por 1,54 bilhão de dólares em 2024 ilustra a consolidação do mercado. O valor se desloca da emissão de certificados para a gestão do ciclo de vida. As CA que não oferecem automação integrada perdem participação de mercado frente ao Let's Encrypt e às soluções CLM.
Wildcards e multi-SAN
Os certificados wildcard (*.captaindns.com) e multi-SAN (vários domínios em um único certificado) exigem o challenge DNS-01 para a validação. Com renovações a cada 47 dias, a automação do challenge dns-01 via API do provedor DNS se torna indispensável. Os principais provedores DNS (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) oferecem APIs compatíveis com os clientes ACME.
A automação questiona o certificado pago
A automação ACME nivela o campo de jogo. Um certificado DV gratuito Let's Encrypt, renovado automaticamente a cada 47 dias, oferece o mesmo nível de criptografia que um certificado EV pago. A diferença se limita à barra de endereço do navegador (que não exibe mais o nome da organização desde 2019) e à garantia financeira associada ao certificado. Para a maioria dos sites, essa diferença não justifica mais o custo adicional.
Interação com SC-085v2: DNSSEC e renovações frequentes
SC-081v3 e SC-085v2 entram em vigor no mesmo mês e criam um efeito multiplicador na cadeia de confiança DNS. Para entender o SC-085v2 em detalhe, consulte nosso artigo dedicado.
O efeito multiplicador
Com SC-085v2, cada validação de domínio (DCV) agora inclui uma verificação DNSSEC. Com a fase 3 do SC-081v3, um certificado de 47 dias implica cerca de 8 renovações por ano em vez de 1. Cada renovação aciona uma DCV, e cada DCV verifica DNSSEC. O número de verificações DNSSEC ligadas aos certificados é portanto multiplicado por 8.
Cenário de falha: DNSSEC quebrado + certificados curtos
Considere um cenário concreto. Seu certificado TLS expira em 15 dias. Seu cliente ACME tenta a renovação. A CA realiza a validação DNS-01 e verifica DNSSEC conforme o SC-085v2. Mas uma rotação de chave DNSSEC falhou: o registro DS no TLD não corresponde mais à KSK da sua zona. O resolvedor da CA retorna BOGUS, a DCV falha, o certificado não é renovado.
Com um certificado de 398 dias, você tem meses para detectar e corrigir o problema. Com um certificado de 47 dias, você tem no máximo 17 dias (a margem integrada ao ciclo de renovação). Se o problema DNSSEC persistir, seu certificado expira e seu site se torna inacessível.
Rotação DANE/TLSA e certificados curtos
Se você usa DANE para autenticar seus certificados TLS via registros TLSA assinados por DNSSEC, a rotação dos registros TLSA deve acompanhar o ritmo das renovações de certificados. Com um certificado de 47 dias, o registro TLSA deve ser atualizado a cada renovação (exceto no modo DANE-EE 3 1 1 com SPKI, que sobrevive à renovação se a chave pública não mudar). Consulte nosso guia DANE/TLSA para as estratégias de rotação.
Pipeline unificado: a recomendação
A combinação SC-081v3 + SC-085v2 impõe uma abordagem unificada. O pipeline de renovação de certificados deve integrar:
- A renovação ACME do certificado TLS
- A verificação prévia da cadeia DNSSEC
- A atualização dos registros DANE/TLSA se necessário
- O monitoramento contínuo dos três componentes
Tratar esses elementos separadamente multiplica os pontos de falha. Um pipeline unificado que verifica DNSSEC antes de iniciar a renovação ACME, e depois atualiza TLSA após a emissão, reduz consideravelmente o risco de interrupção.
Guia prático: preparar a sua infraestrutura
A transição para certificados de 47 dias se faz em 4 fases ao longo de 3 anos. Cada fase impõe restrições mais rigorosas. Aqui estão as 6 etapas para preparar a sua infraestrutura.
Etapa 1: inventariar todos os seus certificados
Antes de automatizar, é preciso saber o que você gerencia. Use várias fontes para fazer um inventário completo:
- Certificate Transparency logs: consulte os logs CT (crt.sh) para listar todos os certificados emitidos para os seus domínios.
- Scan de rede: use ferramentas como
sslyzeounmappara descobrir os certificados ativos na sua infraestrutura. - Ferramentas CLM: plataformas como Keyfactor ou Venafi Discovery escaneiam a sua rede e nuvens para identificar certificados não catalogados.
- Nosso DNSSEC Checker: verifique a cadeia de confiança DNSSEC, indispensável para a renovação de certificados desde o SC-085v2.
Documente para cada certificado: o domínio, a CA emissora, a data de expiração, o tipo (DV/OV/EV), o modo de renovação (manual ou automatizado) e o responsável.
Etapa 2: implantar um cliente ACME adequado
Escolha um cliente ACME adequado ao seu ambiente:
- Servidor web standalone: Certbot com o plugin apropriado (Apache, NGINX) ou Caddy com ACME integrado.
- Ambiente containerizado: cert-manager para Kubernetes, Lego para pipelines CI/CD.
- Infraestrutura de nuvem: AWS ACM, Google Cloud Managed Certificates ou Azure App Service Managed Certificates.
- Ambiente misto: acme.sh pela sua flexibilidade e compatibilidade com mais de 150 APIs DNS.
Teste a renovação com um dry-run antes de passar para produção. Valide que o cliente pode renovar sem intervenção humana.
Etapa 3: automatizar a validação DNS
Para o challenge dns-01 (necessário para certificados wildcard), seu cliente ACME precisa poder criar e excluir registros TXT via a API do seu provedor DNS. Configure os acessos à API com permissões mínimas: criação e exclusão de registros TXT em _acme-challenge somente.
Se o seu provedor DNS não oferece API, migre para um provedor que ofereça. Em 2026, a ausência de API DNS é um fator bloqueante.
Etapa 4: verificar a sua cadeia DNSSEC
Com SC-085v2, uma cadeia DNSSEC quebrada bloqueia a renovação de certificados. Verifique:
- A presença e a validade do registro DS no TLD
- A coerência entre o DS e a KSK publicada na sua zona
- A validade das assinaturas RRSIG (datas de expiração)
- A automação da rotação das chaves ZSK e KSK
Consulte nosso guia sobre a cadeia de confiança DNSSEC para os detalhes técnicos. Use o DNSSEC Checker para um diagnóstico completo.
Etapa 5: implementar o monitoramento
Implante alertas em três eixos:
- Expiração dos certificados TLS: alerta a 30 dias, 14 dias e 7 dias antes da expiração.
- Assinaturas DNSSEC (RRSIG): alerta quando as assinaturas se aproximam da data de expiração.
- Registros DANE/TLSA: verificação de que os registros TLSA correspondem ao certificado ativo.
O monitoramento é a rede de segurança que detecta falhas de automação antes que se tornem interrupções.
Etapa 6: planejar a migração progressiva
Não espere março de 2029 para passar a 47 dias. Adote um plano progressivo:
- Agora mesmo: automatize todos os certificados com validades de 90 dias (Let's Encrypt por padrão).
- 2026: teste os certificados de 6 dias do Let's Encrypt em um ambiente de staging.
- 2027: passe para produção com certificados de 100 dias ou menos.
- 2028: ative os certificados de 45 dias Let's Encrypt (opt-in) para validar o seu pipeline antes do prazo.
- 2029: a passagem para 47 dias é um não-evento, a sua infraestrutura está pronta.
Plano de ação: preparar a sua infraestrutura
- Inventariar todos os seus certificados: discovery via CT logs, scan de rede, ferramentas CLM
- Implantar um cliente ACME: Certbot, acme.sh ou Lego conforme o ambiente
- Automatizar a validação DNS: API do provedor DNS para o challenge dns-01
- Verificar DNSSEC: cadeia de confiança válida, rotações de chaves automatizadas
- Implementar o monitoramento: alertas de expiração de certificados + RRSIG + TLSA
- Testar com certificados curtos: Let's Encrypt 90d e depois 6d para validar o pipeline
FAQ
O que é o Ballot SC-081v3 do CA/Browser Forum?
SC-081v3 é um ballot adotado em abril de 2025 pelo CA/Browser Forum que reduz progressivamente a validade máxima dos certificados TLS públicos. A validade passa de 398 dias para 200 dias (março de 2026), depois 100 dias (março de 2027) e depois 47 dias (março de 2029). Ele também reduz o período de reutilização das provas de validação de domínio (DCV) até 10 dias na fase final.
Quando os certificados de 47 dias se tornam obrigatórios?
Os certificados de 47 dias no máximo se tornam obrigatórios em 15 de março de 2029 (fase 3 do ballot). Antes dessa data, duas fases intermediárias se aplicam: 200 dias no máximo a partir de 15 de março de 2026 e 100 dias no máximo a partir de 15 de março de 2027. Os certificados emitidos antes de cada data limite permanecem válidos até a sua expiração natural.
Meus certificados atuais serão revogados?
Não. Os certificados já emitidos permanecem válidos até a sua data de expiração, independentemente da fase em curso. SC-081v3 se aplica somente aos novos certificados emitidos após cada data de entrada em vigor. Um certificado de 398 dias emitido em 14 de março de 2026 permanecerá válido durante toda a sua validade.
Por que 47 dias e não um número redondo?
O número 47 corresponde a um ciclo de renovação de 30 dias mais uma margem de 17 dias. Se o cliente ACME renovar 30 dias antes da expiração (a prática recomendada), restam 17 dias de margem em caso de falha na renovação. Essa margem permite detectar e corrigir os problemas antes da expiração efetiva do certificado.
Os certificados EV e OV são afetados?
Sim. SC-081v3 se aplica a todos os tipos de certificados TLS públicos, incluindo DV, OV e EV. Não há nenhuma exceção. A distinção entre esses tipos se refere ao nível de verificação da identidade da organização, não à validade do certificado. Um certificado EV será limitado a 47 dias assim como um certificado DV a partir de março de 2029.
O que é a redução da reutilização DCV?
A reutilização DCV (Domain Control Validation) permite que uma CA reutilize uma prova de controle de domínio para emitir vários certificados sem pedir uma nova validação. SC-081v3 reduz essa janela de 398 dias para 10 dias na fase final. Concretamente, cada renovação de certificado na fase 3 exigirá uma nova prova de controle do domínio.
Preciso migrar para o Let's Encrypt?
Não necessariamente. O Let's Encrypt é uma opção sólida para certificados DV automatizados, mas outras CA também suportam ACME: DigiCert, Sectigo, GlobalSign e ZeroSSL oferecem endpoints ACME. Se você precisa de certificados OV ou EV, deverá permanecer com uma CA paga, mas com um cliente ACME para a renovação automatizada.
Como funciona o ACME para a renovação automática?
O ACME (RFC 8555) automatiza o diálogo entre o seu servidor e a CA. O cliente ACME prova que você controla o domínio (via um challenge HTTP-01, DNS-01 ou TLS-ALPN-01), a CA verifica a prova e depois emite o certificado. O cliente então agenda a renovação automática antes da expiração. Todo o processo ocorre sem intervenção humana.
Qual é a relação entre SC-081v3 e SC-085v2 (DNSSEC)?
SC-085v2 impõe às CA a validação DNSSEC durante a DCV. SC-081v3 multiplica as DCV ao encurtar a validade dos certificados. Combinados, esses dois ballots criam um efeito multiplicador: 8 renovações por ano (47 dias) significam 8 verificações DNSSEC em vez de 1. Um DNSSEC quebrado portanto bloqueia de forma mais rápida e frequente a renovação dos seus certificados.
Os certificados internos (PKI privada) são afetados?
Não. SC-081v3 se aplica somente aos certificados emitidos por CA publicamente aprovadas (aquelas cujo certificado raiz está incluído nos repositórios de confiança dos navegadores). Os certificados emitidos por uma PKI privada interna à sua organização não estão sujeitos aos Baseline Requirements do CA/Browser Forum e não são afetados por essa redução.
Glossário
- CA/Browser Forum: consórcio que reúne as autoridades de certificação e os editores de navegadores. Ele publica os Baseline Requirements, o marco normativo que todas as CA públicas devem respeitar para que seus certificados sejam aceitos pelos navegadores.
- Ballot: proposta de modificação dos Baseline Requirements submetida à votação dos membros do CA/Browser Forum. Um ballot deve obter uma supermaioria do lado das CA e unanimidade do lado dos navegadores para ser adotado.
- DCV (Domain Control Validation): processo pelo qual uma CA verifica que o solicitante de um certificado controla efetivamente o domínio. Os métodos comuns são DNS-01, HTTP-01 e email. A reutilização DCV permite reutilizar uma prova existente para emissões posteriores.
- ACME (Automatic Certificate Management Environment): protocolo padronizado (RFC 8555) para a automação da emissão e renovação de certificados TLS. Usado pelo Let's Encrypt, certbot, acme.sh, Lego e cert-manager.
- CRL (Certificate Revocation List): lista de certificados revogados publicada por uma CA. As CRL são volumosas (várias centenas de MB) e raramente consultadas pelos navegadores, o que limita a sua eficácia.
- OCSP (Online Certificate Status Protocol): protocolo de verificação em tempo real do status de revogação de um certificado. Na prática, os navegadores ignoram os erros OCSP (soft-fail), tornando o mecanismo ineficaz. O Let's Encrypt abandonou o OCSP em 2025.
- Criptoagilidade: capacidade de um sistema de migrar rapidamente para novos algoritmos criptográficos. Certificados curtos facilitam essa migração ao limitar o período durante o qual um algoritmo obsoleto permanece em uso.
- DANE/TLSA: protocolo que permite publicar no DNS (via registros TLSA assinados por DNSSEC) o certificado esperado em um servidor. Elimina a dependência das CA para a autenticação do certificado.
