Das Mandat des CA/Browser-Forums: Das Ende der Dual-EKU-Zertifikate

Die CA/Browser Forum-Abstimmung SC-081v3 wurde im April 2025 einstimmig mit Unterstützung aller vier Hauptmitglieder des Forums – Google, Apple, Microsoft und Mozilla – sowie 25 abstimmenden Zertifizierungsstellen angenommen. Diese Abstimmung führte weitreichende Änderungen an den TLS-Basisanforderungen (TBRs) ein, wobei die Trennung der erweiterten Client-Schlüsselverwendung (EKU) zu den strukturell bedeutendsten Änderungen zählt.

Die Chrome-Root-Programmrichtlinie v1.8 , die als Durchsetzungsmechanismus für den Root-Zertifikatspeicher von Google Chrome dient , geht noch weiter. Sie schreibt nicht nur vor, dass Endzertifikate frei von Client-Authentifizierung sein müssen, sondern dass ganze PKI-Hierarchien reorganisiert werden müssen. Dies schließt Zwischenzertifizierungsstellen ein, die mit Root-Zertifikaten im Chrome-Root-Zertifikatspeicher verknüpft sind und keine doppelten EKU-Werte mehr enthalten dürfen. Die Trennung muss auf Ebene der Zertifizierungsstelle erfolgen, nicht nur auf Zertifikatsebene.

Bevor wir uns mit dem Mandat befassen, ist es sinnvoll, die technischen Grundlagen zu erläutern. Die erweiterte Schlüsselverwendung (Extended Key Usage, EKU) ist ein Feld in einem X.509-Zertifikat , das die spezifischen Zwecke definiert, für die der öffentliche Schlüssel des Zertifikats verwendet werden darf. Systeme, die Zertifikate validieren, prüfen die EKU-Werte, um festzustellen, ob ein vorgelegtes Zertifikat für die beabsichtigte Operation autorisiert ist.

Zwei Werte der EKU stehen im Mittelpunkt dieses Auftrags:

• Serverauthentifizierung (OID 1.3.6.1.5.5.7.3.1): Dieses Zertifikat signalisiert, dass es zur Authentifizierung eines Servers gegenüber einem Client gültig ist. Ihre HTTPS-Website verwendet dieses Zertifikat. Browser prüfen es beim Aufbau einer TLS-Verbindung.
• Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2): Es signalisiert, dass das Zertifikat zur Authentifizierung eines Clients gegenüber einem Server gültig ist. Dies wird bei mTLS, Geräteauthentifizierung und in Szenarien verwendet, in denen der Client seine Identität nachweisen muss und nicht nur der Server.

Öffentliche Zertifizierungsstellen stellten TLS-Zertifikate mit zwei EKU-Werten aus . Das Zertifikat sieht folgendermaßen aus:

Ein einzelnes Zertifikat enthielt sowohl Server- als auch Clientauthentifizierung . Diese Praxis mit zwei EKUs war zwar praktisch, da ein Zertifikat beide Funktionen erfüllen konnte, aber architektonisch mangelhaft, und das CA/Browser Forum hat sie nun offiziell aus öffentlichen PKIs verbannt.

Kurzantwort: Was ist das Dual-EKU-Zertifikatsmandat?

Die Dual-EKU-Zertifikatspflicht gemäß CA/Browser Forum SC-081v3 (April 2025) und Chrome Root Program Policy v1.8 schließt die Clientauthentifizierung aus öffentlich vertrauenswürdigen TLS-Zertifikaten aus. Ab dem 15. Juni 2026 dürfen keine neuen Zwischenzertifizierungsstellen mehr Dual-EKU-Werte verwenden. Ab dem 15. März 2027 muss jedes neu ausgestellte, öffentlich vertrauenswürdige TLS-Endzertifikat ausschließlich Serverauthentifizierung enthalten . Die Clientauthentifizierung muss in eine dedizierte, private PKI-Hierarchie verlagert werden.

Wichtige Erkenntnisse

• Die Abstimmung des CA/Browser Forums (SC-081v3) wurde im April 2025 mit Unterstützung von Google, Apple, Microsoft, Mozilla und 25 weiteren Zertifizierungsstellen einstimmig angenommen. Die Chrome-Root-Programmrichtlinie v1.8 erzwingt die Trennung auf der Ebene der Zertifizierungsstellenhierarchie, nicht nur auf der Ebene der Endzertifikate. Ab dem 15. Juni 2026 darf keine neue, dem CCADB gemeldete Zwischenzertifizierungsstelle sowohl Server- als auch Clientauthentifizierung enthalten. Ab dem 15. März 2027 muss jedes neu ausgestellte, öffentlich vertrauenswürdige TLS-Endzertifikat ausschließlich die Serverauthentifizierungs-EKU enthalten.
• Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen im Vorjahr aufgrund von Zertifikatsproblemen Ausfallzeiten verzeichneten und 37.5 Prozent einen Ausfall auf ein abgelaufenes Zertifikat zurückführten. Die Dual-EKU-Pflicht führt zu einem neuen und schwerer zu diagnostizierenden Fehlermodus: Ein ohne Client-Authentifizierung erneuertes Zertifikat ist zwar gültig, nicht abgelaufen und vertrauenswürdig, führt aber stillschweigend zu Fehlern bei allen Client-Authentifizierungsanwendungen (TLS-Handshake-Fehler, Zugriff verweigert, Peer-Verifizierungsfehler), die die fehlende EKU nicht als Ursache identifizieren.
• Das CA/Browser Forum SC-081v3 reduziert die maximale Gültigkeitsdauer von TLS von 200 Tagen (März 2026) über 100 Tage (März 2027) auf 47 Tage (März 2029). Bei einer Gültigkeitsdauer von 47 Tagen muss ein Zertifikat etwa achtmal jährlich erneuert werden. Jede Erneuerung eines Dual-EKU-Zertifikats, das noch nicht auf eine private PKI migriert wurde, birgt das Risiko eines unbemerkten Ausfalls der Authentifizierung. Die Einführung der neuen Regelung und die Reduzierung der Gültigkeitsdauer erfolgen zeitgleich, was das Risiko für Organisationen, die die Erkennung und Migration verzögern, zusätzlich erhöht.
• Acht Anwendungsfallkategorien sind von Umbrüchen bedroht: Mutual TLS (mTLS), RADIUS- und IEEE 802.1X-Netzwerkauthentifizierung, zertifikatsbasierte VPNs (OpenVPN, Cisco Secure Client, Fortinet), Server-zu-Server-Kommunikation mit Microsoft Exchange, Remote Desktop und RDP-Gateway, IoT und Geräteidentität, API- und Server-zu-Server-Authentifizierung sowie CI/CD- und DevOps-Workloads. Die gefährlichsten Abhängigkeiten sind die undokumentierten: Systeme, die auf clientAuth angewiesen sind, weil öffentliche Zertifikate dies historisch standardmäßig beinhalteten, ohne dass diese Abhängigkeit formal erfasst wurde.
• NIST FIPS 203, 204 und 205 (finalisiert am 13. August 2024) fordern den Austausch von RSA- und Elliptische-Kurven-Algorithmen in allen PKI-Hierarchien gemäß dem NIST IR 8547-Abkürzungsplan. Private CA-Hierarchien, die zur Erfüllung des Dual-EKU-Mandats erstellt wurden, müssen zudem eine Migrationsplanung für private CA-Schlüsselalgorithmen nach der Quantenabkürzung beinhalten. Die Migrationsanforderungen für private CA-Schlüsselalgorithmen können über die NIST FIPS 203, 204 und 205 verfolgt werden. PQC Kompetenzzentrum.

Für wen ist das Dual-EKU-Mandat relevant?

Die Einführung der dualen EKU-Pflicht ist keine Änderung der Zertifikatsvorlage. Es handelt sich um eine Änderung der PKI-Architektur, die ein koordiniertes Vorgehen von PKI-Teams, Sicherheitsarchitekten, Plattformingenieuren, Compliance-Teams und CISOs erfordert. Jedes Team ist für einen bestimmten Teil des Übergangs verantwortlich, und Lücken in einem dieser Bereiche führen zu unbemerkten Authentifizierungsfehlern, die das größte operative Risiko der Pflicht darstellen.

Funktion / Rolle (Role) *	Warum es wichtig ist	Aktionselement
PKI- und Zertifikatsteams	Verantwortlich für das Design der privaten CA-Hierarchie und die Trennung der Zertifikatvorlagen: Die Chrome-Root-Programmrichtlinie v1.8 erfordert eine Trennung auf CA-Ebene, nicht nur auf Ebene der Endzertifikate. Das bedeutet, dass PKI-Teams eine private Hierarchie mit dedizierten ausstellenden CAs für die Clientauthentifizierung (nur clientAuth EKU, keine serverAuth) entwerfen und betreiben müssen, getrennt von der öffentlichen TLS-Hierarchie (nur serverAuth). Standardmäßige CA-Plattformen für Unternehmen erfordern eine explizite Vorlagenkonfiguration, um die EKU-Trennung durchzusetzen und die Ausstellung von doppelten EKUs zu verhindern. Der Stichtag 15. März 2027 ist für neu ausgestellte Zertifikate absolut; eine Verlängerung ist für Organisationen, die die Migration noch nicht abgeschlossen haben, nicht möglich.	Überprüfen Sie das gesamte Zertifikatsinventar auf alle öffentlich vertrauenswürdigen Zertifikate, die sowohl serverAuth- als auch clientAuth-EKU-Werte enthalten. CertSecure Manager; Entwerfen Sie die private CA-Hierarchie mit dedizierten ausstellenden CAs für Clientauthentifizierung, Benutzeridentität, Geräteidentität und Workload-Identität; Konfigurieren Sie Zertifikatvorlagen, um die EKU-Trennung zu erzwingen (nur öffentliche Vorlagen für Serverauthentifizierung, nur private Vorlagen für Clientauthentifizierung), wobei die Ausstellung von zwei EKUs nicht möglich ist; verwenden CBOM Secure zur vollständigen Ermittlung des kryptografischen Besitzes einschließlich aller von Zertifizierungsstellen ausgestellten Zertifikate in Cloud-, On-Premises- und Multi-Cloud-Umgebungen; Bewertung PKIaaS für die private CA-Hierarchie, wenn die interne PKI-Operationskapazität begrenzt ist
Sicherheitsarchitekten	Verantwortung für die Governance der PKI-Architektur übernehmen: Das Mandat erfordert nicht nur eine neue Zertifikatvorlage, sondern eine neue Hierarchie privater Zertifizierungsstellen mit eigener Stammzertifizierungsstelle, ausstellenden Zertifizierungsstellen, HSM-gestütztem Schlüsselschutz, einer Strategie zur Verteilung des Truststores, einer CRL/OCSP-Infrastruktur und der Auswahl des Registrierungsprotokolls. Sicherheitsarchitekten müssen zudem die Grenze zwischen öffentlichen TLS-Zertifikaten (nur Serverauthentifizierung, browservertrauenswürdig) und privaten Clientzertifikaten (nur Clientauthentifizierung, privat vertrauenswürdig) festlegen, um zu gewährleisten, dass kein System ein öffentliches Zertifikat zur Clientauthentifizierung oder umgekehrt verwenden kann. Die Migration der privaten CA-Schlüsselalgorithmen nach der Quantenintegration (ECDSA zu ML-DSA gemäß NIST FIPS 204, finalisiert am 13. August 2024) muss ebenfalls bereits bei der Architekturplanung berücksichtigt werden.	Entwerfen Sie die Architektur der privaten CA-Hierarchie: Offline-Root-CA, separate ausstellende CAs für jeden Client-Authentifizierungs-Anwendungsfall (mTLS, Gerät, Benutzer, Workload, API), HSM-gestützter Schlüsselschutz gemäß FIPS 140-3 Level 3, CRL- und OCSP-Infrastruktur sowie ein Truststore-Verteilungsplan; spezifizieren Sie Registrierungsprotokolle für jeden Anwendungsfall (WSTEP für Windows-AD-eingebundene Rechner, ACME für Cloud-native Workloads, SCEP für Mobilgeräte/IoT, EST für allgemeine Registrierung); planen Sie den Migrationspfad nach der Quantenintegration für private CA-Schlüsselalgorithmen. PQC Kompetenzzentrum; die Richtliniengrenze definieren, die verhindert, dass Systeme nach dem 15. März 2027 ein öffentliches TLS-Zertifikat zur Clientauthentifizierung verwenden.
Plattform- und DevOps-Teams	Verantwortlich für die Migration auf Anwendungsebene: Jedes System, das derzeit ein öffentliches TLS-Zertifikat zur Client-Authentifizierung verwendet, muss so konfiguriert werden, dass es stattdessen ein privates Client-Zertifikat verwendet. Dies umfasst mTLS-Endpunkte in Microservice-Architekturen, RADIUS-Server und 802.1X-Authentifizierungsinfrastruktur, VPN-Gateways (OpenVPN, Cisco Secure Client, Fortinet), IoT-Plattformen und Geräteverwaltungssysteme, Kubernetes-Service-Mesh-Konfigurationen, API-Gateways mit zertifikatbasierter Client-Authentifizierung sowie CI/CD-Pipelines, die sich bei Registries, Artefakt-Repositories und Kubernetes-Clustern authentifizieren. Plattformteams müssen zudem die Registrierung privater Zertifikate (WSTEP, ACME, SCEP, EST) in die Workflows zur Infrastrukturbereitstellung integrieren, damit neue Systeme automatisch private Client-Zertifikate erhalten.	Alle mTLS-Konfigurationen, RADIUS-Bereitstellungen, VPN-Gateways, Kubernetes-Service-Mesh-Richtlinien, API-Gateway-Authentifizierungskonfigurationen und die Zertifikatsnutzung der CI/CD-Pipelines werden erfasst, um die Anwendungsfälle zu identifizieren, die öffentliche Zertifikate für die Clientauthentifizierung verwenden. Jedes System wird so konfiguriert, dass es ein privates ClientAuth-Zertifikat aus der neuen privaten PKI-Hierarchie verwendet. Die Registrierung privater Zertifikate wird in die Infrastrukturbereitstellungspipelines integriert (cert-manager für Kubernetes, ACME für Cloud-native Systeme, WSTEP für Windows AD-basierte Systeme). Die Erfolgsrate der Authentifizierung wird für mTLS-, RADIUS- und VPN-Anwendungsfälle überwacht, um Fehler bei der ClientAuth-Entfernung zu erkennen, bevor es zu Ausfällen mit Auswirkungen auf die Kunden kommt.
Compliance-Teams	Organisationen müssen vor dem 15. März 2027 einen Nachweis über die abgeschlossene Migration vorlegen: Regulierte Branchen, die mTLS (PCI DSS 4.0 Anforderung 4), zertifikatsbasierte Netzwerkauthentifizierung (HIPAA, DORA) oder Geräteidentität (CMMC) einsetzen, riskieren Compliance-Probleme, wenn Client-Authentifizierungszertifikate ohne clientAuth erneuert werden und Authentifizierungsfehler auf eine nicht konforme Zertifikatsausstellung zurückzuführen sind. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen Ausfallzeiten im Zusammenhang mit Zertifikaten verzeichneten und dass Feststellungen im Zusammenhang mit Fehlern in der Zertifikatsverwaltung eine direkte Folge unentdeckter Dual-EKU-Abhängigkeiten sind.	Nehmen Sie den Status der Dual-EKU-Migration in das vierteljährliche Compliance-Nachweispaket auf: Prozentsatz der öffentlich vertrauenswürdigen Zertifikate, die noch clientAuth enthalten, Prozentsatz der auf private Zertifikate migrierten Client-Authentifizierungs-Anwendungsfälle und Authentifizierungsausfälle, die auf die Entfernung von clientAuth zurückzuführen sind; ordnen Sie die Frist für die Zwischenzertifizierungsstelle (15. Juni 2026) und die Frist für das Endzertifikat (15. März 2027) internen Compliance-Meilensteinen zu; bestätigen Sie, dass die private PKI-Hierarchie auf Anfrage auditfähige Zertifikats-Governance-Berichte (ausstellende Zertifizierungsstelle, EKU, Ablaufdatum, Inhaber, Registrierungsmethode) ohne manuelle Zusammenstellung erstellt; überprüfen Sie die Abdeckung der automatisierten Registrierung privater Zertifizierungsstellen, sodass die 47-tägige Gültigkeit ab März 2029 keine manuellen Zertifikatserneuerungspflichten mit sich bringt.
CISOS	Die Dual-EKU-Vorgabe stellt ein operatives Risiko auf Vorstandsebene dar: Authentifizierungsfehler aufgrund der Entfernung von clientAuth werden nicht als Zertifikatsfehler, sondern als TLS-Handshake-Fehler, Zugriffsverweigerungsmeldungen, VPN-Verbindungsverlust, Offline-Ereignisse von IoT-Geräten und CI/CD-Pipeline-Fehler ohne erkennbare Ursache angezeigt. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 37.5 Prozent der zertifikatsbezogenen Ausfälle auf abgelaufene Zertifikate zurückzuführen waren. Der Dual-EKU-Fehlermodus ist jedoch schwieriger zu diagnostizieren als ein Ablauf, da das Zertifikat gültig ist. Die verkürzte Gültigkeitsdauer (47 Tage bis März 2029) bedeutet, dass Erneuerungsereignisse achtmal pro Jahr auftreten, wodurch sich das Risiko unentdeckter Abhängigkeiten vervielfacht.	Finanzieren Sie ein Zertifikatsfindungs- und Inventarisierungsprogramm mit CertSecure Manager als unmittelbare Priorität, abgeschlossen vor dem 15. Juni 2026; Finanzierung des Aufbaus der privaten PKI-Hierarchie oder der PKIaaS-Implementierung, bevor die Frist für die Zwischenzertifizierungsstelle Notfallmaßnahmen erfordert; Verpflichtung, dass der Migrationsstatus der Dual-EKU, die Abdeckung der Automatisierung der privaten PKI-Registrierung und die Kennzahlen zu Authentifizierungsausfällen aufgrund von Zertifikatsfehlern als KPIs auf Vorstandsebene gemeldet werden; Bewertung PKI als Service Um den Aufbau und Betrieb einer HSM-Infrastruktur unter Zeitdruck in der privaten CA-Hierarchie zu vermeiden, muss die Planung der Post-Quanten-Migration privater CA-Schlüsselalgorithmen in die jährliche PKI-Programmüberprüfung einbezogen werden.

Checkliste für den Übergang zu Dual-EKU: Problem, Auswirkungen auf das Geschäft, empfohlene Maßnahmen und Verantwortlicher

Nutzen Sie diese Checkliste vor dem Stichtag für die Zwischenzertifizierung am 15. Juni 2026 und dem Stichtag für die Blattzertifizierung am 15. März 2027, um Übergangslücken zu identifizieren, die geschäftlichen Auswirkungen jeder Lücke zu verstehen und die Verantwortlichkeit für die Behebung zuzuweisen.

Problem	Auswirkungen auf das Geschäft	Empfohlene Maßnahme	Eigentümer
Es liegen keine Zertifikate vor, die sowohl serverAuth- als auch clientAuth-EKU-Werte enthalten.	Unternehmen können nicht feststellen, welche Zertifikate bei der Verlängerung stillschweigend die Client-Authentifizierung verlieren. Die Entdeckung nach Ablauf der Frist bedeutet, dass die Behebung des Problems unter Zeitdruck erfolgen muss, anstatt eine geplante Migration zu ermöglichen. Die DigiCert Trust Pulse Survey (Juli 2025) ergab, dass 45 Prozent der Unternehmen aufgrund von Zertifikatsproblemen Ausfallzeiten erlitten haben. Nicht erkannte Abhängigkeiten von zwei EKUs sind die Hauptursache für diese Ausfallzeiten.	Einführung CertSecure Manager Vollständige Zertifikatserkennung über alle CA-Quellen hinweg, einschließlich öffentlicher CAs, AWS Private CA, Azure Key Vault, HashiCorp Vault PKI und lokalem AD CS; Filterung des Inventars nach Zertifikaten mit den OIDs 1.3.6.1.5.5.7.3.1 und 1.3.6.1.5.5.7.3.2; Zuordnung jedes Dual-EKU-Zertifikats zum ausstellenden System und zum System, das es zur Clientauthentifizierung verwendet; Erstellung eines nach Risiko priorisierten Migrationszeitplans basierend auf den Ablaufdaten	PKI-Team + CISO
Keine private PKI-Hierarchie für Client-Authentifizierungszertifikate	Ohne eine private Zertifizierungsstelle gibt es keine konforme Quelle für Client-Auth-Zertifikate; Organisationen stehen vor einer strikten Frist (15. März 2027) ohne Ausweichmöglichkeit: Öffentliche Zertifizierungsstellen können nach diesem Datum keine Client-Auth-Zertifikate mehr ausstellen, und es gibt keine Übergangsfrist für Organisationen, die keine private Zertifizierungsstelle eingerichtet haben.	Entwerfen und implementieren Sie eine private CA-Hierarchie mit dedizierten ausstellenden CAs für Client-Authentifizierungs-Anwendungsfälle; schützen Sie die privaten CA-Schlüssel mit einem FIPS 140-3 Level 3 HSM; konfigurieren Sie Zertifikatvorlagen ausschließlich mit clientAuth EKU und ohne serverAuth; alternativ können Sie die Dienstleistungen von Encryption Consulting in Anspruch nehmen. PKIaaS für eine vollständig verwaltete private Zertifizierungsstelle, die unter Einhaltung enger Fristen errichtet, betrieben und konform gehalten wird	PKI-Team + Sicherheitsarchitekt
Private Root-CA wird nicht an alle vertrauenden Systeme verteilt	Von der privaten PKI ausgestellte Clientzertifikate werden von Systemen abgelehnt, die die private Stammzertifizierungsstelle nicht installiert haben; Authentifizierungsfehler treten auf, obwohl das Zertifikat korrekt mit clientAuth konfiguriert ist, da das empfangende System der ausstellenden Zertifizierungsstellenkette nicht vertraut.	Verteilen Sie die private Stammzertifizierungsstelle über Gruppenrichtlinien (Speicher für vertrauenswürdige Stammzertifizierungsstellen) an alle Windows-Systeme in der Domäne; verteilen Sie sie über update-ca-certificates mit Ansible, Chef oder Puppet an Linux-Systeme; verteilen Sie sie über MDM an mobile und IoT-Systeme; testen Sie die Authentifizierung anhand repräsentativer Systeme, bevor Sie Produktions-Workloads migrieren; dokumentieren Sie den Plan zur Vertrauensverteilung und bestätigen Sie die Abdeckung vor jeder Migrationsphase	Plattformteam + PKI-Team
Anwendungsfälle der Clientauthentifizierung bei manueller Zertifikatserneuerung	Bei einer maximalen TLS-Gültigkeit von 47 Tagen ab März 2029 führt die manuelle Erneuerung von Client-Zertifikaten zu acht Erneuerungsvorgängen pro Jahr und Zertifikat. Manuelle Prozesse in dieser Frequenz sind betrieblich nicht tragbar und bergen acht Ausfallrisiken pro Zertifikat und Jahr, falls eine Erneuerung versäumt oder verzögert wird.	Registrieren Sie alle privaten Clientzertifikate für die automatische Erneuerung mithilfe des entsprechenden Registrierungsprotokolls: WSTEP für Windows-Computer mit Active Directory-Zugriff (automatisch per Gruppenrichtlinie), ACME für Cloud-native und containerisierte Workloads, SCEP für mobile Geräte und IoT-Geräte, EST für die allgemeine Registrierung. Integrieren Sie die Registrierung in die Infrastrukturbereitstellungsprozesse, sodass neue Systeme private Clientzertifikate automatisch und ohne manuelles Eingreifen des PKI-Teams erhalten.	Plattformteam + PKI-Team
Keine Überwachung der Authentifizierungserfolgsrate für mTLS, RADIUS und VPN	Fehler bei der ClientAuth-Entfernung äußern sich als allgemeine Fehler (TLS-Handshake-Fehler, Zugriff verweigert, Peer-Verifizierungsfehler, Authentifizierungs-Timeout), die leicht fälschlicherweise als Netzwerk-, Cipher-Suite- oder Anwendungskonfigurationsprobleme diagnostiziert werden können; ohne spezifische Überwachung der Authentifizierungserfolgsrate wird die Ursache erst nach längerer Ausfallzeit identifiziert.	Fügen Sie eine Überwachung der Authentifizierungserfolgsrate für alle mTLS-Endpunkte, RADIUS-Authentifizierungsereignisse, VPN-Verbindungsversuche und IoT-Geräte-Check-ins hinzu; konfigurieren Sie Benachrichtigungen über Änderungen der Authentifizierungsfehlerrate, die mit Zertifikatserneuerungsereignissen korrelieren; integrieren Sie die EKU-Validierung in die Zertifikatszustandsprüfungen, sodass ein erneuertes Zertifikat ohne Client-Authentifizierung gekennzeichnet wird, bevor es zu einem Authentifizierungsfehler im Produktivbetrieb führt.	Plattformteam + Sicherheitsarchitekt
Private CA-Schlüsselalgorithmen sind nicht im Post-Quanten-Migrationsplan enthalten	NIST FIPS 203/204/205 (finalisiert am 13. August 2024) schreiben vor, dass RSA und ECC in allen PKI-Hierarchien gemäß dem in NIST IR 8547 festgelegten Deprecation-Timeline ersetzt werden müssen. Eine private CA-Hierarchie, die vor Ablauf der Dual-EKU-Frist ohne Post-Quantum-Algorithmusplanung erstellt wurde, muss vor dem Deprecation-Timeline neu aufgebaut oder neu verschlüsselt werden, was den Migrationsaufwand zusätzlich erhöht.	Private CA-Schlüsselalgorithmen (RSA, ECDSA P-256/P-384) sind bei der Architekturplanung anhand der Meilensteine ​​für die Abschaffung gemäß NIST IR 8547 zu klassifizieren; die Migration zu ML-DSA (FIPS 204) für CA-Signaturschlüssel ist zu planen; CBOM Secure alle kryptografischen Assets in der privaten PKI-Hierarchie ermitteln; Migrationsanforderungen über die PQC Kompetenzzentrum; auswerten PQC-Bereitschaft Dienstleistungen für eine strukturierte Migrationsbewertung	Sicherheitsarchitekt + PKI-Team

Das Mandat: Was SC-081 und das Chrome-Root-Programm erfordern

Öffentliche Zertifizierungsstellen dürfen keine TLS-Serverzertifikate mehr ausstellen, die die erweiterte Schlüsselverwendung für Client-Authentifizierung (clientAuth Extended Key Usage) beinhalten. Zwischenzertifizierungsstellenzertifikate, die sowohl Server- als auch Client-Authentifizierung unterstützen und auf eine öffentlich vertrauenswürdige Stammzertifizierungsstelle zurückgehen, müssen außer Betrieb genommen werden.

Jede Organisation, die Client-Authentifizierungszertifikate benötigt, muss diese von einer eigens dafür eingerichteten PKI-Hierarchie beziehen, die definitionsgemäß keine öffentliche CA-Hierarchie sein kann, der in Browser-Root-Speichern vertraut wird.

Der wichtigste Termin für Organisationen ist der 15. Juni 2026. Untergeordnete/Zwischen-CA-Zertifikate: Alle neuen Zwischenzertifikate, die CCADB an oder nach diesem Datum offengelegt werden, müssen ausschließlich serverAuth bestätigen, und es dürfen keine neuen Dual-EKU-Zwischenzertifikate zu den von Chrome als vertrauenswürdig eingestuften Hierarchien hinzugefügt werden.

Ab dem 15. März 2027 muss jedes neu ausgestellte Endzertifikat, das auf eine von Chrome als vertrauenswürdig eingestufte Stammzertifizierungsstelle verweist, ausschließlich serverAuth-fähig sein. Chrome lehnt ab diesem Zeitpunkt öffentliche TLS-Endzertifikate ab, die noch die clientAuth-EKU enthalten, und die betroffenen Handshakes schlagen fehl. Zertifikate, die vor dem Stichtag ausgestellt wurden, bleiben bis zu ihrem Ablaufdatum gültig, werden bei der Verlängerung jedoch ohne clientAuth neu ausgestellt.

Um gemäß dieser Richtlinie als dedizierte TLS-Server-Authentifizierungs -PKI-Hierarchie zu gelten:

1. Alle entsprechenden nicht abgelaufen und nicht widerrufen Untergeordnete CA-Zertifikate, die unter einer bestehenden, im Chrome Root Store enthaltenen Stammzertifizierungsstelle betrieben werden, MÜSSEN:
   • wenn sie der CCADB offengelegt wird vor dem 15. Juni 2026: schließen Sie die erweiterte Tastenverwendung Erweiterung und (a) nur einen Zweck der erweiterten Schlüsselverwendung geltend machen id-kp-serverAuth oder b) nur die erweiterten Schlüsselverwendungszwecke von id-kp-serverAuth geltend machen und id-kp-clientAuth.
   • wenn die Offenlegung gegenüber der CCADB am oder nach dem 15. Juni 2026: die extendedKeyUsage-Erweiterung einbinden und nur den Zweck extendedKeyUsage von id-kp-serverAuth festlegen.
   • Enthält keinen öffentlichen Schlüssel, der einem anderen gültigen oder nicht widerrufenen Zertifikat entspricht, das unterschiedliche extendedKeyUsage-Werte angibt.
2. Alle zugehörigen Teilnehmerzertifikate wurden ausgestellt am oder nach dem 15. März 2027, MUSS die extendedKeyUsage-Erweiterung enthalten und darf nur den Zweck extendedKeyUsage von id-kp-serverAuth angeben.

Ab dem 15. März 2027 muss jedes neu ausgestellte, öffentlich vertrauenswürdige TLS-Zertifikat einem einzigen Zweck dienen: der Serverauthentifizierung. Es darf nur die serverAuth EKU enthalten, wobei die clientAuth OID vollständig entfernt werden muss. Das Zertifikat einer öffentlichen Zertifizierungsstelle sollte wie folgt aussehen:

Die folgende Tabelle spezifiziert die erforderlichen und zulässigen Felder für Subscriber (Leaf) TLS-Serverzertifikate, die von öffentlich vertrauenswürdigen Zertifizierungsstellen gemäß CA/Browser Forum Mandat, 7.1.2.7 Subscriber (Server) Certificate Profile, ausgestellt werden:

Feld / Erweiterung	Präsenz	Zulässige Werte und Anforderungen
Version	MUST macht	v3 (ganzzahliger Wert 2)
Seriennummer	MUST macht	Positive ganze Zahl, mindestens 64 Bit Ausgabe eines CSPRNG.
BetreffAltName	MUST macht	Diese Erweiterung MUSS mindestens einen Eintrag enthalten. Jeder Eintrag MUSS entweder ein dNSName or IP-Adresse wie beschrieben in Abschnitt 7.1.4.2.
grundlegende Einschränkungen	MUST macht	Für ein Teilnehmerzertifikat (Blattzertifikat) cA-Feld MUSS auf FALSCH gesetzt werden. Pfadlängenbeschränkung DARF NICHT vorhanden sein.
Schlüsselverwendung	MUST macht	Es handelt sich um ein entscheidendes Attribut. Die zulässigen Werte für die Schlüsselverwendung variieren je nachdem, ob das Zertifikat subjectPublicKeyInfo identifiziert einen öffentlichen RSA-Schlüssel oder einen ECC Öffentlicher Schlüssel. Zertifizierungsstellen MÜSSEN sicherstellen, dass die Schlüsselverwendung für den öffentlichen Schlüssel des Zertifikats geeignet ist. Die zulässigen Schlüsselverwendungen sind: digitale Signatur + Schlüsselverschlüsselung für RSA und digitale Signatur nur für ECDSA
erweiterte Tastenverwendung	MUST macht	Folgender Wert MUSS vorhanden sein: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) Folgender Wert DARF NICHT vorhanden sein: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Verboten für neu ausgestellte Blattzertifikate ab dem 15. März 2027 gemäß Chrome-Root-Programmrichtlinie v1.8, Abschnitt 1.3.2
Zertifikatsrichtlinien	MUST macht	Falls vorhanden, MUSS die Erweiterung „Zertifikatrichtlinien“ mindestens einen Eintrag enthalten. Richtlinieninformationen.
Zugriff auf behördliche Informationen	MUST macht	Es handelt sich nicht um ein kritisches Feld. • Schlüsselidentifikator- Muss vorhanden sein. Muss mit dem Feld „subjectKeyIdentifier“ der ausstellenden Zertifizierungsstelle identisch sein. • authorityCertIssuer- DARF NICHT anwesend sein • authorityCertSerialNumber- DARF NICHT anwesend sein
subjectKeyIdentifier	MUST macht	Die Zertifizierungsstelle MUSS eine generieren subjectKeyIdentifier das innerhalb des Rahmens aller Zertifikate, die es für jeden einzelnen öffentlichen Schlüssel ausgestellt hat, einzigartig ist
cRLDistributionPoints	MUST macht	Diese Erweiterung MUSS vorhanden sein und DARF NICHT als kritisch gekennzeichnet sein. Die CRL-Verteilungspunkte-Erweiterung MUSS in Folgendem vorhanden sein: • Untergeordnete CA-Zertifikate; und • Teilnehmerzertifikate, die 1) nicht als „Kurzlebige Teilnehmerzertifikate“ gelten und 2) keine Authority Information Access-Erweiterung mit einer id-ad-ocsp accessMethod enthalten.

Hinweis zur erweiterten Schlüsselverwendung: Die CA/Browser Forum TLS Baseline Requirements v2.2.8, Abschnitt 7.1.2.7.10, führen id-kp-clientAuth weiterhin als „kann“ auf, d. h. zulässig, aber nicht erforderlich auf BR-Ebene. Das strikte Verbot ergibt sich aus der Chrome Root Program Policy v1.8, Abschnitt 1.3.2 , die vorschreibt, dass alle Teilnehmerzertifikate, die ab dem 15. März 2027 ausgestellt werden, ausschließlich id-kp-serverAuth enthalten müssen. Zertifizierungsstellen müssen diese Richtlinie einhalten, um im Chrome Root Store gelistet zu bleiben, wodurch die Einschränkung praktisch universell gilt.

Der Gesetzesentwurf SC-081 sieht außerdem eine schrittweise Reduzierung der maximalen Gültigkeitsdauer öffentlich vertrauenswürdiger TLS-Zertifikate vor. Die Gültigkeitsdauer sinkt ab März 2026 auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 47 Tage . Durch die kürzere Gültigkeitsdauer wird die automatisierte Registrierung über ACME, WSTEP, SCEP und EST zur Pflicht und nicht mehr nur zur Annehmlichkeit. Organisationen, die auf die manuelle Zertifikatserneuerung angewiesen sind, sehen sich mit einer untragbaren betrieblichen Belastung konfrontiert, da sich die Gültigkeitsdauer verkürzt. Dies unterstreicht die Notwendigkeit einer verwalteten privaten PKI mit von Anfang an integriertem, vollautomatisiertem Lebenszyklusmanagement.

Die öffentliche CA-Zeitleiste

Der kritischste Stichtag für Unternehmen ist der 15. Juni 2026. Ab diesem Datum lehnt Chrome öffentliche TLS-Zertifikate mit der clientAuth-EKU aktiv ab. Jede neue untergeordnete Zertifizierungsstelle (Zwischenzertifizierungsstelle), die ab diesem Datum an die Common CA Database (CCADB) gemeldet wird, darf nur noch die EKU „ id-kp-serverAuth“ enthalten . Ab diesem Datum können keine neuen Zwischenzertifizierungsstellen mit gemischten EKUs mehr zu den von Chrome vertrauenswürdigen Hierarchien hinzugefügt werden. Systeme, die ein solches Zertifikat in einem von Chrome validierten TLS-Handshake vorlegen, schlagen fehl. Bestehende Zertifikate, die vor diesem Datum ausgestellt wurden, bleiben bis zu ihrem Ablaufdatum gültig. Bei der Erneuerung werden sie jedoch ohne clientAuth ausgestellt.

Die Zertifizierungsstellen haben nicht bis zum endgültigen Stichtag im März 2027 gewartet . Die meisten großen Zertifizierungsstellen begannen bereits deutlich vorher mit der Abschaffung der Client-Authentifizierung, bedingt durch die von Chrome festgelegte Zwischenfrist für Zertifizierungsstellen im Juni 2026. Nachfolgend der vollständige Zeitplan (Stand: Juni 2026):

Datum	CA / Programm	Milestone	Status
15 September 2025	SSL.com	Verhindert standardmäßig die Ausstellung von Client-Authentifizierungsdateien	PASSED
1. Oktober 2025	DigiCert	Verhindert standardmäßig die Ausstellung von Client-Authentifizierungsdateien	PASSED
14. Oktober 2025	Sektigo	Verhindert standardmäßig die Ausstellung von Client-Authentifizierungsdateien	PASSED
11. Februar 2026	Lass uns verschlüsseln	Das Standard-ACME-Profil entfernt die Clientauthentifizierung.	PASSED
15. Juni 2026	Google Chrome	Lehnt öffentliche TLS-Zertifikate mit clientAuth EKU ab	KRITISCH
Juli 8, 2026	Lass uns verschlüsseln	tlsclient-Profil dauerhaft eingestellt	BEVORSTEHENDE
10. Februar 2027	Sektigo	Absolute Frist, keine Ausnahmen.	BEVORSTEHENDE
1. März 2027	DigiCert	Vollständige Entfernung, keine Ausnahmen.	BEVORSTEHENDE
15. März 2027	Chrome Root-Programm	Letzter Branchentermin	DEADLINE

Warum wird die Client-Authentifizierungs-EKU entfernt?

Man könnte versucht sein, diese Vorgabe lediglich als Compliance-Aufwand zu betrachten. Tatsächlich schließt sie jedoch eine echte und unterschätzte Sicherheitslücke. Das Verständnis der folgenden Sicherheitsbegründung hilft Organisationen zu verstehen, warum diese Änderung durchgesetzt wird:

• Die Public Web PKI wurde zur Authentifizierung von Servern gegenüber Browsern entwickelt: Die von öffentlichen Zertifizierungsstellen verwendeten Prozesse zur Domänenvalidierung (DV) und Organisationsvalidierung (OV) dienen der Überprüfung der Domäneninhaberschaft und der Identität der Organisation für die Serverauthentifizierung. Sie sind nicht dafür ausgelegt, die Berechtigung eines Systems zur Client-Authentifizierung in einem bestimmten Kontext nachzuweisen. Die Einbindung der clientAuth-EKU in ein öffentlich ausgestelltes Zertifikat impliziert einen Validierungsstandard, der nie angewendet wurde.
• Die Kompromittierung des privaten Schlüssels hat verschärfte Folgen: Wenn ein TLS-Serverzertifikat sowohl Server- als auch Clientauthentifizierung enthält, richtet ein kompromittierter privater Schlüssel doppelten Schaden an. Ein Angreifer, der den privaten Schlüssel eines Servers erlangt, kann sich nicht nur gegenüber Clients als dieser Server ausgeben, sondern das Zertifikat auch als gültige Client-Anmeldeinformationen jedem System präsentieren, das der ausstellenden Zertifizierungsstelle vertraut und die Clientauthentifizierungs-EKU überprüft. Eine einzige Kompromittierung ermöglicht die laterale Ausbreitung im Netzwerk. Durch das Entfernen der Clientauthentifizierung aus Serverzertifikaten wird dieser zweite Angriffsvektor vollständig eliminiert.
• Trennung ermöglicht ordnungsgemäßes Lebenszyklusmanagement: Server- und Clientzertifikate haben grundlegend unterschiedliche Lebenszyklusanforderungen. Serverzertifikate sind an Domainnamen gebunden, werden über öffentliche Infrastruktur erneuert und von Web-Operations-Teams verwaltet. Clientzertifikate hingegen sind an Systemidentitäten gebunden und erfordern Widerrufsfunktionen, die auf Anwendungsebene durchgesetzt werden. Die Zusammenführung beider Zertifikate in einem einzigen Zertifikat erschwert deren korrekte Verwaltung. Die Trennung stellt klare Zuständigkeiten und Verantwortlichkeiten wieder her.

Die Auswirkungen der Entfernung der Client-Authentifizierungs-EKU

Die Entfernung der clientAuth EKU betrifft Organisationen, die derzeit ein öffentlich vertrauenswürdiges TLS-Serverzertifikat für die Clientauthentifizierung verwenden.

Organisationen, die öffentliche Zertifikate ausschließlich für die standardmäßige HTTPS- Serverauthentifizierung verwenden, sind im Allgemeinen nicht betroffen. Ihre Websites, Portale und öffentlich zugänglichen Anwendungen können weiterhin Zertifikate verwenden, die nur die serverAuth EKU enthalten.

Die Auswirkungen treten auf, wenn dasselbe öffentliche Zertifikat auch zur Authentifizierung eines Benutzers, Geräts, Servers, einer Anwendung oder einer Arbeitslast gegenüber einem anderen System verwendet wird. Wird dieses Zertifikat ohne die clientAuth EKU erneuert oder neu ausgestellt, akzeptiert das empfangende System es möglicherweise nicht mehr als gültige Client-Anmeldeinformation.

Wichtig ist, dass das Zertifikat weiterhin gültig, nicht abgelaufen und vertrauenswürdig sein kann. Der Fehler tritt auf, weil das Zertifikat nicht mehr zur Clientauthentifizierung autorisiert ist.

Um Ihnen dabei zu helfen, mögliche Fehlerquellen und deren Ursachen zu identifizieren, hebt die folgende Tabelle die potenziellen Auswirkungen auf Ihre Organisation hervor.

Luftüberwachung	Mögliche Auswirkungen
Gegenseitiges TLS (mTLS)	Bei einer mTLS-Verbindung prüft das empfangende System, ob das Client-Zertifikat die clientAuth-EKU enthält. Fehlt diese EKU, wird das Zertifikat möglicherweise abgelehnt und der TLS-Handshake schlägt fehl. Dies kann Microservices, API-Gateways, Service Meshes, B2B-Integrationen und benutzerdefinierte Anwendungsauthentifizierungen beeinträchtigen. Der Fehler kann als allgemeiner TLS-Handshake- oder Zertifikatsvalidierungsfehler anstatt als Ablaufproblem erscheinen.
RADIUS, IEEE 802.1X und EAP-TLS	Bei der zertifikatbasierten Netzwerkauthentifizierung legen Benutzer oder Geräte ein Clientzertifikat vor, um ihre Identität nachzuweisen. Benötigt der Authentifizierungsserver die ClientAuth-EKU und enthält das erneuerte Zertifikat diese nicht, schlägt die Authentifizierungsanfrage fehl. Betroffene Geräte können sich daher möglicherweise nicht mit Unternehmens-WLANs, kabelgebundenen Netzwerken oder VPN-Diensten verbinden.
OpenVPN, Cisco Secure Client und Fortinet VPN	Viele zertifikatbasierte VPN-Implementierungen erfordern, dass das Benutzer- oder Gerätezertifikat die ClientAuth-EKU enthält. Wird ein zuvor für die VPN-Authentifizierung verwendetes öffentliches Zertifikat ohne diese EKU erneuert, kann das VPN-Gateway die Verbindung ablehnen. Benutzer können dann möglicherweise keine sichere Fernzugriffsverbindung herstellen.
Microsoft Exchange und Server-zu-Server-Kommunikation	SMTP-Connector, EWS und Partnerkommunikationskonfigurationen verwenden Zertifikate für die gegenseitige oder Server-zu-Server-Authentifizierung. Wenn das Zertifikat des verbindenden Servers die Clientauthentifizierung unterstützen soll, kann das Entfernen der ClientAuth-EKU die Authentifizierung oder den E-Mail-Verkehr beeinträchtigen. Die tatsächlichen Auswirkungen hängen von der Exchange-Version, der Connector-Konfiguration und den Anforderungen an die Zertifikatsvalidierung ab.
Remote-Desktop- und RDP-Gateway-Umgebungen	Das Remote Desktop Gateway verwendet üblicherweise ein Serverzertifikat zur Authentifizierung gegenüber Clients. Umgebungen, die zusätzlich zertifikatbasierte Clientauthentifizierung, Smartcard-Authentifizierung oder benutzerdefinierte gegenseitige Authentifizierungsmechanismen nutzen, benötigen jedoch möglicherweise dedizierte Clientzertifikate. Die Wiederverwendung eines öffentlichen Serverzertifikats für diesen Zweck kann nach der Erneuerung zu Authentifizierungsfehlern führen.
IoT und Geräteidentität	IoT-, Industrie- und eingebettete Geräte verwenden Zertifikate zur Authentifizierung gegenüber Cloud-Diensten, Managementplattformen oder Gerätegateways. Wird ein Gerätezertifikat ohne die erforderliche clientAuth-EKU erneuert, kann die Plattform die Geräteidentität ablehnen. Dies kann das Einchecken des Geräts, die Übermittlung von Telemetriedaten, die Fernverwaltung, Softwareaktualisierungen oder die Ausführung von Befehlen verhindern.
API- und Server-zu-Server-Authentifizierung	Anwendungen und Server fungieren häufig als TLS-Clients beim Aufruf interner oder externer APIs. Wenn sie ein öffentliches TLS-Zertifikat als Clientidentität angeben, kann die empfangende API das Zertifikat ablehnen, sobald die Clientauthentifizierung entfernt wird. Dies kann Integrationen unterbrechen, obwohl dasselbe Zertifikat für eingehende HTTPS-Verbindungen weiterhin normal funktioniert.
CI/CD- und DevOps-Workloads	Build-Server, Deployment-Agenten, Container und Automatisierungsplattformen verwenden möglicherweise Zertifikate zur Authentifizierung bei Registries, Kubernetes-Clustern, Artefakt-Repositories oder internen APIs. Wenn ein erneuertes Zertifikat die Client-Authentifizierung nicht mehr unterstützt, können automatisierte Pipelines fehlschlagen, ohne dass die Ursache unmittelbar ersichtlich ist.

Warum diese Fehler so schwer zu diagnostizieren sein können

Das Entfernen von clientAuth führt nicht zwangsläufig zu einer eindeutigen Fehlermeldung, die besagt, dass die EKU fehlt. Je nach Anwendung, Betriebssystem oder TLS-Bibliothek kann der Fehler wie folgt gemeldet werden:

• TLS-Handshake fehlgeschlagen
• Zweck der Bescheinigung nicht zulässig
• Nicht unterstütztes Zertifikat
• Schlechtes Zertifikat
• Zugriff verweigert
• Client-Identität abgelehnt
• Fehler bei der Peer-Verifizierung
• Authentifizierungs-Timeout

Dadurch kann das Problem leicht fälschlicherweise als Problem der Vertrauenskette, des Ablaufs, des Netzwerks, der Verschlüsselungssuite oder der Anwendungskonfiguration diagnostiziert werden.

Das größte Risiko beschränkt sich nicht auf Zertifikate, die bekanntermaßen Mutual TLS unterstützen. Es umfasst auch undokumentierte Systeme, die sich auf die ClientAuth-EKU verlassen haben, da öffentliche TLS-Zertifikate diese in der Vergangenheit standardmäßig enthielten.

Organisationen sollten diese Abhängigkeiten identifizieren, bevor die betroffenen Zertifikate erneuert oder neu ausgestellt werden. Ein Warten bis zur Erneuerung kann dazu führen, dass ein routinemäßiger Zertifikatsaustausch zu einem unerwarteten Ausfall führt, der die Anwendungskonnektivität, den Netzwerkzugriff, den Fernzugriff oder die Geräteauthentifizierung beeinträchtigt.

Die Lösung: Wechsel zu einer privaten Wirtschaftsprüfungsgesellschaft

Öffentlich vertrauenswürdige Zertifizierungsstellen dürfen keine TLS-Zertifikate mehr für die Clientauthentifizierung ausstellen (d. h. Zertifikate mit der clientAuth EKU). Daher können sich Organisationen nicht mehr auf öffentliche TLS-Zertifikate für interne Anwendungsfälle der Clientauthentifizierung wie Mutual TLS, Geräteauthentifizierung, Workload-Identität, API-Authentifizierung und Server-zu-Server-Kommunikation verlassen.

Eine private PKI löst dieses Problem, da sie außerhalb des von Browsern als vertrauenswürdig eingestuften öffentlichen PKI-Ökosystems operiert. Ihre Stammzertifizierungsstelle wird nur von den von der Organisation ausgewählten Benutzern, Geräten, Anwendungen und Systemen als vertrauenswürdig eingestuft. Daher kann die Organisation dedizierte Clientzertifikate ausstellen, die die ClientAuth-EKU enthalten, ohne das öffentliche Browservertrauen zu beeinträchtigen oder darauf angewiesen zu sein.

Private PKI ermöglicht zudem eine ordnungsgemäße Trennung der beiden Zertifizierungszwecke:

• Öffentliche oder private Serverzertifikate, die nur die ServerAuth-EKU enthalten
• Dedizierte private Clientzertifikate, die nur die clientAuth EKU (OID 1.3.6.1.5.5.7.3.2) enthalten, ohne serverAuth OID, wie im folgenden Screenshot dargestellt:

Diese Trennung gewährleistet, dass ein Serverzertifikat ausschließlich zur Authentifizierung eines Servers und ein Clientzertifikat ausschließlich zur Authentifizierung eines Benutzers, Geräts, einer Anwendung oder einer Workstation verwendet wird. Dadurch wird das Risiko eines Kompromittierungsfalls des privaten Schlüssels verringert und eine klarere Kontrolle über die Ausstellung, den Besitz, die Verlängerung und den Widerruf von Zertifikaten ermöglicht.

Mit einer privaten PKI können Organisationen zudem Zertifikatsrichtlinien definieren, die ihren spezifischen Sicherheitsanforderungen entsprechen. Dazu gehören Verfahren zur Identitätsprüfung, Gültigkeitsdauer von Zertifikaten, Namenskonventionen, zugelassene Algorithmen, Anforderungen an den Schlüsselschutz und Registrierungsmethoden. Zertifikate können mithilfe von Protokollen wie ACME, SCEP, EST, CMP, WSTEP oder Microsoft Auto-Enrollment automatisch ausgestellt und erneuert werden.

Diese Umstellung ermöglicht es Organisationen, Authentifizierungsabläufe zu entwickeln, die auf ihre spezifischen Bedürfnisse zugeschnitten sind, ohne durch die Beschränkungen öffentlicher Zertifizierungsstellen eingeschränkt zu sein. Im folgenden Abschnitt wird der Aufbau der PKI-Hierarchie beschrieben.

Wie sich die PKI-Hierarchie ändern muss

Das Entfernen der clientAuth-EKU aus öffentlich vertrauenswürdigen TLS-Zertifikaten ist nicht einfach eine Änderung der Zertifikatsvorlage. Es erfordert von Organisationen, die öffentliche Serverauthentifizierung von der internen Clientauthentifizierung auf PKI-Architekturebene zu trennen.

Nach dem neuen Modell sollten öffentlich vertrauenswürdige Zertifikate nur noch zur Authentifizierung von Servern gegenüber externen Clients verwendet werden, beispielsweise von Browsern, die sich mit Websites und öffentlich zugänglichen Anwendungen verbinden. Diese Zertifikate enthalten ausschließlich die ServerAuth -EKU und führen kontinuierlich zu einer öffentlich vertrauenswürdigen Stammzertifizierungsstelle.

Die Clientauthentifizierung muss in eine separate, private PKI-Hierarchie verlagert werden. Diese private Hierarchie stellt zweckspezifische Zertifikate für Benutzer, Geräte, Anwendungen, Workloads und Server aus, die sich als Clients authentifizieren müssen.

Die Zielarchitektur sollte daher Folgendes umfassen:

• Eine öffentliche TLS-PKI-Hierarchie für internetseitige Serverzertifikate, die nur ServerAuth enthält
• Eine private, offline betriebene und nicht in eine Domäne eingebundene Stammzertifizierungsstelle, die mit einem FIPS 140-3 Level 3-konformen Hardware-Sicherheitsmodul gesichert ist.
• Eine oder mehrere private ausstellende Zertifizierungsstellen (CAs), die der Client-Authentifizierung dienen. HSM-gestützter Schutz für die privaten Schlüssel der ausstellenden CAs.
• Clientzertifikatprofile sind ausschließlich auf die clientAuth EKU beschränkt (keine serverAuth OID vorhanden), wobei die Schlüsselverwendung auf digitalSignature eingestellt ist, sodass das Zertifikat unter keinen Umständen zur Serverauthentifizierung verwendet werden kann.

  

• Separate Zertifikatsprofile für Geräte, Benutzer, Workloads, APIs und andere Identitäten
• CRL- oder OCSP-Dienste für den Zertifikatswiderruf, wobei CDP-Endpunkte je nach Anwendungsfall und den Zugriffsanforderungen der Organisation als öffentlich oder privat konfiguriert werden.
• Automatisierte Zertifikatsausstellung, -verlängerung und -widerrufung
• Verteilung der privaten Stammzertifizierungsstelle an Systeme, die den Clientzertifikaten vertrauen müssen

Bei dieser Architektur benötigt ein Server, der beide Rollen ausführt, möglicherweise zwei separate Zertifikate:

1. Ein Serverzertifikat mit serverAuth zur Annahme eingehender TLS-Verbindungen
2. Ein Clientzertifikat mit der Information clientAuth zur Authentifizierung beim Verbinden mit einem anderen System

Diese Trennung gewährleistet, dass jedes Zertifikat und jeder private Schlüssel einen klar definierten Zweck hat. Sie ermöglicht es Organisationen außerdem, unterschiedliche Richtlinien für Identitätsvalidierung, Lebenszyklus, Widerruf und Schlüsselschutz auf Server- und Clientidentitäten anzuwenden.

Die Konzeption, Implementierung und der kontinuierliche Betrieb dieser privaten Hierarchie erfordern spezialisiertes PKI-Know-how, eine sichere HSM-Infrastruktur, die Automatisierung des Zertifikatslebenszyklus, Widerrufsdienste, Überwachung, Notfallwiederherstellung und fortlaufendes Richtlinienmanagement. Im folgenden Abschnitt dieses Blogs wird detailliert beschrieben, wie PKIaaS von Encryption Consulting eine vollständig verwaltete private Zertifizierungsstelle bereitstellt, die in Ihrem Namen erstellt, betrieben und deren Compliance sichergestellt wird.

PKIaaS von Encryption Consulting

Der Aufbau und Betrieb einer privaten PKI-Hierarchie ist konzeptionell technisch nicht komplex, in der Ausführung jedoch anspruchsvoll. Dies umfasst die Beschaffung von HSMs, Offline-Root-CA-Zeremonien, CDP/AIA-Zugänglichkeit, Automatisierung des Zertifikatslebenszyklus, Richtliniendokumentation und Registrierungsvorgänge.

Encryption Consulting bietet mit PKI-as-a-Service (PKIaaS) die Möglichkeit, auch unter Zeitdruck eine vollständige private PKI als Managed Service bereitzustellen . Encryption Consulting übernimmt Aufbau, Betrieb und Compliance der PKI, während Sie die volle Kontrolle behalten.

Keine Anbieterbindung: Ihre privaten Schlüssel, die CA-Hierarchie und die Zertifikate bleiben vollständig in Ihrem Besitz. Sollten Sie sich für die Migration Ihrer PKI in Ihre lokale Umgebung entscheiden, führt Encryption Consulting eine formelle, dokumentierte Schlüsselübertragung durch. Die privaten CA-Schlüssel werden mithilfe authentifizierter, doppelt kontrollierter Exportverfahren sicher auf Ihr HSM übertragen.

Ihre bestehenden Zertifikate behalten ihre Gültigkeit und müssen nicht neu ausgestellt werden. Der gesamte Übertragungsprozess wird vollständig dokumentiert und nachvollziehbar sein, um die Betriebskontinuität und die uneingeschränkte Eigentumsübertragung zu gewährleisten.

Sie sind Eigentümer der PKI. Wir entwickeln, verwalten und betreiben sie in Ihrem Auftrag. So funktioniert die Zusammenarbeit genau.

Phase 1: Ermittlung und Zertifikatsinventarisierung

Vor der Konzeption der neuen PKI erstellt Encryption Consulting einen umfassenden Überblick über die bestehende Zertifikatsumgebung des Kunden. Dies ist von entscheidender Bedeutung, da viele Systeme auf ClientAuth basieren, ohne dass diese Abhängigkeit explizit erkannt wird.

Wir unterstützen verschiedene Methoden zur Zertifikatserkennung , darunter Netzwerk-Scanning, agentenloses Scanning und integrationsbasierte Erkennung.

Die integrationsbasierte Erkennung bietet eine autoritative Echtzeit-Sicht auf Zertifikatsdaten durch die direkte Anbindung an Zertifizierungsstellen und Cloud-Plattformen wie AWS, Microsoft Azure und Google Cloud. Sie kann außerdem Anwendungskonfigurationen, einschließlich mTLS-Einstellungen, untersuchen und sich in Kubernetes-Cluster, Secrets-Management-Plattformen wie HashiCorp Vault und CyberArk Conjur sowie CI/CD-Pipelines wie GitHub Actions, Jenkins und GitLab integrieren.

Zu den zusätzlichen Erkennungsfunktionen gehören passive Überwachung über Proxys, Firewalls und Netzwerk-Taps; Verzeichnis-Scanning über LDAP und Active Directory; und Erkennung über Konfigurationsmanagement-Tools wie Ansible, Chef und Puppet.

Die Ausgabe ist ein vollständiges Zertifikatsinventar mit Zertifikatssubjekten, SANs, EKUs, Ausstellern und Ablaufdaten. Jedes Zertifikat mit ClientAuth ist sowohl dem ausstellenden System als auch dem System zugeordnet, das es zur Authentifizierung verwendet.

Die Ergebnisse werden anschließend in einem nach Risiko geordneten Migrationszeitplan dargestellt. Der Kunde erhält einen klaren Überblick darüber, welche Systeme ausfallen könnten, wann sie gefährdet sind und welche potenziellen Auswirkungen eine Zertifikatserneuerung ohne Client-Authentifizierung auf das Geschäft haben könnte.

Phase 2: PKI-Architekturdesign

Nichts wird gebaut, bevor die Architektur geprüft und freigegeben wurde. Jede Zertifizierungsstelle, jede Zertifikatvorlage und jeder Widerrufsendpunkt wird schriftlich festgelegt, bevor ein Schlüssel generiert wird.

Die Architektur umfasst typischerweise eine offline befindliche, nicht in die Domäne eingebundene Stammzertifizierungsstelle (Root CA) und separate ausstellende Zertifizierungsstellen (Issuing CAs) für die Clientauthentifizierung, internes TLS und die Geräteidentitätsauthentifizierung. Diese Trennung gewährleistet, dass Clientzertifikate ausschließlich clientAuth-Zertifikate enthalten.

Für jeden Anwendungsfall werden Zertifikatsprofile definiert, einschließlich Algorithmen, Gültigkeitszeiträume, Subjekt- und SAN-Formate, Schlüsselverwendung, EKU, Richtlinien-OIDs und Widerrufsendpunkte. CRL- und OCSP-Speicherorte werden je nach Verwendungsort der Zertifikate als öffentlich oder privat konfiguriert.

Dadurch entsteht eine klare, zweckorientierte Hierarchie ohne doppelte EKU-Zertifikate und ohne Unklarheiten darüber, wozu jedes Zertifikat berechtigt ist.

Phase 3: Root-CA-Zeremonie und Infrastrukturaufbau

Der private Schlüssel der Root-CA wird in einem FIPS 140-3 Level 3-konformen Hardware-Sicherheitsmodul (HSM) generiert und geschützt. Die Root-CA wird sicher im Rechenzentrum gehostet und zwischen autorisierten Zertifikatsignierungsvorgängen offline gehalten. Für die Notfallwiederherstellung wird eine verschlüsselte und zugriffskontrollierte Sicherung des Schlüsselmaterials in einer geografisch getrennten HSM-Umgebung aufbewahrt.

Encryption Consulting baut dann die unterstützende PKI-Infrastruktur auf, einschließlich gehärteter ausstellender Zertifizierungsstellen, OCSP-Responder, CRL-Veröffentlichungsdienste und Zertifikatsverwaltungsfunktionen.

Phase 4: Trust Store-Verteilung

Von einer privaten PKI ausgestellte Zertifikate gelten nur dann als vertrauenswürdig, wenn die private Stammzertifizierungsstelle auf jedem System installiert ist, das sie validiert. In dieser Phase wird das neue private Stammzertifizierungsstellenzertifikat an alle vertrauenden Systeme im Geltungsbereich verteilt.

Windows-Systeme in der Domäne erhalten die Stammzertifizierungsstelle per Gruppenrichtlinie, die im Speicher der vertrauenswürdigen Stammzertifizierungsstellen abgelegt wird. Linux-Systeme werden mit dem Befehl `update-ca-certificates` aktualisiert, der je nach verwendetem Konfigurationsmanagement-Toolchain über Ansible, Chef oder Puppet bereitgestellt wird.

Nach der Verteilung werden repräsentative Systeme mit neu ausgestellten Clientzertifikaten getestet. Diese Phase ist erst abgeschlossen, nachdem der Kunde bestätigt hat, dass die Zertifikatsketten vertrauenswürdig sind und die Authentifizierung erfolgreich war.

Phase 5: PKIaaS-Gateway-Bereitstellung

In dieser Phase wird das PKIaaS-Gateway bereitgestellt – eine Reihe von Registrierungs- und Verwaltungskomponenten, die in der Infrastruktur des Kunden installiert werden. Das Gateway verbindet die internen Systeme des Kunden mit der von Encryption Consulting gehosteten Zertifizierungsstellenhierarchie. Sämtliche Zertifikatsanforderungen werden über das Gateway geleitet. Die privaten Schlüssel der Zertifizierungsstellen verbleiben stets in den HSMs von Encryption Consulting. Das Gateway verarbeitet ausschließlich den Datenverkehr des Registrierungsprotokolls und führt keine Signiervorgänge durch.

Das Gateway stellt einen WSTEP-Endpunkt (WS-Trust Enrollment Protocol) bereit, der die vollautomatische Zertifikatsregistrierung für Windows-Rechner ohne Benutzer- oder Administratorinteraktion ermöglicht. Der Zertifikatsregistrierungsrichtliniendienst (CEP) ist so konfiguriert, dass er anhand seiner Active Directory-Identität und Gruppenrichtlinienmitgliedschaft erkennt, für welche Zertifikatvorlagen er berechtigt ist.

Der Zertifikatregistrierungs-Webdienst validiert die Anfrage anhand der Registrierungsrichtlinie, leitet sie über das PKIaaS-Gateway an die ausstellende Zertifizierungsstelle weiter und sendet das signierte Zertifikat direkt an den Rechner zurück, der es automatisch im korrekten Zertifikatsspeicher installiert. Ab der GPO-Konfiguration ist für den gesamten Lebenszyklus – Richtlinienermittlung, Anfrage, Signierung, Installation und Erneuerung – kein manueller Eingriff erforderlich.

Ein webbasiertes Dashboard, über das autorisierte Benutzer Zertifikate anfordern, CSRs einreichen, den Zertifikatsbestand durchsuchen, Zertifikate erneuern, kompromittierte oder ungenutzte Zertifikate widerrufen und den Zertifikatsstatus überprüfen können.

Das Dashboard beinhaltet eine rollenbasierte Zugriffskontrolle. Zertifikatsmanager können Zertifikate anfordern oder widerrufen, Prüfer können Berichte und Aktivitätsprotokolle einsehen, und Administratoren können genehmigte Profile und Registrierungsrichtlinien verwalten.

Jede Anmeldung, Verlängerung, Widerrufung, Genehmigung, Konfigurationsänderung und jeder administrative Login wird in einem revisionssicheren Aktivitätsprotokoll erfasst.

Phase 6: Zertifikatsmigration: System für System

Sobald die Vertrauens- und Registrierungsdienste betriebsbereit sind, beginnt Encryption Consulting mit dem Austausch der öffentlichen Dual-EKU-Zertifikate gegen dedizierte private Client-Zertifikate.

Die Migration beginnt mit Entwicklungs- und Testumgebungen. Anschließend werden interne Dienste und APIs migriert, gefolgt von der Netzwerkinfrastruktur, einschließlich VPN, RADIUS und 802.1X. Geschäftskritische Systeme wie Exchange, Kernanwendungen und unternehmensinterne Systeme werden erst migriert, nachdem Tests und Rollback-Verfahren erfolgreich abgeschlossen wurden.

Jede Zertifikatsanforderung wird über die entsprechende Registrierungsmethode (z. B. WSTEP, ACME, SCEP, EST oder das Management-Dashboard) eingereicht. Das neue Zertifikat enthält ausschließlich die ClientAuth-EKU. Die Anwendung wird so konfiguriert, dass sie das neue Zertifikat präsentiert, und ein End-to-End-Authentifizierungstest bestätigt die erfolgreiche Verbindung.

Nach erfolgreicher Validierung wird das alte Dual-EKU-Zertifikat gegebenenfalls entfernt oder widerrufen, und das neue Zertifikat wird für die automatische Verlängerung registriert.

Phase 7: Laufender Betrieb und Einhaltung der Vorschriften

In dieser Phase bietet PKIaaS auch über die anfängliche Einrichtung hinaus kontinuierlichen Mehrwert.

Die CLM-Plattform von Encryption Consulting verwaltet fortlaufend die Ausstellung, Erneuerung und den Widerruf von Zertifikaten, die Veröffentlichung von CRLs, die OCSP-Verfügbarkeit, die HSM-Überwachung, die Infrastrukturwartung, die Backup-Validierung und den Betrieb des PKIaaS-Gateways.

Registrierungsdienste wie WSTEP, ACME, SCEP und EST werden kontinuierlich gewartet, sodass Zertifikate ohne manuelle Eingriffe ausgestellt und erneuert werden können.

Encryption Consulting überwacht zudem die Sicherheitsanforderungen relevanter Organisationen, Entwicklungen im CA/Browser Forum, kryptografische Standards, Algorithmusänderungen und Aktualisierungen der Zertifikatsrichtlinien, wie beispielsweise die Kompatibilität mit Post-Quanten-Kryptografie . Wenn eine Änderung die Umgebung des Kunden betrifft, werden die PKI-Konfiguration und die Zertifikatsprofile vor dem jeweiligen Stichtag aktualisiert.

Fazit

Die Entfernung der clientAuth-EKU aus öffentlich vertrauenswürdigen TLS-Zertifikaten markiert einen grundlegenden Wandel im Umgang von Unternehmen mit zertifikatsbasierter Authentifizierung. Öffentliche Zertifikate sichern weiterhin Websites und externe Dienste, die Client-Authentifizierung für Benutzer, Geräte, Anwendungen und Workloads muss jedoch auf eine speziell dafür entwickelte private PKI umgestellt werden. Unternehmen, die versteckte Abhängigkeiten zwischen zwei EKUs nicht erkennen, riskieren unerwartete Ausfälle bei der Zertifikatserneuerung ohne clientAuth. Diese Ausfälle äußern sich nicht als Zertifikatsfehler, sondern als Authentifizierungs-Timeouts, TLS-Handshake-Fehler oder Zugriffsverweigerungen ohne erkennbare Ursache.

Encryption Consulting bietet mit PKIaaS einen Komplettservice für diesen Übergang. Wir analysieren Ihre bestehende Umgebung, identifizieren betroffene Systeme, konzipieren und implementieren die private PKI, schützen CA-Schlüssel in HSMs, stellen Registrierungsdienste bereit, migrieren Zertifikate und verwalten die Umgebung fortlaufend. Die automatisierte Registrierung über WSTEP, ACME, SCEP und EST gewährleistet die Ausstellung, Verlängerung und den Widerruf von Zertifikaten ohne zusätzlichen Betriebsaufwand.

Für eine kostenlose PKI-Readiness-Analyse kontaktieren Sie uns unter [email protected] oder besuchen Sie encryptionconsulting.com/pkiaas.

Häufig gestellte Fragen

Was ist die wichtigste Erkenntnis aus dem CA/Browser Forum Mandat: Das Ende der Dual-EKU-Zertifikate?

Die CA/Browser Forum-Abstimmung SC-081v3 (April 2025) und die Chrome-Root-Programmrichtlinie v1.8 sehen die Abschaffung der Client-Authentifizierung aus öffentlich vertrauenswürdigen TLS-Zertifikaten nach einem festen Zeitplan vor. Ab dem 15. Juni 2026 dürfen neue Zwischenzertifizierungsstellen in einer von Chrome als vertrauenswürdig eingestuften Hierarchie keine doppelten EKU-Werte mehr enthalten. Ab dem 15. März 2027 muss jedes neu ausgestellte öffentlich vertrauenswürdige TLS-Endzertifikat ausschließlich die Server-Authentifizierung enthalten. Organisationen, die öffentliche Zertifikate für mTLS, RADIUS, VPN, IoT-Geräteidentität oder Server-zu-Server-Authentifizierung verwenden, müssen diese Anwendungsfälle vor diesen Fristen auf eine dedizierte private PKI-Hierarchie migrieren, um bei der Erneuerung betroffener Zertifikate nicht unbemerkt Authentifizierungsfehler zu riskieren.

Warum ist die Dual-EKU-Vorgabe für PKI-Teams in Unternehmen relevant?

PKI-Teams in Unternehmen stehen unter doppeltem Druck. Die DigiCert Trust Pulse Survey (2. Juli 2025) ergab, dass 45 Prozent der Unternehmen im Vorjahr Ausfallzeiten aufgrund von Zertifikatsproblemen verzeichneten. Die Dual-EKU-Pflicht führt genau zu dem stillen Fehler, der diese Ausfallzeiten verursacht: Ein ohne Client-Authentifizierung erneuertes Zertifikat funktioniert zwar weiterhin für HTTPS, schlägt aber bei allen Client-Authentifizierungsanwendungen mit allgemeinen Fehlern fehl. Gleichzeitig reduziert SC-081v3 die maximale TLS-Gültigkeit bis März 2029 auf 47 Tage. Das bedeutet, dass Erneuerungsereignisse, die Dual-EKU-Abhängigkeiten offenlegen, bis zu achtmal pro Jahr statt nur einmal auftreten.

Welche Risiken erhöhen sich, wenn der Übergang zur dualen EKU manuell oder reaktiv erfolgt?

Vier Risikokategorien nehmen zu: stille Authentifizierungsausfälle (generische Fehlermeldungen, die leicht falsch diagnostiziert werden können); unentdeckte Abhängigkeiten (Systeme, die auf clientAuth ohne formale Dokumentation angewiesen sind); verkürzte Behebungszeit (bei einer Gültigkeit von 47 Tagen beträgt das Zeitfenster zwischen Erneuerung und Ausfall sechs Wochen statt zwölf Monate); und Lücken bei der Migration nach der Quantenmigration (private CA-Schlüsselalgorithmen müssen gemäß NIST FIPS 204, finalisiert am 13. August 2024, ebenfalls auf ML-DSA migriert werden; eine ungeplante private PKI lässt sich schwieriger in den Migrationsfahrplan integrieren).

Welchen Teams sollte der Übergang zu zwei EKU-Teams die Verantwortung übertragen werden?

Die PKI- und Zertifikatsteams sind für die Architektur der privaten Zertifizierungsstelle und die Trennung der Zertifikatvorlagen verantwortlich. Die Sicherheitsarchitekten verantworten das Governance-Modell: die Verteilung des Vertrauens der privaten Stammzertifizierungsstelle, die Auswahl des Registrierungsprotokolls und die Planung der Migration nach der Quantenmigration für die Algorithmen der privaten Zertifizierungsstellenschlüssel. Die Plattform- und DevOps-Teams sind für die Migration auf Anwendungsebene zuständig: die Neukonfiguration von mTLS, RADIUS, VPN, IoT und CI/CD-Systemen. Die Compliance-Teams stellen die Prüfnachweise bereit, die bestätigen, dass die Migration vor dem Stichtag am 15. März 2027 abgeschlossen ist.

Wie hängt das Dual-EKU-Mandat mit dem Zertifikatslebenszyklusmanagement zusammen?

Das Mandat ist ein Ereignis im Zertifikatslebenszyklus: Jedes öffentliche TLS-Zertifikat, das derzeit clientAuth enthält, verliert diese EKU bei der nächsten Verlängerung. Zertifikatserkennung und -inventarisierung sind Voraussetzungen für ein sicheres Lebenszyklusmanagement: Organisationen, die nicht wissen, welche Zertifikate clientAuth enthalten, können den Verlängerungszyklus nicht sicher verwalten, ohne das Risiko von Authentifizierungsausfällen einzugehen. CertSecure Manager bietet die CLM-Ebene: automatisierte Erkennung von clientAuth-Abhängigkeiten, Richtliniendurchsetzung bei der Ausstellung (EKU-getrennte Profile), automatisierte Verlängerung über WSTEP/ACME/SCEP/EST, Widerrufsmanagement und revisionssichere Berichte.

Wie sollten Organisationen den Erfolg beim Übergang zum dualen EKU-System messen?

Wichtige Kennzahlen: Keine öffentlich vertrauenswürdigen Zertifikate, die sowohl Server- als auch Clientauthentifizierung umfassen; 100 % der Anwendungsfälle für die Clientauthentifizierung wurden auf private Zertifikate mit ausschließlicher Clientauthentifizierung migriert; keine Authentifizierungsausfälle aufgrund der Entfernung der Clientauthentifizierung bei der Zertifikatserneuerung; Abdeckung der automatisierten Registrierung privater PKI (Anteil der Clientzertifikate mit automatisierter Erneuerung); und Klassifizierung der Bereitschaft nach der Quantentechnologie (Klassifizierung der privaten CA-Schlüsselalgorithmen gemäß NIST IR 8547 mit definiertem Migrationszeitplan). Diese Kennzahlen sind vierteljährlich gemäß dem Zeitplan des CA/Browser Forums zu melden.

Was sollte regelmäßig geprüft oder überwacht werden?

Kontinuierliche Überwachung: Zertifikatsbestand für öffentlich vertrauenswürdige Zertifikate mit Server- und Clientauthentifizierung, inklusive Warnmeldungen für Dual-EKU-Zertifikate vor der Verlängerung; Erfolgsraten der mTLS-, RADIUS-, VPN- und IoT-Authentifizierung zur frühzeitigen Erkennung von Fehlern bei der Clientauthentifizierungsentfernung. Vierteljährliche Prüfung: Anteil der auf private Zertifikate migrierten Clientauthentifizierungsfälle; Abdeckung der automatisierten Registrierung privater Zertifizierungsstellen; Klassifizierung der Schlüsselalgorithmen privater Zertifizierungsstellen gemäß NIST FIPS 203/204/205 (finalisiert am 13. August 2024); Vollständigkeit der Nachweise zur Einhaltung der Vorschriften bis zum 15. März 2027.

Wie wirkt sich die Dual-EKU-Pflicht auf Cloud-, Hybrid- oder Multi-CA-PKI-Umgebungen aus?

Cloud- und Hybridumgebungen weisen typischerweise die höchste Dichte an unentdeckten Dual-EKU-Abhängigkeiten auf: Microservices, die mTLS mit öffentlichen Zertifikaten verwenden, Cloud-native Workloads mit zertifikatsbasierter Authentifizierung für Cloud-APIs, Kubernetes-Cluster mit Zertifikaten für die Service-Mesh-Identität und CI/CD-Pipelines, die sich bei Registries authentifizieren. Multi-CA-Umgebungen benötigen eine zentrale CLM-Schicht, die Client-Authentifizierungsabhängigkeiten über alle CA-Quellen hinweg erkennt, nicht nur über das öffentliche CA-Inventar, einschließlich AWS Private CA, HashiCorp Vault PKI und Microsoft AD CS.

Welche häufigen Fehler sollten Teams vermeiden?

Die häufigsten Fehler: Nichtbeachtung der Abhängigkeiten von clientAuth vor der Zertifikatserneuerung; Behandlung des Mandats lediglich als Änderung der Zertifikatsvorlage, ohne die PKI-Hierarchie auf CA-Ebene zu trennen (die Chrome-Root-Programmrichtlinie erfordert eine Trennung auf CA-Ebene); Nichtverteilung der privaten Root-CA an alle vertrauenden Systeme vor der Migration; Aufbau einer privaten PKI unter Zeitdruck ohne Planung der Post-Quantum-Migration der privaten CA-Schlüsselalgorithmen; und Nichtregistrierung migrierter Clientzertifikate in automatisierte Erneuerungsprozesse, die eine Gültigkeit von 47 Tagen ab März 2029 gewährleisten können.

Was sollte vierteljährlich aktualisiert werden?

Vierteljährlich: Prüfen Sie das Zertifikatsinventar auf öffentlich vertrauenswürdige Zertifikate, die noch Client-Authentifizierung enthalten; vergewissern Sie sich, dass die private Stammzertifizierungsstelle an alle seit der letzten Prüfung hinzugefügten Systeme verteilt wurde; bestätigen Sie die Abdeckung der automatisierten Registrierung privater Zertifizierungsstellen für alle Anwendungsfälle der Client-Authentifizierung; klassifizieren Sie die Algorithmen für private Zertifizierungsstellenschlüssel anhand der NIST-Meilensteine ​​für die Post-Quantum-Abschaffung (ML-DSA gemäß FIPS 204, finalisiert am 13. August 2024); vergewissern Sie sich, dass keine neuen Dual-EKU-Zwischenzertifizierungsstellen in den Chrome-vertrauenswürdigen Hierarchien an CCADB gemeldet wurden (verboten ab dem 15. Juni 2026). Informationen zur Migrationsplanung von Algorithmen für private Zertifizierungsstellenschlüssel nach der Abschaffung der Quantenzertifizierung finden Sie im PQC Center of Excellence.