Certificats DV vs OV vs EV : ce qu’apporte la validation

DV vs OV vs EV indique jusqu’où une autorité de certification (AC) a poussé ses vérifications avant d’émettre un certificat TLS. La validation de domaine prouve le contrôle des noms ; la validation de l’organisation y ajoute l’identité juridique de l’entreprise ; la validation étendue ajoute un contrôle d’identité plus strict, selon des lignes directrices distinctes. La cryptographie est identique, les navigateurs affichent les trois de la même façon, et depuis 2019, les différences comptent surtout pour les personnes et les systèmes qui lisent les détails des certificats.

Vue d’ensemble

Ce que prouve chaque niveau

La validation de domaine prouve que l’auteur de la demande de certificat contrôlait le domaine à ce moment-là : en servant un jeton via HTTP (http-01), en publiant un enregistrement TXT dans le DNS (dns-01), en répondant à un challenge TLS-ALPN, ou par l’une des autres méthodes énumérées dans les Baseline Requirements, §3.2.2.4. Depuis 2025, les AC doivent corroborer ces contrôles depuis plusieurs perspectives réseau, si bien que détourner le DNS ou le routage BGP vers un seul point d’observation ne suffit plus pour obtenir un certificat. Un certificat DV ne dit rien de l’exploitant du site : un domaine d’hameçonnage en obtient un aussi facilement qu’une banque.

La validation de l’organisation ajoute au sujet du certificat la dénomination légale vérifiée, la localité et le pays du demandeur, après des contrôles fondés sur des registres officiels et des coordonnées vérifiées. La validation étendue applique un processus plus strict et prescriptif, qui couvre les numéros d’enregistrement, la juridiction d’immatriculation, l’existence opérationnelle et la vérification de la personne qui approuve la demande, le tout consigné dans des attributs dédiés du sujet.

Ce qu’aucun d’eux ne prouve : que le site est sans danger, que l’organisation est honnête, ou que votre interlocuteur est bien celui qu’il prétend être.

Comment savoir lequel un site utilise

L’OID de politique figurant dans l’extension Certificate Policies indique le niveau de validation ; le sujet montre ce qui a été vérifié. Ce script, exécuté le 20 octobre 2026 avec OpenSSL 3.6.5, lit les deux sur trois sites en ligne.

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

Le premier est DV (un nom seulement), le deuxième OV (organisation et adresse), le troisième EV (juridiction d’immatriculation, catégorie d’entreprise et numéro d’enregistrement). Les OID supplémentaires sont les identifiants de politique propres à chaque AC. Le décodeur de certificats affiche les mêmes champs pour un PEM collé.

Ce qu’affichent les navigateurs

Les navigateurs affichaient autrefois les certificats EV avec une barre verte et le nom de l’entreprise. Des études ont constaté que les utilisateurs remarquaient rarement l’indicateur ou son absence et ne modifiaient pas leur comportement en conséquence, et des chercheurs ont montré que des sociétés juridiquement distinctes pouvaient obtenir des certificats EV pour des noms prêtant à confusion avec des marques connues. Safari 12 a retiré le nom de la barre d’adresse en 2018 ; Chrome 77 (septembre 2019) et Firefox 70 (octobre 2019) ont déplacé les détails EV dans le panneau d’informations de la page. Aujourd’hui, les trois niveaux affichent le même cadenas, et l’organisation n’apparaît que lorsqu’un utilisateur ouvre les détails du certificat.

Différences opérationnelles

Les durées de vie et la réutilisation des validations diminuent pour tout le monde. Selon le vote SC-081v3, les certificats émis à partir du 15 mars 2026 peuvent être valides 200 jours au plus, durée ramenée à 100 jours en mars 2027 puis à 47 jours en mars 2029 ; la validation de domaine peut être réutilisée pendant 200 jours aujourd’hui et pendant 10 jours seulement à partir de mars 2029, tandis que les informations d’identité de l’organisation peuvent être réutilisées pendant 398 jours. Tout certificat public a donc besoin d’un renouvellement automatisé, et OV et EV ajoutent une étape périodique de nouvelle vérification d’identité en plus de cette même automatisation.

ACME lui-même ne valide que le contrôle du domaine. Certaines AC commerciales acceptent des commandes ACME de certificats OV et EV provenant de comptes liés, par External Account Binding (RFC 8555 §7.3.4), à une organisation vérifiée au préalable, ce qui permet aux entreprises d’automatiser les renouvellements après une première vérification manuelle de l’identité. Certificate Transparency journalise chaque certificat TLS de confiance publique, si bien que les informations d’organisation des certificats OV et EV deviennent publiques dès leur émission.

Lequel choisir, et quand

• Sites web et API publics : DV, automatisé avec ACME. Consacrez l’effort économisé à HSTS, aux enregistrements CAA et à la surveillance CT.
• Contrats, régulateurs ou partenaires qui exigent un sujet de certificat identifié (certaines intégrations de paiement, bancaires et gouvernementales) : OV, ou EV lorsqu’il est spécifié.
• Systèmes clients qui comparent le nom de l’organisation figurant dans un certificat : OV, mais pour ces intégrations, préférez l’épinglage de clés ou une AC privée.
• Services internes et mTLS : aucun des trois ; utilisez une AC privée.
• Signature de code : un produit distinct, avec ses propres règles de validation et des clés protégées par du matériel (obligatoires depuis juin 2023), et non un certificat TLS OV ou EV.
• Protection de la marque : les enregistrements CAA, la surveillance CT et la gestion du portefeuille de noms de domaine traitent plus directement les risques auxquels EV devait répondre.

Notes de migration

1. Passer d’EV ou d’OV à DV ne demande généralement aucune modification sur le serveur en dehors du certificat : demandez un certificat DV pour les mêmes noms (avec une nouvelle clé, idéalement ECDSA P-256), déployez-le avec la chaîne complète et laissez l’ancien expirer.
2. Vérifiez les dépendances aux champs du sujet : les listes d’autorisation des clients, les règles de surveillance ou les intégrations de partenaires qui comparent O= ne fonctionneront plus avec DV.
3. Automatisez d’abord : le renouvellement manuel est déjà un risque à 200 jours et ne pourra pas suivre à 47 jours, quel que soit le niveau de validation.
4. Définissez des enregistrements CAA pour que seules les AC que vous avez choisies puissent émettre, et liez-les à votre compte ACME avec accounturi (RFC 8657) ; le générateur d’enregistrements CAA les construit.
5. Surveillez CT : un outil de surveillance Certificate Transparency liste les certificats émis pour vos noms, ce qui rend visible toute émission inattendue, quel que soit le niveau (Certificate Transparency pour les développeurs).

Références

• Baseline Requirements du CA/Browser Forum (§3.2.2, §3.2.2.4, §7.1.6.1)
• EV Guidelines du CA/Browser Forum
• Vote SC-081v3, réduction des durées de validité et de réutilisation des données
• Vote SC-067v3, corroboration de l’émission depuis plusieurs perspectives réseau
• RFC 8555, ACME
• RFC 8659, CAA et RFC 8657, liaison de CAA à un compte