TL;DR: Com prazos de validade cada vez mais curtos (47 dias até 2029), separação obrigatória de EKU para mTLS e a chegada iminente da criptografia pós-quântica, times de segurança brasileiros precisam repensar a gestão de certificados. A automação total de renewals, a migração de client auth para PKI privada e a preparação para algoritmos PQC não são mais opcionais — são requisitos operacionais para evitar riscos de indisponibilidade, violações de compliance e exposição a ataques 'harvest now, decrypt later'. O guia abaixo detalha as melhores práticas separadas para certificados públicos e privados.
As regras dos certificados estão mudando mais rápido do que a maioria dos times imagina
Mudanças na indústria — como prazos de validade mais curtos, criptografia pós-quântica e identidades de máquina para agentes de IA e workloads automatizadas — estão redefinindo o que significa "boa prática". Este guia percorre o que você precisa saber, separado claramente entre a gestão de certificados públicos e privados.
A indústria está se movendo: o que está mudando
Antes de mergulhar nas melhores práticas, três mudanças merecem destaque explícito.
Separação de EKU — O CA/B Forum está removendo a extended key usage (EKU) de Client Authentication de todos os certificados TLS públicos. Se sua organização usa atualmente um certificado TLS público para mutual TLS (mTLS) ou autenticação de cliente, esses casos de uso devem migrar para PKI privada. Sites HTTPS padrão não são afetados — essa mudança só importa se você estiver rodando client auth em certificados públicos.
Prazos de validade mais curtos estão chegando para certificados públicos. O CA/B Forum definiu um cronograma claro: validade máxima de 200 dias a partir de março de 2026, 100 dias em março de 2027 e 47 dias até março de 2029. A implicação prática é que a renovação manual de certificados não é mais um modelo operacional viável. Automação é mandatória.
Janela de preparação para criptografia pós-quântica (PQC) é agora. O NIST finalizou três algoritmos em 2024: ML-KEM (FIPS 203), ML-DSA (FIPS 204) e SLH-DSA (FIPS 205). A preocupação mais urgente é o ataque "harvest now, decrypt later": adversários estão coletando ativamente tráfego criptografado hoje com a intenção de descriptografá-lo quando o hardware quântico amadurecer.
Certificados públicos vs. certificados privados
Clientes frequentemente confundem esses dois mundos.
Certificados TLS públicos são emitidos por Autoridades Certificadoras públicas e ancorados em trust stores embarcados em navegadores e sistemas operacionais. Isso significa que eles precisam cumprir os requisitos do CA/Browser Forum e as políticas dos programas de root store. As mudanças de EKU e prazos de validade mais curtos se aplicam exclusivamente a esses certificados.
Certificados privados operam inteiramente sob sua própria política. Eles não estão sujeitos às regras dos programas de root store de navegadores. Operam sob a governança PKI da própria organização, oferecendo flexibilidade para definir EKUs, períodos de validade e hierarquia de CA adequados para casos de uso internos, como autenticação de cliente, identidade de dispositivos, service mesh e VPN. No entanto, a organização precisa estabelecer e aplicar salvaguardas equivalentes (como política de emissão, escopo de EKU, constraints de nome/pathlength, proteção de chaves, auditoria e rotação/revogação automatizadas) para reduzir o risco de certificados excessivamente permissivos ou emissão incorreta. A PKI privada é cada vez mais o local arquiteturalmente correto para client authentication, identidade de dispositivos, service mesh interno, VPN e code signing. Organizações que já operam sua própria PKI privada não precisam substituir modelos de confiança existentes para adotar estas melhores práticas. Uma abordagem Bring Your Own CA (BYOCA) permite que empresas integrem suas Autoridades Certificadoras raiz ou subordinadas existentes em fluxos modernos de cloud e automação, preservando políticas de confiança internas, controles de governança e requisitos de compliance.
Melhores práticas: Certificados públicos
Automatize a renovação de ponta a ponta
Com a validade caindo para 47 dias até 2029, nenhum time consegue gerenciar renovações manuais de certificados públicos de forma sustentável. Ferramentas baseadas em ACME devem ser o modelo operacional padrão. Cada certificado deve renovar sem intervenção humana. Fique de olho nos blogs da Oracle para futuros anúncios sobre isso.
Aja sobre a remoção de EKU antes de maio de 2026
Audite seu inventário de certificados agora para qualquer certificado público que carregue a EKU clientAuth. Se você os usa para mTLS, autenticação de dispositivos ou qualquer autenticação no lado do cliente, crie um plano de migração para PKI privada.
Configure os registros CAA DNS corretos
Registros Certificate Authority Authorization permitem que você designe, no nível de DNS, quais CAs estão autorizadas a emitir certificados para seu domínio. É um controle de baixo esforço e alto valor que ajuda a evitar que CAs públicas emitam certificados para seu domínio sem autorização.
Monitore logs de Certificate Transparency
Todo certificado público emitido é registrado em logs CT públicos. Assine serviços de monitoramento que alertam quando qualquer novo certificado é emitido para seus domínios. Este é seu sistema de alerta precoce para emissão incorreta e certificados não autorizados.
Implante sempre a cadeia completa de certificados
Ao instalar um certificado, inclua a cadeia completa — certificado folha junto com todos os certificados intermediários, em ordem. Intermediários ausentes podem fazer com que navegadores/clientes rejeitem a conexão silenciosamente, e o erro é frequentemente mal diagnosticado.
Force apenas TLS 1.2 e 1.3
SSL 3.0, TLS 1.0 e TLS 1.1 estão obsoletos e inseguros. Force TLS 1.2 e TLS 1.3 hoje, e trate TLS 1.3 como o estado alvo para TLS pronto para PQC.
Use SAN corretamente; pare de depender do Common Name
A validação moderna de TLS é orientada por SAN. A orientação atual do OWASP observa explicitamente que navegadores modernos ignoram o Common Name e dependem do Subject Alternative Name (SAN). Portanto, a boa prática é garantir que todo certificado público seja emitido com os nomes DNS exatos que os clientes usarão e parar de pensar no CN como fonte de identidade.
Prefira validação baseada em DNS e planeje revalidações frequentes
Com as janelas de reutilização de dados de validação diminuindo, as empresas devem assumir que a validação de controle de domínio ocorrerá com mais frequência, não menos. Isso torna a validação baseada em DNS o padrão mais prático para empresas, porque é mais fácil automatizar repetidamente do que processos baseados em e-mail e funciona bem com fluxos de trabalho wildcard ou multi-ambiente. O ponto mais amplo é que a própria validação está se tornando parte do loop de automação em tempo de execução.
Evite a proliferação de wildcards amplos
Isso não é um padrão novo, mas torna-se mais importante sob automação com prazos curtos. Wildcards são operacionalmente convenientes, mas expandem o raio de explosão e frequentemente escondem a propriedade. O padrão empresarial melhor é certificados específicos por serviço ou endpoint sempre que prático, com wildcards usados apenas onde há uma necessidade justificada de plataforma.
Melhores práticas: Certificados privados
A hierarquia recomendada
Uma PKI privada bem projetada segue um modelo de três camadas.
Camada 1 — Root CA é a âncora de confiança para toda a sua hierarquia. Essas CAs devem estar sob controles de acesso rigorosos. É usada apenas para assinar certificados de CA subordinada. A chave da Root CA deve residir em um módulo de segurança de hardware (HSM) certificado FIPS 140-2 ou 140-3. O OCI KMS suporta algoritmos de chave RSA e ECDSA. Validade recomendada: até 10 anos. Chave recomendada: ECDSA, pois oferece o mesmo nível de segurança que RSA com chaves muito menores, resultando em handshakes TLS mais rápidos e menor uso de CPU.
Camada 2 — Subordinate CAs fazem o trabalho diário de emitir certificados. Você deve ter pelo menos uma, e a maioria das organizações se beneficia de duas ou mais, separadas por caso de uso: uma para serviços internos e mTLS, outra para autenticação de usuário e code signing. Mantê-las separadas significa que um comprometimento de uma CA emissora não expõe todos os tipos de certificado. Validade: 3 a 5 anos. Chave recomendada: ECDSA. As chaves devem residir em HSMs com controles de acesso rigorosos.
Camada 3 — Leaf / End-Entity Certificates são emitidos para servidores, dispositivos, usuários e aplicações. Estes são os certificados que são renovados com frequência e devem ser automatizados. O OCI suporta algoritmos de chave RSA e ECDSA. Validade recomendada: 90 dias. Chave recomendada: ECDSA. Nota: a renovação automática do OCI Certificates se aplica a certificados emitidos e gerenciados pelo OCI Certificates. Certificados importados ou gerenciados externamente precisam de seu próprio caminho de automação.
Certificados de curta duração para ambientes de alta escala
A recomendação de 90 dias para certificados folha privados é um piso, não um alvo. Para ambientes de alta escala e alta rotatividade, como microsserviços, a faixa de validade correta é de algumas horas a uma semana. Em arquiteturas modernas de cloud e microsserviços, onde workloads são efêmeras e escalam dinamicamente, os certificados funcionam principalmente como identidades de máquina, não como credenciais de longo prazo. A boa prática é emitir certificados de curta duração com validade de algumas horas a uma semana para sistemas de alta escala, como microsserviços, containers e service meshes. Essa abordagem reduz significativamente a dependência de mecanismos de revogação como CRLs, porque credenciais comprometidas expiram naturalmente em pouco tempo.
Defina e force perfis de certificado
Cada caso de uso de certificado — server TLS, client auth, code signing, email — deve ter um template bloqueado que especifique EKUs permitidas, flags de key usage e requisitos de SAN. CAs emissoras devem ser capazes de produzir apenas certificados que correspondam a um perfil definido. Isso impede que um certificado de servidor seja acidental ou maliciosamente usado para code signing. As políticas de referência de certificado do OCI podem ajudar você a entender como controlar alguns desses casos de uso via Auth.
Publique uma CRL acessível
Garanta que sua infraestrutura de revogação seja acessível. Se não for, o ponto de distribuição de CRL de uma CA não oferece cobertura de revogação na prática. Teste seus endpoints de revogação regularmente e monitore sua disponibilidade. Configure suas CRLs adequadamente usando object buckets no OCI.
Audite operações de CA em um cronograma definido
Aplique least-privilege a todos com acesso de operador de CA. Registre todos os eventos de emissão de certificados com trilhas de auditoria imutáveis. Revise periodicamente padrões anômalos — tipos de certificado inesperados, valores de SAN incomuns, emissão fora do horário comercial.
Perguntas Frequentes
-
O que muda com a separação de EKU para certificados públicos?
- O CA/B Forum está removendo a extended key usage (EKU) de Client Authentication de todos os certificados TLS públicos. Isso significa que quem usa certificados públicos para mTLS ou autenticação de cliente precisará migrar esses casos para uma PKI privada. Sites HTTPS padrão não são afetados.
-
É viável gerenciar certificados manualmente com validade de 47 dias?
- Não. A partir de março de 2029, a validade máxima será de 47 dias. Nenhum time consegue renovar manualmente nessa frequência de forma confiável. A automação com ACME e ferramentas similares se torna mandatória — não uma opção.
-
O que devo fazer agora para me preparar para a criptografia pós-quântica?
- O maior risco atual é o ataque 'harvest now, decrypt later': atacantes coletam tráfego criptografado hoje para descriptografar quando hardware quântico estiver disponível. Comece migrando para TLS 1.3, que já suporta algoritmos PQC, e acompanhe a padronização dos algoritmos ML-KEM, ML-DSA e SLH-DSA do NIST.
-
Em quais cenários devo usar certificados privados em vez de públicos?
- Sempre que houver necessidade de client authentication (mTLS), identidade de dispositivos, service mesh interno, VPN ou code signing, o local arquiteturalmente correto é a PKI privada. Certificados públicos terão a EKU de Client Authentication removida, e a PKI privada oferece mais flexibilidade e controle sobre políticas de emissão.
-
Qual é a hierarquia recomendada para uma PKI privada?
- O padrão é o modelo de três camadas: Root CA (validade de até 10 anos, chave ECDSA, em HSM), Subordinate CAs separadas por caso de uso (validade de 3 a 5 anos) e Leaf certificates de vida curta (90 dias ou menos, idealmente horas a semanas para microsserviços). Isso isola riscos e facilita automação.
Artigo originalmente publicado por Meghana Vyakaranam em cloud-infrastructure.
