(Atualizado em 12 de outubro de 2026.)
Os certificados TLS de servidor de confiança pública passaram a ter uma validade máxima mais curta. A alteração SC081v3 das Baseline Requirements do CA/Browser Forum, aprovada em abril de 2025, estabelece uma redução faseada até março de 2029. Para quem gere sítios Web, aplicações e outros serviços HTTPS, isto significa emitir e instalar certificados com maior frequência.
Trata-se de uma regra técnica do ecossistema de certificados de confiança pública, não de uma nova lei europeia. A sua aplicação depende também da adoção destas regras pelos programas de confiança dos fabricantes de navegadores e outros fornecedores de aplicações.
O calendário diz respeito aos certificados TLS de servidor de confiança pública. Pode abranger também serviços que não estejam acessíveis publicamente, desde que os nomes ou endereços IP e a respetiva validação cumpram as regras aplicáveis. Não impõe os mesmos limites aos certificados raiz ou intermédios das autoridades de certificação, aos certificados de assinatura de código, aos certificados S/MIME ou às infraestruturas de chave pública exclusivamente privadas. Essas categorias podem estar sujeitas a regras próprias.
Os certificados públicos podem ser DV (validação do controlo ou autorização sobre o domínio), OV (verificação adicional da identidade da organização) ou EV (verificações reforçadas da organização e da autorização do pedido). Estas categorias distinguem a verificação efetuada antes da emissão; nenhuma constitui uma exceção aos novos limites gerais de validade.
O limite aplicável é determinado pela data de emissão de cada certificado:
Em outubro de 2026, o máximo geral já é, portanto, de 200 dias. Estes valores são tetos, não períodos que todos os emissores tenham de oferecer. Uma autoridade de certificação pode emitir certificados de duração inferior ou implementar a mudança antes da data-limite. Para estes cálculos, um dia corresponde a 86 400 segundos; a margem recomendada reduz o risco de ultrapassar o limite por diferenças entre os instantes de início e fim da validade.
Por exemplo, a DigiCert passou a limitar as novas emissões a 199 dias em 24 de fevereiro de 2026. A Sectigo adotou o mesmo máximo em 12 de março de 2026.
A validade do certificado é o intervalo indicado pelos campos notBefore e notAfter do certificado X.509. Estar dentro desse intervalo não basta, por si só, para estabelecer confiança: também são necessárias as restantes verificações da cadeia, do nome e do estado do certificado.
O período de reutilização da validação determina durante quanto tempo a autoridade de certificação pode aproveitar dados, documentos ou verificações anteriores para uma nova emissão. A expiração desse período exige uma nova verificação antes de emitir outro certificado; não encurta retroativamente a validade de um certificado já emitido.
A duração do plano comercial é a cobertura contratada ao fornecedor. Um plano anual ou plurianual pode abranger várias emissões sucessivas. A redução do prazo técnico de cada certificado não determina, por si só, uma nova frequência de faturação nem um pagamento por cada emissão; é necessário consultar as condições do produto e do contrato.
Não. A entrada em vigor de um limite mais curto não altera automaticamente a data de expiração dos certificados emitidos antes desse limite. Um certificado existente pode continuar a ser usado até à sua expiração, desde que não seja revogado e continue a cumprir as restantes condições de confiança.
Se for emitido um certificado de substituição — por renovação ou reemissão —, aplicam-se o limite vigente nessa nova data de emissão e a política da entidade emissora. Uma encomenda ou plano contratado antes da alteração não garante que as emissões posteriores conservem a antiga duração.
Antes de emitir um certificado público, a autoridade de certificação verifica o controlo ou a autorização sobre cada domínio ou endereço IP abrangido. As Baseline Requirements fixam os seguintes máximos para reutilizar dados ou validações de domínio e endereço IP:
Assim, a partir de 15 de março de 2029, uma emissão feita 20 dias após a validação anterior não poderá apoiar-se apenas nessa validação. O limite de 10 dias não é a duração do certificado: regula a antiguidade da validação reutilizada numa nova emissão. As autoridades de certificação podem adotar períodos mais curtos. A Sectigo, por exemplo, utiliza 198 dias para a reutilização da validação do domínio desde 12 de março de 2026.
Também não se deve presumir que uma validação efetuada antes da mudança conserva sempre o prazo de reutilização anterior: a DigiCert encurtou o prazo aplicável às validações de domínio existentes ao implementar as regras de 2026.
Sim. A informação de identidade abrangida pelas Baseline Requirements, relevante nomeadamente para certificados OV, passou a ter um máximo geral de 398 dias de reutilização em 15 de março de 2026, distinto do prazo da validação do domínio. A DigiCert aplica, para as organizações OV, um prazo de 397 dias desde 24 de fevereiro de 2026.
Nos certificados EV, as EV Guidelines estabelecem regras adicionais. Várias categorias de informação — incluindo existência legal, identidade e endereço da organização — têm o limite de 398 dias, com as exceções e verificações complementares aí previstas. A validação do domínio acompanha os limites das Baseline Requirements.
Emitir certificados com maior frequência não significa repetir toda a validação empresarial em cada emissão. A autoridade de certificação determina que elementos ainda podem ser aproveitados e quais exigem atualização.
Um certificado representa informação verificada num determinado momento. Ao longo do tempo, podem mudar o controlo do domínio, os dados da organização e as condições de segurança das chaves. Prazos menores reduzem o tempo durante o qual informação desatualizada ou uma emissão indevida pode continuar associada a um certificado temporalmente válido.
A redução também favorece processos de substituição mais frequentes e a capacidade de transição para outros mecanismos criptográficos. Complementa, mas não substitui, a revogação nem a resposta rápida a incidentes. Estas razões são expostas na fundamentação da alteração SC081v3.
Renovar implica obter um novo certificado e colocá-lo efetivamente em utilização. O processo inclui o pedido, as validações necessárias, a emissão, a instalação e a ativação nos servidores, proxies, balanceadores de carga e outros sistemas que apresentam o certificado aos utilizadores.
Uma nova emissão disponível no portal do fornecedor não atualiza automaticamente o certificado instalado. Mesmo quando o plano comercial inclui reemissões, é necessário confirmar a substituição em todos os pontos de terminação TLS. A periodicidade operacional deve deixar margem para corrigir falhas antes da expiração; o limite futuro de 47 dias não impõe, por si só, uma data mensal fixa de renovação.
O protocolo ACME — Automatic Certificate Management Environment permite automatizar a validação de identificadores e a emissão de certificados entre um cliente e uma autoridade de certificação. A compatibilidade e as funcionalidades disponíveis devem ser confirmadas para cada fornecedor, produto e cliente ACME.
Entre os métodos de validação utilizados em ACME encontram-se:
A automatização de DNS-01 exige um mecanismo fiável para atualizar os registos. As credenciais da API de DNS devem ser protegidas e limitadas às permissões estritamente necessárias. É igualmente importante considerar a propagação dos registos e as falhas de validação.
Como preparação operacional, recomenda-se:
Estas medidas acompanham o guia de integração da Let’s Encrypt. Obter um certificado é apenas uma etapa da gestão do seu ciclo de vida.
Uma duração já inferior ao máximo geral não dispensa a revisão da automatização. A Let’s Encrypt anunciou em 7 de outubro de 2026 que, a partir de 10 de fevereiro de 2027, passará a emitir por defeito certificados de 64 dias, em vez de 90, salvo seleção de uma duração ainda menor. Também prevê certificados de 45 dias por defeito em 2028.
Quando suportado pelo cliente, o ACME Renewal Information (ARI) permite à autoridade emissora indicar uma janela adequada de renovação. Agendamentos rígidos, baseados num número fixo de dias antes da expiração, devem ser revistos. A automatização deve incluir a instalação, o recarregamento dos serviços e alertas de falha.
As regras técnicas não determinam a frequência da faturação nem impõem um novo pagamento por cada certificado emitido. Um fornecedor pode manter uma cobertura anual e incluir as substituições necessárias nesse período. As condições concretas dependem do produto, da conta e do contrato; a DigiCert documenta o funcionamento dos seus planos plurianuais.
Num serviço gerido, importa definir quem executa as validações, as novas emissões, a instalação e a monitorização. Devem estar identificados os sistemas abrangidos e as situações que exigem a colaboração do cliente, como alterações no DNS ou atualização dos dados da organização. Esta distribuição de responsabilidades reduz o risco de interrupções durante as substituições sucessivas.
A BITWOCI utiliza IA na elaboração ou revisão dos seus conteúdos, sempre com revisão humana substantiva e sob a sua responsabilidade editorial [artigo 50.º do Regulamento (UE) 2024/1689 (AI Act)].
CA/Browser Forum — Baseline Requirements para certificados TLS de servidor de confiança pública
CA/Browser Forum — Alteração SC081v3 e respetiva fundamentação
CA/Browser Forum — Extended Validation Guidelines
IETF/RFC Editor — RFC 5280, perfil de certificados X.509 e validação da cadeia
IETF/RFC Editor — RFC 8555, protocolo ACME
Let’s Encrypt — anúncio da redução para certificados de 64 dias em fevereiro de 2027
