Renovações de certificados HTTPS agora, parte da rotina
Até mês passado, fevereiro de 2026, você tinha a opção de comprar um certificado SSL válido por 365 dias, instalar em todo o seu ambiente e só se preocupar com esta mudança no próximo ano.
Mas o CA/Browser Forum [1] decidiu que isso não será mais assim, agora os certificados devem ter validade de no máximo 200 dias e já com cronograma para chegar em 47, conforme a tabela:
| Certificado emitido em ou após | Certificado emitido antes | Validade máxima |
| 15 de março de 2026 | 398 dias | |
| 15 de março de 2026 | 15 de março de 2027 | 200 dias |
| 15 de março de 2027 | 15 de março de 2029 | 100 dias |
| 15 de março de 2029 | 47 dias |
Fonte: CA/Browser Forum [2]
Na minha compreensão, a principal justificativa deles [3], é a possibilidade de um domínio ser transferido de dono com o antigo ainda tendo um certificado válido, não sei se eles pensaram também em tornar as chaves privadas expostas em repositórios de código, como GitHub, obsoletas mais rapidamente.
Acredito que isso dará mais força comercial para soluções de SSL Offload, como o Azure Front Door, que já realizam a renovação do certificado automaticamente, sem intervenção e interrupção.
Vejo desafios para outras soluções que não puramente HTTP, mas que utilizam estes certificados, como o Deployment de Remote Desktop do Windows Server da Microsoft, que utiliza certificado desde para o site “RDWeb”, até para assinar digitalmente o arquivo RDP, dentre outras utilizações.
Tenho como certo, é que será necessário automatizar este processo, que antes era esporádico, anual, e agora se tornará rotineiro, mensal.
Não sei se o compras vai ser impactado, pois pelo que entendi comercialmente ainda será comercializado por um ano.
[2] Latest Baseline Requirements | CA/Browser Forum
[3] Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods | CA/Browser Forum
Tags: Automação, Certificado, Infraestrutura, Processos.
Categorias: Processos.