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 und nicht nur auf Zertifikatsebene erfolgen.

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.

Das Mandat: Was benötigen SC-081 und das Chrome Root-Programm?

Ö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 ein von Chrome als vertrauenswürdig eingestuftes Stammzertifikat verweist, ausschließlich Serverauthentifizierung unterstützen. Chrome lehnt ab diesem Zeitpunkt öffentliche TLS-Endzertifikate ab, die noch die Clientauthentifizierungs-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 Clientauthentifizierung 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 finden Sie den vollständigen 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 muss sich die PKI-Hierarchie ändern?

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 Zertifikatfehler, 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.