DV- vs. OV- vs. EV-Zertifikate: was die Validierung bringt

DV vs. OV vs. EV beschreibt, wie viel eine Zertifizierungsstelle geprüft hat, bevor sie ein TLS-Zertifikat ausstellt. Die Domain-Validierung belegt die Kontrolle über die Namen; die Organisationsvalidierung ergänzt die rechtliche Identität des Unternehmens; die erweiterte Validierung (Extended Validation) ergänzt eine strengere Identitätsprüfung nach gesonderten Richtlinien. Die Kryptografie ist identisch, Browser zeigen alle drei gleich an, und seit 2019 sind die Unterschiede vor allem für Menschen und Systeme von Bedeutung, die Zertifikatsdetails lesen.

Auf einen Blick

Was jede Stufe belegt

Die Domain-Validierung belegt, dass der Antragsteller des Zertifikats in diesem Moment über die Domain verfügte: Er hat ein Token per HTTP ausgeliefert (http-01), einen DNS-TXT-Eintrag veröffentlicht (dns-01), eine TLS-ALPN-Challenge beantwortet oder eine der anderen Methoden genutzt, die die Baseline Requirements in §3.2.2.4 aufführen. Seit 2025 müssen CAs das Ergebnis dieser Prüfungen aus mehreren Netzwerkperspektiven bestätigen; es reicht also nicht mehr, DNS oder das BGP-Routing in Richtung eines einzelnen Prüfstandorts zu kapern, um ein Zertifikat zu erhalten. Ein DV-Zertifikat sagt nichts darüber aus, wer die Website betreibt; eine Phishing-Domain bekommt eines so leicht wie eine Bank.

Die Organisationsvalidierung trägt nach Prüfungen anhand amtlicher Register und verifizierter Kontaktdaten den geprüften rechtlichen Namen, den Ort und das Land des Antragstellers in das Subject des Zertifikats ein. Die erweiterte Validierung wendet ein strengeres, genau vorgeschriebenes Verfahren an, das Registrierungsnummern, den Rechtsraum der Gründung, die operative Existenz und die Prüfung der Person umfasst, die den Antrag genehmigt; die Ergebnisse stehen in eigenen Subject-Attributen.

Was keine der drei belegt: dass die Website sicher ist, dass die Organisation ehrlich ist oder dass die Person, mit der du sprichst, die ist, für die sie sich ausgibt.

So erkennst du, welche Stufe eine Website nutzt

Die Policy-OID in der Erweiterung Certificate Policies gibt die Validierungsstufe an; das Subject zeigt, was geprüft wurde. Dieses Skript, ausgeführt am 20. Oktober 2026 mit OpenSSL 3.6.5, liest beides von drei Live-Websites.

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

Das erste ist DV (nur ein Name), das zweite OV (Organisation und Adresse), das dritte EV (Rechtsraum der Gründung, Geschäftskategorie und Registrierungsnummer). Die zusätzlichen OIDs sind eigene Policy-Kennungen der jeweiligen CA. Der Zertifikats-Decoder zeigt dieselben Felder für ein eingefügtes PEM.

Was Browser anzeigen

Browser zeigten EV-Zertifikate früher mit einer grünen Leiste und dem Firmennamen an. Studien ergaben, dass Nutzer die Anzeige oder ihr Fehlen selten bemerkten und ihr Verhalten deswegen nicht änderten, und Forscher zeigten, dass rechtlich eigenständige Unternehmen EV-Zertifikate für Namen erhalten konnten, die bekannten Marken zum Verwechseln ähnlich sind. Safari 12 entfernte den Namen 2018 aus der Adressleiste; Chrome 77 (September 2019) und Firefox 70 (Oktober 2019) verlagerten die EV-Details in das Fenster mit den Seiteninformationen. Heute zeigen alle drei Stufen dasselbe Schloss-Symbol, und die Organisation erscheint erst, wenn jemand die Zertifikatsdetails öffnet.

Unterschiede im Betrieb

Laufzeiten und Fristen für die Wiederverwendung von Validierungen schrumpfen für alle. Nach Ballot SC-081v3 dürfen Zertifikate, die ab dem 15. März 2026 ausgestellt werden, höchstens 200 Tage gültig sein; im März 2027 sinkt die Grenze auf 100 Tage, im März 2029 auf 47 Tage. Eine Domain-Validierung lässt sich derzeit 200 Tage lang wiederverwenden, ab März 2029 nur noch 10 Tage, während Angaben zur Identität der Organisation 398 Tage lang wiederverwendet werden dürfen. Jedes öffentliche Zertifikat braucht daher eine automatisierte Erneuerung, und OV und EV fügen zur selben Automatisierung noch eine regelmäßige erneute Identitätsprüfung hinzu.

ACME selbst validiert nur die Kontrolle über die Domain. Manche kommerziellen CAs nehmen ACME-Bestellungen für OV- und EV-Zertifikate von Konten an, die über External Account Binding (RFC 8555 §7.3.4) an eine vorab geprüfte Organisation gebunden sind; so können Unternehmen Erneuerungen nach einer ersten manuellen Identitätsprüfung automatisieren. Certificate Transparency protokolliert jedes öffentlich vertrauenswürdige TLS-Zertifikat, daher werden die Organisationsdetails in OV- und EV-Zertifikaten öffentlich, sobald diese ausgestellt sind.

Wann welche Stufe passt

• Öffentliche Websites und APIs: DV, automatisiert mit ACME. Investiere den gesparten Aufwand in HSTS, CAA-Einträge und CT-Monitoring.
• Verträge, Aufsichtsbehörden oder Partner, die ein identifiziertes Subject im Zertifikat verlangen (manche Integrationen im Zahlungsverkehr, im Bankwesen und mit Behörden): OV, oder EV, wo dies vorgegeben ist.
• Client-Systeme, die den Organisationsnamen eines Zertifikats abgleichen: OV, aber bevorzuge für solche Integrationen Schlüssel-Pinning oder eine private CA.
• Interne Dienste und mTLS: keine der drei; verwende eine private CA.
• Codesignatur: ein eigenes Produkt mit eigenen Validierungsregeln und hardwaregeschützten Schlüsseln (seit Juni 2023 Pflicht), nicht TLS-OV oder -EV.
• Markenschutz: CAA-Einträge, CT-Monitoring und die Verwaltung des Domainportfolios gehen die Risiken, gegen die EV gedacht war, direkter an.

Hinweise zur Migration

1. Der Wechsel von EV oder OV zu DV erfordert auf dem Server meist keine Änderung außer dem Zertifikat: Beantrage ein DV-Zertifikat für dieselben Namen (mit einem neuen Schlüssel, idealerweise ECDSA P-256), stelle es mit der vollständigen Kette bereit und lass das alte ablaufen.
2. Prüfe Abhängigkeiten von Subject-Feldern: Client-Allowlists, Monitoring-Regeln oder Partnerintegrationen, die O= abgleichen, funktionieren mit DV nicht mehr.
3. Automatisiere zuerst: Manuelle Erneuerung ist schon bei 200 Tagen ein Risiko und bei 47 Tagen nicht mehr zu bewältigen, unabhängig von der Validierungsstufe.
4. Setze CAA-Einträge, damit nur die von dir gewählten CAs ausstellen können, und binde sie mit accounturi (RFC 8657) an dein ACME-Konto; der CAA-Eintragsgenerator erstellt sie.
5. Beobachte CT: Ein Certificate-Transparency-Monitor listet Zertifikate auf, die für deine Namen ausgestellt wurden, sodass eine unerwartete Ausstellung auf jeder Stufe sichtbar wird (Certificate Transparency für Entwickler).

Quellen

• Baseline Requirements des CA/Browser Forum (§3.2.2, §3.2.2.4, §7.1.6.1)
• EV Guidelines des CA/Browser Forum
• Ballot SC-081v3, Verkürzung der Gültigkeits- und Wiederverwendungsfristen
• Ballot SC-067v3, Gegenprüfung der Ausstellung aus mehreren Netzwerkperspektiven
• RFC 8555, ACME
• RFC 8659, CAA und RFC 8657, CAA-Kontobindung