EV-TLS (Extended Validation TLS)

Veröffentlicht am

31.08.2026

Aktualisiert am

31.08.2026

Lesezeit

4 min

Definition

EV-TLS (Extended Validation TLS) bezeichnet ein TLS-Serverzertifikat, das nach der strengsten Prüfstufe des CA/Browser Forum ausgestellt wurde. Der Unterschied zu einem gewöhnlichen Zertifikat liegt nicht in der Kryptografie (die ist dieselbe), sondern in der Prüfung, die der Ausstellung vorausgeht.

Ein EV-Zertifikat bescheinigt, dass die dahinterstehende Organisation als juristische Person tatsächlich existiert, unter der angegebenen Firma registriert ist und die Domain kontrolliert. Die dafür einzuhaltenden Schritte sind in den EV Guidelines des CA/Browser Forum festgelegt.

Die drei Prüfstufen

StufeWas geprüft wirdAussagekraft
DV – Domain Validationnur die Kontrolle über die Domain„jemand verfügt über diese Domain“
OV – Organisation Validationzusätzlich die Organisation„eine Organisation dieses Namens existiert“
EV – Extended Validationrechtliche Existenz, Firma, Sitzstaat, Registernummer  (nach dokumentiertem Verfahren)„diese konkrete juristische Person betreibt diesen Server“

Der Sprung von OV zu EV liegt in der Nachvollziehbarkeit: Das Verfahren ist normiert, die geprüften Angaben stehen strukturiert im Zertifikat, und die Zertifizierungsstelle haftet für ihre Einhaltung.

Was im Zertifikat steht

Ein EV-Zertifikat trägt im Subject-Feld über den Domainnamen hinaus die geprüften Identitätsmerkmale (u.a. den eingetragenen Firmennamen, die Rechtsform, den Sitzstaat und die Registernummer der Organisation). Hinzu kommt eine Policy-OID, die die Einhaltung der EV Guidelines kennzeichnet.

Entscheidend für die maschinelle Verarbeitung: Diese Angaben sind strukturierte Felder, nicht Freitext. Eine Gegenstelle kann sie auslesen und gegen eine Erwartung prüfen.

Für den Endanwender ist EV unsichtbar geworden, da die meisten Browser seit 2019 kein entsprechendes Symbol („grüner Balken“) mehr einblenden. Für die maschinelle Kommunikation ändert dies nichts.

EV-TLS bei Verification of Payee (VoP)

Das EPC API Security Framework (EPC164-22) regelt die Absicherung der Schnittstellen zwischen Zahlungsdienstleistern in den Schemes des EPC. z.B. Verification of Payee und SEPA Request-to-Pay.

Für VoP gilt eine asymmetrische Zuordnung, die man kennen muss:

SeiteRolleZertifikat
ClientVoP Requesting PSP bzw. Routing and Verification MechanismQWAC PSD2
ServerVoP Responding PSPEV-TLS

Das Framework (Stand 2026) formuliert es für die Serverseite ausdrücklich: „The API server does not need a QWAC, it can use a standard website certificate. To ensure a sufficient high level of authentication, an EV TLS certificate is required.“

Beide Seiten authentisieren sich gegenseitig – das Framework verlangt mutual TLS: „When calling another scheme Participant’s API’s endpoint, the Participants MUST perform mutual authentication.“

Der anfragende Zahlungsdienstleister muss nicht nur seine Identität nachweisen, sondern auch seine aufsichtsrechtliche Rolle, denn er fragt fremde Kontodaten ab. Dafür trägt das QWAC die Attribute aus dem PSD2-Umfeld. Der antwortende Zahlungsdienstleister muss lediglich zweifelsfrei belegen, dass er derjenige ist, für den er sich ausgibt. Dafür genügt EV-TLS.

Abgrenzung zum QWAC

Beide Zertifikatstypen beweisen die Identität einer Organisation. Der Unterschied liegt darin, wer dafür einsteht und unter welchem Regime.

EV-TLSQWAC
GrundlageEV Guidelines des CA/Browser ForumeIDAS-Verordnung (EU) Nr. 910/2014
CharakterIndustriestandardEU-Recht
Ausstelleröffentliche Zertifizierungsstelle im Root-ProgrammQTSP auf der EU-Vertrauensliste
VertrauensankerRoot-Stores von Browsern und BetriebssystemenEU Trusted Lists (EUTL)
Geprüftrechtliche Identität der Organisationrechtliche Identität, qualifiziert nach eIDAS
Zusätzlich–PSD2-Rollen (PSP_AS, PSP_PI, PSP_AI, PSP_IC) und Kennung der zuständigen Aufsichtsbehörde
Bei VoPServerseiteClientseite

Ein QWAC ist technisch ebenfalls ein Website-Zertifikat. Der Unterschied ist nicht die Technik, sondern die Vertrauenskette: Beim EV-TLS bürgt eine kommerzielle Zertifizierungsstelle nach den Regeln eines Industriegremiums, beim QWAC ein qualifizierter Vertrauensdiensteanbieter nach europäischem Recht.

Weitere Zertifikatstypen im Zahlungsverkehr behandelt der Eintrag zu Zertifikaten.

Übersicht zum Ablauf bei VoP

EV-TLS and QWAC in a VoP call — two certificates, two trust anchorsA Verification of Payee call begins with a mutual TLS handshake. The requesting payment service provider opens the connection as the API client. The responding provider presents an EV-TLS server certificate, which the client validates against its own trust store of public certification authority roots; the certificate proves the organisation, its jurisdiction and its registration number. The server then asks the client to identify itself. The client presents a QWAC with the PSD2 attributes, which the server validates against the EU Trusted Lists; this proves not only the identity but also the regulatory role and the competent authority. Only once both sides are identified is the channel open and the VoP request can be sent. Two things break this in practice: a missing certification authority root in the trust store, and a QWAC issued without the client authentication extension.Trust storeCA roots, held by the clientVoP Requesting PSPthe API clientVoP Responding PSPthe API serverEU Trusted Liststhe QTSP register1 · the server proves who it is2 · the client checks it — against its own trust store3 · the client proves who it is4 · the server checks it — against the EU Trusted Lists5 · only now the payloadClientHello · the client opens the connectionserver certificate · EV-TLSchain check · is the issuing CA root in the store?valid · organisation, jurisdiction, registration numbercertificate request · the server asks the client to identifyclient certificate · QWAC PSD2trusted list check · is the QTSP listed?valid · identity plus PSD2 role and NCA identifierVOP request · name and IBANVOP response · match · close match · no matchmutual TLS established — both sides identifiedroot not in the trust store → handshake failsQWAC without id-kp-clientAuth → client auth failsA VoP call starts with a handshake — and two very different certificatesThe client opens the connection; the server presents its EV-TLS certificateThe client checks the chain against its own trust store — and no official list of CAs existsThe server asks the client to identify itself: a QWAC carrying the PSD2 attributesThat one is checked against the EU Trusted Lists — identity plus regulatory roleOnly now is the channel open, and the VoP request can be sentTwo things break it in practice: a missing root, and a QWAC issued without client authentication
EV-TLS and QWAC in a VoP call — the server proves itself to a trust store, the client to the EU Trusted Lists

Zwei offene Baustellen

Welcher Zertifizierungsstelle wird vertraut? Anders als beim QWAC gibt es für EV-TLS keine amtliche Liste. Das EPC stellt in seinen FAQ klar: „The ASF does not specify which CAs can issue EV TLS certificates for VOP“ und „No single public source is available listing the root certificates of CAs issuing EV-TLS certificate.“

Praktisch bedeutet das: Jeder Teilnehmer muss die Wurzelzertifikate der relevanten Zertifizierungsstellen selbst in seinen Trust Store aufnehmen. Das EPC empfiehlt, serverseitig auf in der europäischen Finanzbranche gängige Zertifizierungsstellen zu setzen, clientseitig deren Wurzeln vorzuhalten und im TLS-Handshake stets die vollständige Zertifikatskette auszuliefern. Die Pflege des Trust Store wird damit zu einer betrieblichen Daueraufgabe – und zu einer stillen Fehlerquelle, wenn sie unterbleibt.

Die Client-Authentication verschwindet aus öffentlichen Zertifikaten. Googles Root-Programm schreibt vor, dass öffentliche TLS-Serverzertifikate ab dem 15. Juni 2026 die Erweiterung für Client-Authentication (id-kp-clientAuth) nicht mehr enthalten dürfen. Große Zertifizierungsstellen stellen deshalb schrittweise um (teilweise auch bei QWAC).

Das EPC weist darauf hin, dass VoP-Schnittstellen keine Browser-Unterstützung benötigen und QWAC-PSD2-Zertifikate ohnehin nicht für Browser gedacht sind. Die Konsequenz für die Institute ist trotzdem konkret: Sie müssen sicherstellen, dass ihr QTSP weiterhin QWAC-PSD2-Zertifikate mit dem Wert id-kp-clientAuth ausstellt, sonst scheitert die gegenseitige Authentisierung.

Quellen

Zurück zum Glossar

acmt.023 ISO 20022 Nachricht acmt.024 ISO 20022 Nachricht Ancillary Systems AOS (Additional Optional Service)
Berlin Group BIC – Business Identifier Code
camt.027 ISO 20022 Nachricht camt.029 ISO 20022 Nachricht camt.052 ISO 20022 Nachricht camt.053 ISO 20022 Nachricht camt.054 ISO 20022 Nachricht camt.056 ISO 20022 Nachricht camt.087 ISO 20022 Nachricht camt.110 ISO 20022 Nachricht CBPR+ Roadmap CLM (Central Liquidity Management) CSM – Clearing and Settlement Mechanism
Debitor DFÜ-Abkommen DORA (Digital Operational Resilience Act) DTAZV Due Date
EBA CLEARING EBICS ECMS (Eurosystem Collateral Management System) eIDAS (electronic IDentification, Authentication and trust Services) EUDI Wallet (European Digital Identity Wallet) European Payments Council (EPC) EV-TLS (Extended Validation TLS)
FIDA FileAct FIN und FINplus
GiroCode
Header (Zahlungsverkehr)
IBAN (International Bank Account Number) Identifiers Directory IMPay (International Mass Payments) Instant Payments Regulation InterAct ISO 20022
Kreditor (Creditor)
MT1xx (Nachrichten der Kategorie 1) MT2xx (Nachrichten der Kategorie 2) MT940 Nachricht MT942 Nachricht
NCC (National Clearing Code)
Originator
pacs.002 ISO 20022 Nachricht pacs.003 ISO 20022 Nachricht pacs.004 ISO 20022 Nachricht pacs.007 ISO 20022 Nachricht pacs.008 ISO 20022 Nachricht pacs.009 ISO 20022 Nachricht pacs.010 ISO 20022 Nachricht pacs.028 ISO 20022 Nachricht pain.001 ISO 20022 Nachricht pain.002 ISO 20022 Nachricht pain.007 ISO 20022 Nachricht pain.008 ISO 20022 Nachricht pain.013/14 ISO 20022 Nachricht PSD2
QWAC
R-Transaktionen Relay (Payment Initiation Relay) RTGS – Real-Time Gross Settlement
SCC (SCL) SCT (SCL) SCT Inst SDD (SCL) SEPA SEPA Clearer SEPA Request-to-Pay Strukturierte Adressen SWIFT SWIFT CBPR+ SWIFT gpi
TARGET – T2 TIPS (TARGET Instant Payment Settlement)
Übersicht SEPA Reason Codes
UETR – Unique End-to-End Transaction Reference
Valuedate Verification of Payee (VoP) ViDA
Wolfsberg Group Standards
xBRL-CSV
Zertifikate