Certificados DV vs OV vs EV: o que a validação oferece

DV vs OV vs EV descreve o quanto uma autoridade certificadora verificou antes de emitir um certificado TLS. A validação de domínio comprova o controle dos nomes; a validação de organização acrescenta a identidade jurídica da empresa; a validação estendida acrescenta uma verificação de identidade mais rigorosa, regida por diretrizes próprias. A criptografia é idêntica, os navegadores exibem os três da mesma forma e, desde 2019, as diferenças importam principalmente para pessoas e sistemas que leem os detalhes do certificado.

Visão geral

O que cada nível comprova

A validação de domínio comprova que quem solicitou o certificado controlava o domínio naquele momento: servindo um token por HTTP (http-01), publicando um registro TXT no DNS (dns-01), respondendo a um desafio TLS-ALPN ou por um dos outros métodos listados nos Baseline Requirements §3.2.2.4. Desde 2025, as CAs devem corroborar essas verificações a partir de várias perspectivas de rede, de modo que sequestrar o DNS ou o roteamento BGP na direção de um único ponto de observação já não basta para obter um certificado. Um certificado DV não diz nada sobre quem opera o site; um domínio de phishing obtém um com a mesma facilidade que um banco.

A validação de organização acrescenta ao titular do certificado a razão social, a localidade e o país verificados do solicitante, depois de confrontá-los com registros oficiais e com dados de contato confirmados. A validação estendida aplica um processo mais rigoroso e prescritivo, que abrange números de registro, a jurisdição de constituição, a existência operacional e a verificação da pessoa que aprova a solicitação, e registra o resultado em atributos específicos do titular.

O que nenhum deles comprova: que o site é seguro, que a organização é honesta ou que a pessoa com quem você está falando é quem diz ser.

Como saber qual deles um site usa

O OID da política na extensão Certificate Policies indica o nível de validação; o titular mostra o que foi verificado. Este script, executado em 20 de outubro de 2026 com o OpenSSL 3.6.5, lê as duas informações em três sites em produção.

for host in letsencrypt.org www.microsoft.com www.paypal.com; do
  echo "== $host"
  openssl s_client -connect "$host:443" -servername "$host" </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -ext certificatePolicies
done

== letsencrypt.org
subject=CN=letsencrypt.org
X509v3 Certificate Policies: 
    Policy: 2.23.140.1.2.1
== www.microsoft.com
subject=C=US, ST=WA, L=Redmond, O=Microsoft Corporation, CN=www.microsoft.com
X509v3 Certificate Policies: 
    Policy: 1.3.6.1.4.1.311.76.509.1.1
      CPS: http://www.microsoft.com/pkiops/Docs/Repository.htm
    Policy: 2.23.140.1.2.2
== www.paypal.com
subject=jurisdictionC=US, jurisdictionST=Delaware, businessCategory=Private Organization, serialNumber=3014267, C=US, ST=California, L=San Jose, O=PayPal, Inc., CN=www.paypal.com
X509v3 Certificate Policies: 
    Policy: 2.16.840.1.114412.2.1
    Policy: 2.23.140.1.1
      CPS: http://www.digicert.com/CPS

O primeiro é DV (só um nome), o segundo é OV (organização e endereço) e o terceiro é EV (jurisdição de constituição, categoria do negócio e número de registro). Os OIDs extras são identificadores de política próprios de cada CA. O decodificador de certificados mostra os mesmos campos para um PEM colado.

O que os navegadores mostram

Antes, os navegadores exibiam os certificados EV com uma barra verde e o nome da empresa. Estudos constataram que os usuários raramente notavam o indicador ou a ausência dele e não mudavam de comportamento por causa dele, e pesquisadores demonstraram que empresas juridicamente distintas conseguiam obter certificados EV para nomes confusamente parecidos com marcas conhecidas. O Safari 12 removeu o nome da barra de endereços em 2018; o Chrome 77 (setembro de 2019) e o Firefox 70 (outubro de 2019) moveram os detalhes do EV para o painel de informações da página. Hoje os três níveis mostram o mesmo cadeado, e a organização só aparece quando o usuário abre os detalhes do certificado.

Diferenças operacionais

A vida útil e a reutilização da validação estão diminuindo para todos. Pela votação SC-081v3, os certificados emitidos a partir de 15 de março de 2026 podem ter validade de no máximo 200 dias, caindo para 100 dias em março de 2027 e para 47 dias em março de 2029; a validação de domínio pode ser reutilizada por 200 dias hoje e por apenas 10 dias a partir de março de 2029, enquanto as informações de identidade da organização podem ser reutilizadas por 398 dias. Por isso, todo certificado público precisa de renovação automatizada, e o OV e o EV acrescentam, além da mesma automação, uma etapa periódica de nova verificação da identidade.

O ACME em si valida apenas o controle do domínio. Algumas CAs comerciais aceitam pedidos ACME de certificados OV e EV vindos de contas vinculadas a uma organização previamente verificada por meio do External Account Binding (RFC 8555 §7.3.4), o que permite às empresas automatizar as renovações depois de uma verificação manual inicial da identidade. O Certificate Transparency registra todo certificado TLS publicamente confiável, então os dados da organização nos certificados OV e EV se tornam públicos assim que eles são emitidos.

Quando escolher cada um

• Sites e APIs públicos: DV, automatizado com ACME. Invista o esforço economizado em HSTS, registros CAA e monitoramento de CT.
• Contratos, órgãos reguladores ou parceiros que exigem um titular de certificado identificado (algumas integrações de pagamento, bancárias e governamentais): OV, ou EV onde ele for especificado.
• Sistemas clientes que comparam o nome da organização em um certificado: OV, mas, nessas integrações, prefira fixar as chaves ou usar uma CA privada.
• Serviços internos e mTLS: nenhum dos três; use uma CA privada.
• Assinatura de código: um produto à parte, com regras de validação próprias e chaves protegidas por hardware (exigidas desde junho de 2023), e não um OV ou EV de TLS.
• Proteção de marca: registros CAA, monitoramento de CT e gestão do portfólio de domínios tratam de forma mais direta os riscos que o EV deveria tratar.

Notas de migração

1. A migração de EV ou OV para DV normalmente não exige nenhuma mudança no servidor além do certificado: solicite um certificado DV para os mesmos nomes (com uma chave nova, de preferência ECDSA P-256), implante-o com a cadeia completa e deixe o antigo expirar.
2. Verifique dependências dos campos do titular: listas de permissões de clientes, regras de monitoramento ou integrações de parceiros que comparam O= vão parar de funcionar com DV.
3. Automatize primeiro: a renovação manual já é um risco com 200 dias e não vai dar conta com 47 dias, seja qual for o nível de validação.
4. Publique registros CAA para que só as CAs que você escolheu possam emitir, e vincule-os à sua conta ACME com accounturi (RFC 8657); o gerador de registros CAA monta esses registros.
5. Acompanhe o CT: um monitor de Certificate Transparency lista os certificados emitidos para seus nomes, então uma emissão inesperada em qualquer nível fica visível (Certificate Transparency para desenvolvedores).

Referências

• Baseline Requirements do CA/Browser Forum (§3.2.2, §3.2.2.4, §7.1.6.1)
• EV Guidelines do CA/Browser Forum
• Votação SC-081v3, redução dos períodos de validade e de reutilização de dados
• Votação SC-067v3, corroboração da emissão a partir de múltiplas perspectivas
• RFC 8555, ACME
• RFC 8659, CAA e RFC 8657, vinculação de conta no CAA