Educational Beginner 9 min read

DV vs OV vs EV : les niveaux de validation des certificats

DV, OV et EV désignent les trois niveaux de validation qu'une CA publiquement reconnue peut délivrer. Ils se distinguent par ce que la CA vérifie auprès du demandeur avant de signer, pas par la cryptographie. Ce guide explique les règles, la réalité opérationnelle et les cas où chaque niveau reste pertinent.

En bref

Type
Educational
Niveau
Beginner
Suivant
Le protocole ACME

Vue d'ensemble

Les certificats TLS publiquement reconnus se déclinent en trois classes de validation — validation du domaine (DV), validation de l'organisation (OV) et validation étendue (EV) — définies par les Baseline Requirements du CA/Browser Forum pour les deux premières et par les EV SSL Guidelines pour la troisième. Cette classification porte sur le processus d'émission, non sur la cryptographie obtenue : la clé publique, l'algorithme de signature et la chaîne de confiance sont identiques aux trois niveaux.

Ce qui change, c'est ce que l'autorité de certification confirme avant de signer. La DV prouve que le demandeur contrôle le domaine. L'OV ajoute la preuve qu'une entité juridique réelle, dûment immatriculée, se tient derrière ce domaine. L'EV superpose une vérification approfondie de l'existence de cette entité, de son historique et de l'autorité de la personne qui demande le certificat. Le champ Subject reflète cette profondeur : vide en DV, nommé en OV, nommé et localisé juridiquement en EV.

Depuis 2019, le signal visuel qui justifiait autrefois le surcoût de l'EV — la barre d'adresse verte avec le nom de l'entreprise — a disparu de Chrome et de Firefox. Ce qui demeure, c'est l'identité de l'organisation à l'intérieur du certificat lui-même, utile pour les flux régulés, les contextes eIDAS qualifiés et tout vérificateur qui lit réellement le Subject. Lisez ce guide en parallèle des certificats TLS/SSL et des autorités de certification pour comprendre qui émet ces certificats et comment fonctionne l'ensemble du modèle de confiance.

Un certificat est, en définitive, une attestation. Une autorité de certification reçoit une demande, vérifie un ensemble de faits et signe un énoncé structuré disant « cette clé publique appartient à ce sujet, et voici ce que j'ai contrôlé avant de l'affirmer ». Le niveau de validation — DV, OV ou EV — résume la profondeur de cette vérification. Deux certificats émis par la même CA, sur le même matériel, avec la même courbe elliptique et la même durée de vie de 47 jours, peuvent reposer sur des volumes de revue humaine radicalement différents. Cette différence est invisible côté handshake TLS, mais elle est la raison d'être des trois niveaux.

Sur la majeure partie du Web public, la DV est devenue le réglage par défaut. L'émission gratuite et automatisée de Let's Encrypt, le protocole ACME et la marche vers les certificats à 47 jours ont rendu plus lourd, à l'usage, tout niveau supérieur à la DV. L'OV et l'EV restent émis en volume, mais les raisons de les choisir se sont resserrées — et ont changé de nature. Elles tiennent désormais moins à ce que les navigateurs affichent à l'utilisateur qu'à ce que les auditeurs, les régulateurs et les consommateurs machines peuvent lire dans le Subject du certificat lui-même.

Les trois niveaux de validation

Les Baseline Requirements sont versionnées et resserrées à intervalles réguliers ; la série en vigueur est la v2.x. Toute référence à un numéro de section précis doit être recroisée avec la version applicable au moment où vous lisez : le document évolue plusieurs fois par an au gré des ballots adoptés par le CA/Browser Forum.

1

DV — Validation du domaine

La CA confirme une seule chose : que le demandeur contrôle le domaine porté sur le certificat. La vérification se fait par l'une des méthodes listées à la section 3.2.2.4 des Baseline Requirements — le plus souvent un challenge ACME en HTTP, DNS ou TLS-ALPN. Aucun contact humain n'est requis. L'émission prend de quelques secondes à quelques minutes. Le prix indicatif va de la gratuité (Let's Encrypt, ZeroSSL, Google Trust Services) à quelques dizaines d'euros par an chez les CA commerciales. Le Subject ne contient que le Common Name ; le champ Organisation est vide.

2

OV — Validation de l'organisation

La CA vérifie d'abord le contrôle du domaine, puis confirme qu'une entité juridique réelle existe et que la demande a bien été faite en son nom. L'identité est validée via les registres officiels et des sources d'information indépendantes qualifiées (D&B, chambres de commerce, bases publiques), comme l'exigent les BR §3.2.2.1 et §3.2.5. L'émission prend généralement un à trois jours ouvrés. Le prix indicatif se situe entre 60 € et 250 € par an. Le Subject inclut le nom d'organisation vérifié, la localité, la région et le pays.

3

EV — Validation étendue

La CA effectue la validation du domaine, puis le contrôle approfondi prescrit par les EV SSL Guidelines du CA/Browser Forum : existence légale de l'organisation depuis au moins trois ans (ou preuves alternatives), adresse physique, existence opérationnelle et autorisation explicite d'un signataire nommément désigné qui confirme la demande. L'émission prend couramment trois à dix jours ouvrés. Le prix indicatif se situe entre 150 € et 1 000 € par an. Le Subject inclut l'organisation, la juridiction d'incorporation, le numéro d'immatriculation et la catégorie d'activité.

Ce que chaque niveau vérifie réellement

L'enjeu de ces cartes n'est pas la bureaucratie en elle-même — c'est que le certificat, une fois émis, transporte cette bureaucratie comme une affirmation vérifiable. Un auditeur lisant un certificat EV plusieurs années plus tard peut se demander « la CA a-t-elle effectivement appliqué le §11 des EV Guidelines ? », et les journaux de Certificate Transparency lui permettent d'y répondre sans se fier à la parole de la CA.

Contrôles DV

Preuve purement technique du contrôle du domaine. La CA choisit l'une des méthodes des BR §3.2.2.4 — modification convenue sur le site web, enregistrement DNS CNAME ou TXT, e-mail vers une adresse construite comme `[email protected]`, ACME HTTP-01, ACME DNS-01, ACME TLS-ALPN-01. Les preuves de validation doivent être conservées et une nouvelle validation est exigée pour chaque nouvel identifiant (dans des fenêtres de réutilisation qui se réduisent, décrites à BR §3.2.2.4 / §4.2.1). Aucun champ Organisation, aucun appel téléphonique, aucun signataire.

Contrôles OV

DV plus l'identité. La CA vérifie que l'organisation requérante existe dans un registre officiel, qu'elle correspond aux données du Subject et qu'elle est joignable à l'adresse déclarée, à l'aide de sources d'information indépendantes qualifiées (QIIS, QGIS, QIGS) telles que définies aux BR §3.2.2.1 et complétées par les contrôles de §3.2.5. Un opérateur humain de l'équipe de validation de la CA revoit le dossier et confirme l'autorité du demandeur avant signature.

Contrôles EV

OV plus profondeur et autorité du signataire. La CA vérifie l'existence légale (typiquement trois ans d'historique d'exploitation, ou preuves alternatives au §11.2 des EV Guidelines), l'existence physique, le statut opérationnel et l'autorisation explicite d'un dirigeant nommément désigné. La validation du domaine doit également suivre les méthodes acceptées au §11.7. Le certificat porte la juridiction et le numéro d'immatriculation, ce qui permet aux parties de confiance de retrouver l'entité dans le registre source.

Vue d'ensemble

DVOVEV
VérifieContrôle du domaine uniquementContrôle du domaine + entité juridiqueContrôle du domaine + entité juridique + signataire + 3 ans d'existence
Délai d'émissionQuelques secondes à minutes1 à 3 jours ouvrés3 à 10 jours ouvrés
Prix indicatifGratuit à ~50 € / an~60 € à 250 € / an~150 € à 1 000 € / an
Subject CN / OCN présent, O videCN + O, localité, région, paysCN + O + juridiction + n° d'immatriculation + catégorie d'activité
WildcardsOuiOuiInterdit par les EV Guidelines
UI navigateurCadenas uniquementCadenas uniquementCadenas uniquement (barre verte retirée de Chrome 77 et Firefox 70, 2019)
Durée de vie max. (cible CA/B)47 jours d'ici mars 202947 jours d'ici mars 202947 jours d'ici mars 2029

Lire le niveau de validation sur le fil

Chaque niveau est encodé dans le certificat sous forme d'OID de politique de certification, défini par le CA/Browser Forum à la section 7 des Baseline Requirements. C'est cet OID que les vérificateurs programmatiques lisent pour affirmer « ce certificat a été émis sous la politique DV / OV / EV », indépendamment de toute allégation marketing sur le site de la CA.

Un certificat qui n'affirme aucun de ces OIDs CA/Browser Forum n'est, selon les règles du Web PKI, pas publiquement reconnu pour l'authentification de serveur TLS — du moins selon les politiques que les grands navigateurs appliquent. Lire l'OID est un signal plus fiable que lire le Subject, car ce dernier peut être vide (DV) ou rempli partiellement de manière non standard.

# Récupérer un certificat serveur et inspecter ses politiques de certification
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -text \
| grep -A2 "Certificate Policies"

# OIDs de politique CA/Browser Forum que vous verrez dans la sortie :
#   2.23.140.1.2.1   — Domain Validation (DV)
#   2.23.140.1.2.2   — Organisation Validation (OV)
#   2.23.140.1.2.3   — Individual Validation (IV, rare en TLS)
#   2.23.140.1.1     — Extended Validation (EV)
#
# L'OID propre à la CA est généralement présent à côté de celui du CA/B,
# et c'est lui qui est effectivement ancré dans le programme EV root de
# chaque navigateur.
Chrome a retiré le traitement visuel spécifique à l'EV en Chrome 77 (septembre 2019), et Firefox a suivi en Firefox 70 (octobre 2019). Safari d'Apple avait fait l'équivalent plus tôt, courant 2018-2019. La justification, résumée sur les communications publiques des trois éditeurs : les études montraient que la barre verte et le nom d'entreprise n'influençaient pas mesurablement le comportement des utilisateurs, tandis que des attaquants obtenaient des certificats EV pour des dénominations confondables. Les certificats EV fonctionnent toujours, se chaînent toujours et se valident toujours — mais le signal visuel que l'on apprenait à chercher dans le navigateur n'y est plus.

Quand choisir lequel

Un modèle mental utile : la DV répond à « est-ce le bon serveur au bout de cette connexion ? », l'OV ajoute « et quelle entreprise opère ce serveur ? », l'EV ajoute « et nous avons une trace écrite pour étayer cette affirmation ». Chaque couche est additive, chaque couche coûte davantage à produire, chaque couche protège contre une catégorie d'attaque différente.

La DV est le bon choix par défaut sur le Web ouvert

Tout ce qui est exposé au public, tout ce qui est interne mais accessible, tout ce qui passe derrière un CDN, tout ce qui doit se renouveler tous les 47 jours sans intervention humaine — la DV est la bonne réponse. La combinaison de l'émission gratuite, du protocole ACME de la RFC 8555 et de la réalité opérationnelle des durées de vie plus courtes rend tout niveau supérieur à la DV coûteux en temps humain pour des bénéfices que les navigateurs ne mettent plus en avant. Sur le Web ouvert, la DV n'est pas un sous-choix : c'est l'option autour de laquelle le reste de la pile est construit.

L'OV pour les portails B2B et les secteurs régulés

L'OV reste justifiée chaque fois que le Subject du certificat est consommé par autre chose qu'un onglet de navigateur — intégrations partenaires qui s'appuient sur le nom d'organisation, flux liés à eIDAS qui lisent le certificat comme une preuve d'identité d'entreprise, environnements audités où la trace de la vérification effectuée par la CA fait partie des contrôles. Les banques, les assureurs, les réseaux de santé et les plateformes SaaS B2B à partenaires régulés adoptent souvent l'OV par défaut pour cette raison. Le compromis est opérationnel : chaque renouvellement OV doit franchir un contrôle d'identité, ce qui rend l'automatisation complète plus difficile qu'en DV.

L'EV quand l'identité juridique fait partie de la décision de confiance

L'EV est le bon choix quand le vérificateur a besoin non seulement de « le titulaire du domaine contrôle la clé » mais de « une entité juridique précise, nommée, immatriculée dans une juridiction donnée, a formellement demandé ce certificat ». La variante EV de la signature de code (document distinct, mais même logique) en est l'exemple canonique : Microsoft l'exige pour la signature des pilotes en mode noyau, et la plupart des systèmes de réputation de téléchargement des navigateurs s'y réfèrent. Pour le TLS lui-même, l'EV reste utile pour les certificats qualifiés d'authentification de site web eIDAS (QWAC), où le certificat porte des informations sur lesquelles un régulateur peut s'appuyer. Les certificats EV ne peuvent pas inclure de wildcards : chaque FQDN couvert doit être explicitement énuméré.

L'horizon des 47 jours creuse l'écart

À mesure que les fenêtres de validité s'effondrent vers 47 jours d'ici mars 2029, et que la période pendant laquelle une CA peut réutiliser une preuve antérieure de contrôle du domaine se réduit vers 10 jours (BR §3.2.2.4 / §4.2.1), le coût opérationnel de l'OV et de l'EV augmente : chaque cycle de renouvellement intègre une nouvelle vérification d'identité, sauf si la CA peut s'appuyer sur des preuves mises en cache dans la fenêtre de réutilisation autorisée. La DV — avec sa preuve de contrôle automatisable et légère — absorbe cette cadence sans difficulté. L'OV et l'EV exigent une plateforme CLM capable de piloter le workflow de validation lui-même : récupération des challenges, provisionnement des enregistrements DNS, rattachement des artefacts de validation au bon dossier organisationnel et renouvellement à l'heure. Sans cela, le coût du niveau se multiplie avec la fréquence de renouvellement.

Comment nous aidons

Evertrust & DV vs OV vs EV : les niveaux de validation des certificats

DCV automatisée à tous les niveaux et pour toutes les CAEvertrust orchestre la Domain Control Validation pour les émissions DV, OV et EV face à n'importe quelle CA publique, avec une automatisation DNS-agnostique qui récupère les challenges, provisionne les enregistrements de preuve et suit les fenêtres de réutilisation à mesure qu'elles tombent vers 10 jours. Des renouvellements qui exigeaient des tickets manuels deviennent des workflows reproductibles et audités.

Un inventaire unique sur DV, OV et EVEvertrust CLM tient une source de vérité unique pour chaque certificat TLS public de l'environnement, quel que soit son niveau d'émission et quelle que soit la CA signataire. Le niveau de validation est un attribut de premier rang aux côtés de la date d'expiration, du propriétaire et de la cible de déploiement : des questions d'audit comme « montrez-moi tous les certificats OV qui expirent ce trimestre » se règlent en une requête, pas en tableur.

CA privées avec des niveaux pilotés par la politiqueEvertrust PKI vous permet de définir des niveaux de validation internes qui calquent le modèle public là où cela compte et s'en écartent là où c'est pertinent, avec des contrôles de politique sur les profils, les types de clés, les durées de validité et les contenus de Subject que chaque demandeur peut obtenir. Le même modèle de gouvernance s'applique aux renouvellements publics DV / OV / EV et à l'émission privée.