Uma tendência de mão única rumo a certificados mais curtos
Os certificados TLS públicos vêm tendo vidas cada vez mais curtas há mais de uma década. A validade máxima caiu de cinco anos para três, depois para 825 dias, e em setembro de 2020 para 398 dias. Em abril de 2025 o /Browser Forum aprovou a Cédula SC-081v3, proposta pela Apple e aprovada com amplo consenso entre autoridades certificadoras e fornecedores de navegadores, que continua a tendência até os 47 dias. Não é uma proposta nem uma recomendação: está escrito nos Baseline Requirements de TLS que as ACs publicamente confiáveis precisam seguir. O planejador desta página existe porque, uma vez que os certificados vivem tão pouco, definir um ritmo de renovação na mão deixa de ser prático.
O cronograma, fase por fase
A redução acontece em três etapas, cada uma vinculada à data de emissão de um certificado, e não a qualquer certificado já existente. Até 15 de março de 2026 o máximo é 398 dias. A partir de 15 de março de 2026 cai para 200 dias, a partir de 15 de março de 2027 para 100 dias, e a partir de 15 de março de 2029 para 47 dias. Um certificado emitido no dia anterior a um corte mantém o máximo antigo e mais longo por toda a sua vida; um emitido no dia seguinte fica preso ao novo. É exatamente esse o teste que o planejador executa: ele observa a data de emissão que você informa, encontra a fase que a governa, e diz se a validade informada está dentro do limite dessa fase.
Por que o número é 47
O valor parece arbitrário, mas foi escolhido de propósito. Quarenta e sete dias são, aproximadamente, um mês de calendário mais cerca de duas semanas, com um dia de folga: curto o bastante para que a renovação manual em escala se torne inviável, mas longo o suficiente para que um sistema automatizado renove com tranquilidade, sem operar no limite. Os projetistas evitaram deliberadamente um número próximo de 30, para que a renovação não fosse forçada a cair no mesmo dia do calendário todo mês. As etapas intermediárias seguem a mesma lógica: cada uma é alguns meses cheios mais uma fração, mais um dia de margem.
Por que encurtar os tempos de vida afinal
Um certificado é uma afirmação permanente sobre uma chave e um nome, e quanto mais tempo ela permanece de pé, mais tempo dura qualquer problema com ela. Se uma chave privada vaza, um certificado de vida mais curta limita por quanto tempo a chave vazada continua utilizável. Tempos de vida menores também forçam a agilidade criptográfica: o ecossistema inteiro passa a girar com frequência suficiente para que descontinuar um algoritmo fraco, ou responder a um evento de desconfiança de uma AC, realmente surta efeito em semanas e não em anos. A chegada iminente dos computadores quânticos, e a coleta no estilo "colher agora, descriptografar depois" do tráfego de hoje, adiciona urgência a construir essa agilidade agora, o que é parte do motivo de a indústria ter escolhido este momento para empurrar os tempos de vida para baixo com força.
O que isso faz com o volume de renovações
A consequência operacional é o ponto central. Uma organização que hoje renova um certificado mais ou menos uma vez por ano passará a renová-lo cerca de oito vezes por ano com 47 dias. Análises do setor colocam uma frota de 1.000 certificados em aproximadamente 48.000 horas de renovação por ano sob o regime de 47 dias, cerca de doze vezes os volumes atuais. Some a isso o fato de que as identidades de máquina já superam em muitas vezes as humanas e ainda estão crescendo, e a renovação manual simplesmente não escala. O planejador torna isso concreto: para qualquer validade que você informe, ele mostra as renovações por ano que aquele ritmo implica, e projeta o número em cada limite futuro para que você veja a escalada antes que ela chegue.
O que o planejador mostra
Informe as datas de emissão e expiração de um certificado e o planejador relata o tamanho da sua validade, a fase em que cai sua data de emissão, se esse tamanho está dentro do limite, a frequência de renovação que ele implica, e uma data recomendada para renovar. Ele roda inteiramente no seu navegador e modela certificados TLS publicamente confiáveis; o artigo sobre PKI (infraestrutura de chaves públicas) pública e privada explica por que a interna segue regras diferentes, e a ferramenta companheira, o inspetor X.509, decodifica os próprios bytes do certificado.
Esta série, em ordem
Este artigo abre a série Validade e renovação de certificados. O cronograma dos 47 dias acima dá o ritmo; as partes calculam o que ele significa na prática: como a validade é medida, quando renovar, por quanto tempo uma prova de controle pode ser reutilizada, quais certificados o cronograma de fato alcança, e o protocolo e a CA gratuita que automatizam o resto.
- Janelas de validade: notBefore, notAfter e a antecedência da renovação. notBefore e notAfter, como um tempo de vida é medido contra o limite e por que validade não é tempo restante.
- Renovar antes da expiração: antecedência, ACME e ARI. Por que a renovação tardia causa quedas, como e ARI a automatizam e a orientam, e uma antecedência que deixa espaço para tentar de novo.
- Reutilização de DCV e SII: a cadência de validação por trás da renovação. Por quanto tempo as provas de controle de domínio e de identidade podem ser reutilizadas, caindo para 10 dias até 2029, e por que isso remodela a renovação.
- PKI pública e privada: quais certificados a SC-081v3 governa. O cronograma alcança apenas certificados publicamente confiáveis: o que separa a PKI pública da privada, e por que CAs internas estão isentas.
- ACME: como os certificados se emitem e se renovam sozinhos. A conta, o pedido, os três tipos de desafio e a finalização: a emissão automatizada de ponta a ponta.
- Let's Encrypt: a CA gratuita e os seus rate limits. A CA gratuita, por que seus certificados são de vida curta e como funcionam seus limites de emissão (e por que renovações ARI estão isentas).