Certificados DV, OV y EV: el valor real de la validación

DV frente a OV frente a EV es una cuestión de cuánto verificó una autoridad de certificación antes de emitir un certificado TLS. La validación de dominio demuestra el control de los nombres; la validación de organización añade la identidad jurídica de la empresa; la validación extendida añade una comprobación de identidad más estricta, regida por unas directrices propias. La criptografía es idéntica, los navegadores muestran los tres de la misma forma y, desde 2019, las diferencias importan sobre todo a las personas y los sistemas que leen los detalles del certificado.

De un vistazo

Qué demuestra cada nivel

La validación de dominio demuestra que quien solicitó el certificado controlaba el dominio en ese momento: sirviendo un token por HTTP (http-01), publicando un registro TXT de DNS (dns-01), respondiendo a un desafío TLS-ALPN o mediante alguno de los otros métodos que enumera el §3.2.2.4 de los Baseline Requirements. Desde 2025, las CA deben corroborar estas comprobaciones desde varias perspectivas de red, así que secuestrar el DNS o el enrutamiento BGP hacia un único punto de observación ya no basta para obtener un certificado. Un certificado DV no dice nada sobre quién opera el sitio: un dominio de phishing lo obtiene con la misma facilidad que un banco.

La validación de organización añade al sujeto del certificado el nombre legal, la localidad y el país verificados del solicitante, tras cotejarlos con registros oficiales y con datos de contacto verificados. La validación extendida aplica un proceso más estricto y pautado que abarca los números de registro, la jurisdicción de constitución, la existencia operativa y la verificación de la persona que aprueba la solicitud, y lo que comprueba queda registrado en atributos específicos del sujeto.

Lo que ninguno de ellos demuestra: que el sitio sea seguro, que la organización sea honesta o que la persona con la que hablas sea quien dice ser.

Cómo saber cuál usa un sitio

El OID de política de la extensión Certificate Policies indica el nivel de validación; el sujeto muestra qué se verificó. Este script, ejecutado el 20 de octubre de 2026 con OpenSSL 3.6.5, lee ambos datos de tres sitios reales.

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

El primero es DV (solo un nombre), el segundo OV (organización y dirección) y el tercero EV (jurisdicción de constitución, categoría de empresa y número de registro). Los OID adicionales son identificadores de política propios de cada CA. El decodificador de certificados muestra los mismos campos para un PEM pegado.

Qué muestran los navegadores

Hubo un tiempo en que los navegadores mostraban los certificados EV con una barra verde y el nombre de la empresa. Varios estudios concluyeron que los usuarios rara vez se fijaban en el indicador o en su ausencia y que no cambiaban su comportamiento por ello, y unos investigadores demostraron que empresas jurídicamente distintas podían obtener certificados EV para nombres que se confundían fácilmente con marcas conocidas. Safari 12 quitó el nombre de la barra de direcciones en 2018; Chrome 77 (septiembre de 2019) y Firefox 70 (octubre de 2019) trasladaron los detalles EV al panel de información de la página. Hoy los tres niveles muestran el mismo candado, y la organización solo aparece cuando el usuario abre los detalles del certificado.

Diferencias operativas

La vida útil y la reutilización de la validación se están reduciendo para todos. Según la votación SC-081v3, los certificados emitidos desde el 15 de marzo de 2026 pueden ser válidos durante 200 días como máximo, que bajan a 100 días en marzo de 2027 y a 47 días en marzo de 2029; la validación de dominio puede reutilizarse durante 200 días ahora y solo durante 10 días a partir de marzo de 2029, mientras que la información sobre la identidad de la organización puede reutilizarse durante 398 días. Por eso todo certificado público necesita una renovación automatizada, y OV y EV añaden, sobre esa misma automatización, un paso periódico de nueva verificación de la identidad.

ACME por sí mismo solo valida el control del dominio. Algunas CA comerciales aceptan pedidos ACME de certificados OV y EV desde cuentas vinculadas mediante External Account Binding (RFC 8555 §7.3.4) a una organización ya verificada, lo que permite a las empresas automatizar las renovaciones tras una comprobación manual inicial de la identidad. Certificate Transparency registra todos los certificados TLS de confianza pública, así que los detalles de la organización de los certificados OV y EV se hacen públicos en cuanto se emiten.

Cuándo elegir cada uno

• Sitios web públicos y API: DV, automatizado con ACME. Dedica el esfuerzo ahorrado a HSTS, a los registros CAA y a la monitorización de CT.
• Contratos, reguladores o socios que exigen un sujeto de certificado identificado (algunas integraciones de pagos, banca y administración pública): OV, o EV donde se especifique.
• Sistemas cliente que comparan el nombre de la organización de un certificado: OV, aunque en esas integraciones es preferible la fijación de claves (pinning) o una CA privada.
• Servicios internos y mTLS: ninguno de los tres; usa una CA privada.
• Firma de código: un producto aparte, con sus propias normas de validación y claves protegidas por hardware (obligatorias desde junio de 2023), no OV o EV de TLS.
• Protección de la marca: los registros CAA, la monitorización de CT y la gestión de la cartera de dominios abordan de forma más directa los riesgos que EV pretendía abordar.

Notas de migración

1. Pasar de EV u OV a DV no suele requerir cambios en el servidor más allá del certificado: solicita un certificado DV para los mismos nombres (con una clave nueva, idealmente ECDSA P-256), despliégalo con la cadena completa y deja que el antiguo caduque.
2. Comprueba las dependencias de los campos del sujeto: las listas de permitidos de los clientes, las reglas de monitorización o las integraciones de socios que comparan O= dejarán de funcionar con DV.
3. Automatiza primero: la renovación manual ya es un riesgo con 200 días y no podrá seguir el ritmo con 47 días, sea cual sea el nivel de validación.
4. Configura registros CAA para que solo las CA que elijas puedan emitir, y vincúlalos a tu cuenta ACME con accounturi (RFC 8657); el generador de registros CAA los crea.
5. Vigila CT: un servicio de monitorización de Certificate Transparency enumera los certificados emitidos para tus nombres, de modo que cualquier emisión inesperada, del nivel que sea, queda a la vista (Certificate Transparency para desarrolladores).

Referencias

• Baseline Requirements del CA/Browser Forum (§3.2.2, §3.2.2.4, §7.1.6.1)
• EV Guidelines del CA/Browser Forum
• Votación SC-081v3, reducción de la validez y de la reutilización de datos
• Votación SC-067v3, corroboración de la emisión desde varias perspectivas
• RFC 8555, ACME
• RFC 8659, CAA y RFC 8657, vinculación de cuenta en CAA