Entfernung der clientAuth-EKU: Wo mTLS versagt und wie man zu einer privaten PKI migriert.

Ihr mTLS-Netzwerk kann alle Integritätsprüfungen bestehen, alle Zertifikate planmäßig erneuern und trotzdem über Nacht die Client-Authentifizierung einstellen. Nichts wird gehackt. Nichts läuft vorzeitig ab. Ein Zertifikat wird einfach erneuert, kommt aber stillschweigend mit einem fehlenden Wert für die erweiterte Schlüsselverwendung zurück, und der nächste, davon abhängige Handshake schlägt fehl. So verläuft die Abschaffung der Client-Authentifizierung, und sie hat bereits begonnen.

TL; DR Die Chrome-Root-Programmrichtlinie v1.8, Abschnitt 1.3.2, entfernt die erweiterte Client-Authentifizierung (EKU) aus öffentlich vertrauenswürdigen TLS-Endzertifikaten. Neue untergeordnete Zertifizierungsstellen müssen seit dem 15. Juni 2026 ausschließlich Server-Authentifizierung unterstützen, und jedes neue öffentliche Endzertifikat muss bis zum 15. März 2027 ebenfalls ausschließlich Server-Authentifizierung unterstützen. Ihre Zertifizierungsstelle wird die Umstellung höchstwahrscheinlich vor dem von Chrome festgelegten Stichtag vornehmen. DigiCert, Sectigo, Let's Encrypt, Google Trust Services und SSL.com haben bereits frühere interne Stichtage festgelegt, teilweise schon im September 2025. Die Änderung ist beabsichtigt: Bestehende Zertifikate funktionieren bis zu ihrem Ablaufdatum, sodass die Änderung erst bei der nächsten regulären Zertifikatserneuerung und nicht an einem festgelegten Stichtag sichtbar wird. Sie kann sich Stunden oder Tage später auf unabhängiger Infrastruktur bemerkbar machen. Die Neuausstellung oder das Festlegen des Endzertifikats behebt das Problem nicht. Verifizierer berechnen die effektive EKU als Schnittmenge aller Zertifikate in der Kette. Sobald Ihre ausstellende Hierarchie also nur noch Serverauthentifizierung unterstützt, wird die Clientauthentifizierungs-OID des Endknotens nicht mehr berücksichtigt, selbst wenn sie noch auf dem Zertifikat steht. Die dauerhafte Lösung ist eine private PKI, die Sie für die Client- und Maschinenidentität verwalten. Diese kann intern entwickelt oder als PKI-as-a-Service bezogen und in vier Phasen mit einem unterbrechungsfreien Migrationsplan implementiert werden.

Wichtige Erkenntnisse

• Kenne das Mandat: Die Chrome-Root-Programmrichtlinie v1.8 ist die Quelle. Am 15. Juni 2026 wurden bereits Hierarchien für Sub-CAs mit einem einzigen Verwendungszweck eingeführt. Der 15. März 2027 ist der endgültige Stichtag für die Umstellung auf Endzertifikate. Ihre eigene CA wird die Umstellung wahrscheinlich vor einem dieser beiden Termine vornehmen.
• Aktueller Lagerbestand, nicht erst zum Erneuerungszeitpunkt: Finden Sie jeden ClientAuth-Konsumenten in mTLS, Service Mesh, IoT, VPN, 802.1X, SIP und älteren Machine-to-Machine-Systemen.
• Umgehen Sie die Sackgassen: Opt-in-Flags, Last-Minute-Neuausstellungen und Nicht-Browser-Roots verzögern den Abgrund nur. Eine private PKI ist die einzige Option, die Ihnen EKUs und eine Ausgaberichtlinie bietet, die Sie tatsächlich kontrollieren.
• Prüfen Sie die gesamte Kette, nicht nur das einzelne Blatt: Ein zwischengeschalteter Client, der die Authentifizierung verliert, kann ein Endbenutzerzertifikat ungültig machen, bevor dessen eigene Erneuerung überhaupt erfolgt.
• Suchen Sie über Ihren eigenen Zertifikatsbestand hinaus: Die Protokolle der Zertifikatstransparenz decken vergessene und Schatten-IT-Zertifikate auf, die in Ihren eigenen Aufzeichnungen fehlen.
• Bewusst migrieren: Entdecken, entwerfen, bereitstellen, dann mit parallelem Vertrauen umstellen und die gesamte Kette in der Staging-Umgebung validieren, bevor eine Produktionserneuerung das Problem für Sie erzwingt.

Was ändert sich tatsächlich?

Jahrelang konnte ein öffentlich vertrauenswürdiges TLS-Zertifikat zwei Extended Key Usage-Werte gleichzeitig enthalten: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) und id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2), wie in RFC 5280 Abschnitt 4.2.1.12 definiert. Ein einzelnes Zertifikat konnte HTTPS als Server beenden und sich auch als Client in mTLS-, Service-to-Service- und Machine-Identity-Flows authentifizieren.

Gemäß Chrome-Root-Programmrichtlinie v1.8, Abschnitt 1.3.2, entfällt diese Doppelfunktion. Neue, öffentlich vertrauenswürdige TLS-Endzertifikate enthalten ausschließlich Serverauthentifizierung. Bestehende Zertifikate mit Doppelfunktion bleiben bis zu ihrem Ablaufdatum gültig, jedoch enthalten alle nach dem Gültigkeitsdatum Ihrer Zertifizierungsstelle ausgestellten Verlängerungen standardmäßig nur Serverauthentifizierung.

Zwei Daten sind auf Richtlinienebene von Bedeutung: Neue, dem CCADB gemeldete untergeordnete Zertifizierungsstellen müssen seit dem 15. Juni 2026 ausschließlich ServerAuth verwenden, und jedes Teilnehmerzertifikat (Leaf-Zertifikat), das ab dem 15. März 2027 ausgestellt wird, muss ebenfalls ausschließlich ServerAuth gewährleisten. Google brachte diese Aufteilung erstmals im Oktober 2024 auf dem F2F-63-Treffen des CA/Browser-Forums zur Sprache und verankerte sie anschließend als Richtlinie des Chrome-Root-Programms anstatt durch eine Abstimmung des CA/Browser-Forums. Da Chrome nach wie vor rund zwei Drittel des globalen Browsermarktes ausmacht, riskiert eine öffentliche Zertifizierungsstelle, die das Chrome-Root-Programm ignoriert, das Vertrauen eines Großteils des Webs zu verlieren. Daher behandeln alle großen Zertifizierungsstellen die Richtlinie als verbindlich.

Dieser Artikel setzt voraus, dass Sie diese Grundlagen bereits kennen. Die vollständige Entstehungsgeschichte des Mandats, die Rolle des CA/Browser-Forums und die einzelnen Abschnitte der Chrome-Richtlinien finden Sie in den detaillierten Analysen von Encryption Consulting zur Chrome-Root-Programmrichtlinie v1.8 und dem CA/Browser-Forum-Mandat . Im Folgenden wird der Teil behandelt, der in den meisten Berichten zu dieser Änderung ausgelassen wird: Wo genau Ihre Infrastruktur Probleme bereitet, wie Sie jedes gefährdete Zertifikat finden und wie Sie die Client-Identität vor einer anstehenden Erneuerung, die das Problem im Produktivbetrieb auslöst, dauerhaft sichern.

Die von Ihrer Zertifizierungsstelle festgelegte Frist, nicht die von Chrome, ist Ihre tatsächliche Frist.

Öffentliche Zertifizierungsstellen sind den von Chrome selbst festgelegten Gültigkeitsdauern deutlich voraus. Bestehende Zertifikate funktionieren bis zu ihrem Ablaufdatum, aber die erste Verlängerung nach dem Stichtag Ihrer Zertifizierungsstelle erlaubt nur noch die Serverauthentifizierung. Genau dann bricht die Clientauthentifizierung stillschweigend zusammen.

Zertifizierungsstelle	Clientauthentifizierung ist standardmäßig deaktiviert.	Harte Abschaltung (keine Client-Authentifizierung erfolgt)
DigiCert	1. Oktober 2025	1. März 2027 (alle DigiCert-Marken)
Sektigo	7. Oktober 2025	10. Februar 2027, ohne Ausnahmen
Lass uns verschlüsseln	11. Februar 2026 (Standard-ACME-Profil)	8. Juli 2026 (tlsClient-Brückenprofil außer Betrieb genommen)
Google Trust Services	10. November 2025 (CSRs abgelehnt)	13. April 2026, ohne Ausnahmen
SSL.com	September 15, 2025	Ausgerichtet auf Chrome, 15. März 2027

Prüfen Sie direkt die Hinweise Ihrer zuständigen Behörde; einige dieser Termine wurden bereits einmal vorverlegt, und die Behörden scheuen sich nicht, die Verfahren weiter zu beschleunigen.

Warum die Aufteilung tatsächlich die richtige Entscheidung ist

Man könnte versucht sein, dies als bürokratische Umgehung eines Browserherstellers abzutun. Das ist es aber nicht, und es lohnt sich, die Gründe dafür zu verstehen, bevor man seine Architektur entsprechend anpasst, denn dieselbe Logik sollte auch die Gestaltung der privaten PKI, zu der Sie migrieren, prägen.

Validierung ist nicht gleich Autorisierung: Die Ausstellung öffentlicher Zertifikate belegt die Domänenkontrolle durch Methoden wie ACME HTTP-01 und DNS-01 gemäß RFC 8555, Abschnitte 8.3 und 8.4, oder die Organisationsidentität für OV- und EV-Zertifikate gemäß Abschnitt 3.2.2.4 der Basisanforderungen. Nichts davon bestätigt jedoch, dass ein System berechtigt ist, als Client gegenüber Ihrer Infrastruktur zu agieren. Ein öffentliches ClientAuth-Zertifikat bewirbt stets eine Vertrauenseigenschaft, die die ausstellende Zertifizierungsstelle nie validiert hat.

Die doppelte Verwendung von EKUs verdoppelt die potenziellen Folgen eines gestohlenen Schlüssels: Ein Zertifikat, das sowohl Server- als auch Clientauthentifizierung enthält, ermöglicht es einem Angreifer mit einem kompromittierten privaten Schlüssel, sich als Ihr Server auszugeben und sich lateral im Netzwerk als vertrauenswürdiger Client zu bewegen – und dabei denselben Schlüssel für beides zu verwenden. Die Trennung von Zertifikaten, Schlüsseln und Lebenszyklen nach Zweck beseitigt diesen zweiten Angriffsweg vollständig. Es handelt sich um das Prinzip der minimalen Berechtigungen, angewendet auf Zertifikate – keine neue Idee, sondern nun endlich auf EKU-Ebene umgesetzt.

Wo der mTLS-Handshake tatsächlich abbricht

Dies ist das Detail, das die meisten Erklärer dieser Änderung auslassen, und doch ist es das, was am wichtigsten ist, wenn man um 2 Uhr nachts eine Webseite debuggt.

Bei einem gegenseitigen TLS-Handshake sendet der Server eine CertificateRequest, der Client antwortet mit seinem Zertifikat und sendet anschließend eine CertificateVerify-Signatur, die beweist, dass er den zugehörigen privaten Schlüssel besitzt (dies ist der TLS-1.3-Ablauf; TLS 1.2 fügt dazwischen einen unverschlüsselten ClientKeyExchange-Schritt hinzu, der Fehlerpunkt ist jedoch identisch). Der Verifizierer führt hier zwei völlig unabhängige Prüfungen durch, und die Vermischung dieser Prüfungen ist die häufigste Fehlerursache bei der Fehleranalyse.

Zunächst wird die Pfadvalidierung gemäß RFC 5280 Abschnitt 6 durchgeführt, wobei die Zertifikatskette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle erstellt und geprüft wird. Dieser Schritt ist erfolgreich. Die Zertifikatskette ist vollständig gültig. RFC 5280 definiert die EKU-Erweiterung selbst in Abschnitt 4.2.1.12, schreibt jedoch keinen Prüfer vor, der den Zweck der EKU im Rahmen der Pfadvalidierung überprüft.

Diese Zweckprüfung wird von der jeweiligen TLS-Implementierung zusätzlich durchgeführt und ist nicht im RFC vorgeschrieben. Gängige Bibliotheken wie OpenSSL, JSSE (Java), crypto/tls (Go) und rustls (Rust) erzwingen standardmäßig die Validierung des EKU-Zwecks: Sie suchen im vorgelegten Zertifikat nach clientAuth, finden es nicht und lehnen das Zertifikat sofort ab. Dies ist ein schwerwiegender Authentifizierungsfehler, keine Warnung, und tritt typischerweise auf, sobald der Verifizierer die EKU des Client-Zertifikats auswertet, oft direkt in der Zertifikatsnachricht und nicht erst nach CertificateVerify. Vor dieser Prüfung werden keine Anwendungsdaten übertragen.

Die Durchsetzung erfolgt bewusst und nicht zufällig. Im Issue-Tracker von Go ist ein Fall dokumentiert (golang/go#23884), in dem ein Clientzertifikat, das ausschließlich für Serverauthentifizierung verwendet wurde, unter Go 1.9.4 mit `RequireAndVerifyClientCert` korrekt abgelehnt, nach einer Regression in Go 1.10 jedoch fälschlicherweise akzeptiert wurde. Die Go-Entwickler behandelten die Regression als Fehler und behoben ihn. Dies ist ein deutlicher Beweis dafür, dass die Durchsetzung von EKU das beabsichtigte Standardverhalten im gesamten Ökosystem ist und kein Sonderfall, den man ignorieren kann.

Die Kettenfalle: Das erneute Ausgeben des Blattes wird dich nicht retten.

Hier liegt das Detail, das Teams, die glauben, sich Zeit verschafft zu haben, in die Falle lockt. Prüfprogramme wie Chrome und die zugrundeliegenden TLS-Stacks überprüfen nicht nur die EKU des Endzertifikats. Sie validieren die gesamte Zertifikatskette, und die effektive EKU eines Zertifikats ist die Schnittmenge der von jedem Zertifikat in der Kette darüber erlaubten Zwecke.

Betrachten wir ein Endzertifikat, das sowohl ServerAuth als auch ClientAuth auflistet und von einer Zwischenzertifizierungsstelle ausgestellt wurde, die zu einer Hierarchie migriert ist, die nur noch ServerAuth verwendet:

{ serverAuth } ∩ { serverAuth, clientAuth } = { serverAuth }

Die ClientAuth-OID des Endzertifikats ist weiterhin im Zertifikat enthalten. Sie wird einfach ignoriert, da kein Zertifikat oberhalb des Endzertifikats eine EKU enthalten darf, die ClientAuth zu diesem Zweck ausschließt, um in der Zertifikatskette erhalten zu bleiben. Diese Ignorierung funktioniert: Ein Zwischenzertifikat einer Zertifizierungsstelle ohne jegliche EKU-Erweiterung ist uneingeschränkt nutzbar. Erst eine explizite EKU, die ClientAuth auslässt, führt zu Problemen in allen nachfolgenden Zertifikaten.

Die praktische Konsequenz: Sobald die Hierarchie Ihrer ausstellenden Zertifizierungsstelle auf reine Serverauthentifizierung umgestellt hat, können Sie die Clientauthentifizierung nicht durch Neuausstellung oder Fixierung Ihres bestehenden Endzertifikats aufrechterhalten. Eine Zwischenzertifizierungsstelle kann die Clientauthentifizierungsfunktion für alle darunterliegenden Zertifizierungsstellen verlieren, bevor das Ablaufdatum eines einzelnen Endzertifikats erreicht ist. Wenn Sie nur die Ablaufdaten von Endzertifikaten überwachen, verfolgen Sie die falsche Zeit.

Welche Arbeitslasten verursachen stillschweigende Fehler?

Der Wirkungsbereich ist größer als die meisten Zertifikatsverzeichnisse annehmen, und die Durchsetzung variiert je nach Anbieter, was es schwierig macht, dies allein anhand einer Tabellenkalkulation abzuschätzen.

Arbeitsbelastung	Warum es von der Client-Authentifizierung abhängt	Durchsetzungshinweise
mTLS / Service Mesh	Sidecars authentifizieren sich gegenseitig mit Client-Zertifikaten für den Ost-West-Verkehr.	Üblicherweise streng; dort, wo Ausfälle am deutlichsten sichtbar sind
Partner- und B2B-APIs	Gateways präsentieren Client-Zertifikate, um die Identität in organisationsübergreifenden mTLS-Verbindungen nachzuweisen.	Vertraglich streng in den meisten Integrationen
IoT- und Geräteidentität	Jedes Gerät stellt ein Kundenzertifikat aus, um zu beweisen, zu welchem ​​Flottenmitglied es gehört.	Streng; Geräteflotten lassen sich nur schwer schnell patchen
VPN-Client-Authentifizierung	Clients authentifizieren sich am Gateway mit einem Zertifikat (OpenVPN, AnyConnect, Fortinet).	Anbieterabhängig, im Allgemeinen streng
Wi-Fi / 802.1X (EAP-TLS)	Das Clientzertifikat (Gerätezertifikat) enthält typischerweise die ClientAuth-Informationen.	RFC 5216 §5.3 empfiehlt die Überprüfung, akzeptiert aber auch das vollständige Fehlen von EKU.
SIP / SBC / Unified Communications	Einige Mobilfunkanbieter verlangen eine Clientauthentifizierung für die Vertrauensstellung des Session Border Controllers.	Abhängig vom Mobilfunkanbieter; die Dokumentation zu Microsoft Teams Direct Routing akzeptiert derzeit SBC-Zertifikate ohne Client-Authentifizierung.
Load Balancer	Clientzertifikate prüfen, Clientauthentifizierung jedoch nur erzwingen, wenn explizit konfiguriert	F5 BIG-IP setzt den EKU-Zweck nur dann durch, wenn ein Administrator diese Regel aktiviert.
Legacy-Middleware für die Maschine-zu-Maschine-Kommunikation	Ältere Systeme erwarten ein Zertifikat mit doppelter Zweckbestimmung für beide Rollen.	Oft am schwierigsten zu beheben; häufig im Besitz keines aktuellen Teams

Die wichtigste Erkenntnis ist, dass die Durchsetzung tatsächlich vom jeweiligen Anbieter abhängt. Überprüfen Sie Ihre eigene Systemarchitektur, anstatt anzunehmen, dass alle in dieser Tabelle aufgeführten Workloads am selben Tag ausfallen; manche funktionieren möglicherweise aufgrund einer technischen Einschränkung noch einigermaßen, bis ein zukünftiges Update auch diese Lücke schließt.

Das stille Ausfallmuster

Das Gefährlichste an dieser Veränderung ist, dass sie sich nicht ankündigt. Die Fehlerkette sieht folgendermaßen aus:

1. Der Tag der Entscheidung ist gekommen: Es passiert nichts. Bestehende Dual-EKU-Zertifikate bleiben bis zu ihrem jeweiligen Ablaufdatum gültig.
2. Wochen vergehen: Die Bereitstellungen laufen absolut stabil. Die automatisierten ACME-Erneuerungen funktionieren weiterhin genau wie gewohnt.
3. Routinemäßige Erneuerungsbrände: Das Zertifikat wurde erfolgreich erneuert, weist aber nur die Serverauthentifizierung auf. Es ist ein gültiges Zertifikat. Ihm fehlt lediglich die eine für diese Anwendung relevante Berechtigung.
4. Der nächste mTLS-Handshake schlägt fehl: Die EKU-Prüfung lehnt das Zertifikat bei der nächsten Verwendung zur Client-Authentifizierung ab, was Stunden oder Tage nach der Erneuerung auf einer Infrastruktur geschehen kann, die scheinbar in keinerlei Verbindung zu demjenigen steht, der das Zertifikat erneuert hat.

Da die Zertifikatsrotation durchgängig automatisiert ist, kann ein einziger Erneuerungszyklus bei einer Zertifizierungsstelle ein gesamtes Service-Mesh lahmlegen. Die Diagnose gestaltet sich äußerst schwierig, da das Zertifikat alle Prüfungen besteht – außer der entscheidenden. Die Kettenvalidierung ist erfolgreich. Das Ablaufdatum ist in Ordnung. Die Signatur ist gültig. Es handelt sich ausschließlich um ein Server-Auth-Zertifikat, und niemand hat dieses spezielle Feld überprüft.

So finden Sie Ihre ClientAuth-Offset-Informationen

Was man nicht gefunden hat, kann man nicht migrieren. Sechs Wege zum Aufbau eines echten Inventars, grob nach Aufwand geordnet:

1. Inventar nach EKU: Listen Sie alle öffentlich ausgestellten TLS-Zertifikate auf, die Sie besitzen, und kennzeichnen Sie alle Zertifikate, die clientAuth enthalten. Ein kryptografischer Stücklisten-Workflow (CBOM) ermöglicht die Skalierung dieses Vorgangs auf große IT-Umgebungen.
2. Suche in den Protokollen der Zertifikatstransparenz: Die Chrome-Richtlinien verlangen die Protokollierung von CT-Zertifikaten für alle öffentlich vertrauenswürdigen TLS-Zertifikate. Ein Aggregator wie crt.sh liefert daher die vollständige Ausstellungshistorie für Ihre Domains, einschließlich vergessener oder inoffizieller Zertifikate, an deren Anforderung sich niemand mehr erinnert.
3. Prüfen Sie die gesamte Kette, nicht nur das einzelne Blatt: Prüfen Sie, was die Zwischenstellen Ihrer ausstellenden Zertifizierungsstelle tatsächlich bestätigen. Die Berechtigung kann auf der Zwischenstelle erlöschen, bevor die Endstelle ihre eigene Berechtigung erneuert.
4. Erstellen Sie den Abhängigkeitsgraphen: Ermitteln Sie, welche gegenseitigen Authentifizierungsabläufe in Ihrer Umgebung tatsächlich clientAuth verbrauchen, und nicht nur, welche Zertifikate die EKU enthalten.
5. Unterstützung für Dual-Zertifikate pro Anwendung bestätigen: Kann jede Anwendung separate Client- und Serverzertifikate besitzen, oder wird davon ausgegangen, dass ein Zertifikat beides abdeckt? Falls dies nicht möglich ist, sollte das Gespräch mit dem Anbieter jetzt geführt werden, nicht erst im März 2027.
6. Automatisieren Sie die Suche mit einer CLM-Plattform: Manuelle Prüfungen sind bei wenigen Zertifikaten nicht praktikabel. Eine Plattform für das Zertifikatslebenszyklusmanagement inventarisiert EKUs kontinuierlich, nicht nur dann, wenn jemand an eine Überprüfung denkt.

Drei Befehle decken die meisten Schnellprüfungen ab und sind alle unter Windows, Linux und macOS portabel:

# Die EKU-Erweiterung aus einer Zertifikatsdatei auf der Festplatte lesen openssl x509 -in cert.pem -noout -ext extendedKeyUsage   # Überprüfen Sie die EKU eines Zertifikats, das von einem aktiven TLS-Endpunkt präsentiert wird. echo | openssl s_client -connect :443 -Servername 2>/dev/null \ | openssl x509 -noout -ext extendedKeyUsage   # Listet die EKUs für jedes Zertifikat in einem Java/PKCS12-Keystore auf keytool -list -v -keystore -storetype PKCS12

In der Ausgabe suchen Sie nach der Zeichenkette „TLS Web Client Authentication“ oder der Roh-OID 1.3.6.1.5.5.7.3.2. Wenn diese vorhanden ist und das Zertifikat von einer öffentlichen Zertifizierungsstelle stammt, behandeln Sie es als offengelegt.

Warum die gängigen Umgehungslösungen in einer Sackgasse enden

Drei verlockende Abkürzungen und wo jede von ihnen endet.

Opt-in-Optionen: DigiCert und Sectigo bieten vorerst noch Optionen zur Aktivierung der Client-Authentifizierung an. Diese Optionen verschwinden jedoch mit dem jeweiligen Stichtag der Zertifizierungsstelle, auch bei der Verlängerung bereits vorhandener Zertifikate. Dies ist keine dauerhafte Lösung, sondern ein Countdown mit festem Enddatum.

Frühe Neuausstellung: Durch die heutige Neuausstellung bleibt die Client-Authentifizierung für eine weitere Zertifikatslaufzeit aktiv. Allerdings verkürzt sich die Gültigkeitsdauer öffentlicher Zertifikate bis März 2029 gemäß CA/Browser Forum Ballot SC-081v3 auf etwa 47 Tage, sodass Ihre nächste Verlängerung nach diesem Stichtag erfolgt. Mit jeder Anwendung dieses Tricks rückt die Grenze näher; sie bleibt immer bestehen.

Nicht-Browser-Roots: Hierarchien wie X9 PKI unterstützen zwar weiterhin Dual-EKU-Zertifikate, Chrome und Firefox vertrauen diesen jedoch nicht automatisch. Sie müssten dieses Vertrauen manuell auf jedes vertrauende Gerät verteilen, wodurch ein Zertifikatsproblem gegen ein Problem der vollständigen Vertrauensverteilung getauscht wird. Das ist selten die bessere Lösung.

Das Muster ist allen drei Modellen gemeinsam: Die Identität des Clients war nie der eigentliche Zweck des öffentlichen Web-Vertrauens. Sie basierte auf einem Zertifikat, das für einen anderen Zweck erstellt wurde. Die dauerhafte Lösung ist ein Vertrauensmodell, das Sie selbst verwalten.

Expertenmeinung: Schaffen Sie trotzdem die gewünschte Trennung.

Hier kommt der entscheidende Punkt: Diese Migration ist ein guter Anlass, die Architektur aufzubauen, die Sie wahrscheinlich schon längst hätten haben sollen. Eine private PKI, speziell für Client- und Maschinenidentität entwickelt, bietet Ihnen EKU- und Profilkontrolle, die öffentliche Zertifizierungsstellen nie bieten konnten: standardmäßig dedizierte Server- und Client-Auth-Profile, ein Dual-EKU-Profil nur als bewusste, temporäre Übergangslösung und nicht als dauerhafte Lösung, und Zertifikatsgültigkeitsdauern von Stunden bis Tagen nach der automatisierten Ausstellung – ein Sicherheitsgewinn, keine Belastung.

Es entkoppelt Sie außerdem von öffentlichen Änderungen, die Sie nicht kontrollieren können. Der 47-tägige Laufzeitplan und die nächste Änderung der Programmrichtlinien stellen keine Notlage mehr dar, da die abhängigen Parteien in Ihrer Hand liegen, die Vertrauensanker in Ihren eigenen Speichern verwaltet werden und Sie die Regeln selbst festlegen. Und da Sie die Hierarchie kontrollieren, können Sie hybride und ML-DSA-Post-Quantum-Profile bereits jetzt, vor der Einführung des PQC im öffentlichen Ökosystem, testen, anstatt sie als separates Zukunftsprojekt zu betrachten.

Das bedeutet keineswegs, dass wir wieder bedenkenlos Zertifikate mit doppeltem Verwendungszweck ausstellen werden. Das gleiche Prinzip der minimalen Berechtigungen, das die Trennung von Server- und Clientauthentifizierung in öffentlichen TLS-Systemen gerechtfertigt hat, gilt auch innerhalb Ihrer eigenen Hierarchie.

Was eine produktionsreife private PKI tatsächlich erfordert

„Eine private Zertifizierungsstelle aufbauen“ ist leichter gesagt als getan. Fehlerhafte Umsetzung kann schnell zu einem Ausfall führen. Sechs Anforderungen unterscheiden eine produktionsreife private PKI von einer Zertifizierungsstelle, die selbst zum Problem wird:

Anforderung	Was es tatsächlich bedeutet
HSM-geschütztes Schlüsselmaterial	Root- und ausstellende CA-Schlüssel werden in FIPS 140-3-validierten HSMs generiert und gespeichert, der Root-Schlüssel wird offline gehalten, mit dokumentierten Schlüsselzeremonien.
Ausgabeschicht für hohen Durchsatz ausgelegt	Ausgelegt auf ein hohes Zertifikatsvolumen mit hoher Verfügbarkeit; Unterstützung für ACME, SCEP und EST, damit die automatisierte Ausstellung mit kurzen Gültigkeitsdauern Schritt hält.
Widerrufsinfrastruktur	CRL-Verteilungspunkte und OCSP-Responder; Stapling hilft bei der Validierung von Serverzertifikaten, aber Clientzertifikatsprüfungen in mTLS sind typischerweise vom Verifizierer initiierte CRL- oder OCSP-Lookups.
Angeheftete Zertifikatsprofile	Jedes Profil legt explizite EKUs, Algorithmen und Gültigkeitszeiträume fest, wobei Client- und Serverrollen durch Profil oder Sub-CA getrennt sind.
CP/CPS und Auditbereitschaft	Eine Zertifizierungsrichtlinie, eine Anleitung zur Zertifizierungspraxis, wichtige Zeremonienprotokolle und eine Vorlage für die Unternehmensführung, die einer externen Prüfung standhalten.
Lebenszyklustransparenz und Automatisierung	Kontinuierliche Erkennung sowie automatische Verlängerung und Rotation; die manuelle Nachverfolgung kann mit der in Stunden oder Tagen gemessenen Zertifikatsmenge nicht mithalten.

Die Erfüllung aller sechs Anforderungen erfordert einen erheblichen technischen Aufwand, kontinuierliches operatives Engagement und spezialisiertes kryptografisches Fachwissen, das die meisten internen Teams nicht allein abdecken können. Aus diesem Grund entscheiden sich viele Organisationen für eine Managed PKI (PKIaaS), anstatt eine solche Infrastruktur von Grund auf neu aufzubauen.

Der Migrationsplan ohne Ausfallzeiten

Vier Phasen, die so konzipiert sind, dass beim Übergang der Vertrauensstellung nichts beeinträchtigt wird. Die grundlegende Regel für alle vier Phasen: Bewahren Sie Ihre alten und neuen Zertifikatsketten während des Übergangszeitraums parallel auf, widerrufen Sie keine Zertifikate, bis jeder Kunde der neuen Kette vertraut, und schließen Sie die Migration vor dem Stichtag Ihrer Zertifizierungsstelle ab, nicht erst am Stichtag selbst.

Phase	Optik	Konkrete Schritte
01. Entdecken	Exposition finden	Blattzertifikate nach EKU inventarisieren, Blatt- und Zwischenketten abbilden, jeden mTLS-Fluss identifizieren, Erneuerungszeitpunkte erfassen
02. Formular Design	Profile definieren	Explizite EKUs festlegen, Client- und Serverprofile trennen, Algorithmen und Schlüssellängen definieren, die CRL/OCSP-Strategie entwerfen
03. Bereitstellen	Vertrauen aufbauen	Implementieren Sie die Root- und Issuer-Tier-Infrastruktur (oder erweitern Sie diese gegebenenfalls über PKIaaS), automatisieren Sie die ACME-, SCEP- und EST-Registrierung und verteilen Sie Vertrauensanker.
04. Umstellung	Sicher umschalten	Alte und neue Zertifikatsketten parallel betreiben, vollständige Pfade in der Staging-Umgebung validieren, Zertifikate schrittweise rotieren, bestehende Vertrauensstellungen nach Bestätigung der Übernahme außer Kraft setzen.

Zwei Fehlerquellen, die explizit berücksichtigt werden müssen: die Migration zum Stichtag anstatt davor und die Löschung der alten Blockchain, bevor alle Nutzer die neue tatsächlich übernommen haben. Beide führen dazu, dass eine geplante Migration zu einem Ausfall führt.

Wie PKIaaS von Encryption Consulting zu dieser Migration passt

In der oben beschriebenen Bereitstellungsphase stehen die meisten Teams vor der Herausforderung, entweder schnell voranzukommen oder monatelang mit der Hardwarebeschaffung, der Personalplanung für den 24/7-Betrieb und der Erstellung der CP/CPS-Dokumentation von Grund auf zu kämpfen. PKI-as-a-Service von Encryption Consulting wurde entwickelt, um diesen Engpass zu beseitigen: eine vollständig verwaltete, hochverfügbare Single-Tenant-PKI mit CA-Schlüsseln, die in FIPS 140-3 Level 3 HSMs gesichert sind, und CertSecure Manager , der CA-unabhängigen Zertifikatslebenszyklus-Management-Plattform von EC, die für umfassende Transparenz und Automatisierung sorgt.

Grundlage: Ihre Stammzertifizierungsstelle, untergeordnete Zertifizierungsstellen und OCSP/CRL-Dienste werden vollständig gehostet, sodass keine lokale Zertifizierungsstellenwartung erforderlich ist. HSM-as-a-Service bedeutet, dass EC die FIPS 140-3 Level 3-Hardware bereitstellt und wartet; die Schlüssel der Zertifizierungsstellen verbleiben im HSM und können niemals in Software exportiert werden, während die Kontrolle und das Eigentum an den Schlüsseln bei Ihnen bleiben.

Funktionsweise: CertSecure Manager bietet vollständige Transparenz über alle Zertifikate und automatisiert deren Erkennung, Registrierung, Verlängerung und Widerruf – sowohl für öffentliche als auch private und PKIaaS-Zertifikate – über ACME, SCEP und EST. Da der Dienst vollständig verwaltet wird, überwacht EC rund um die Uhr den Zustand der Zertifizierungsstelle, die CRL-Verlängerung, den HSM-Status und den Zertifikatsablauf und erkennt Probleme, bevor es zu den zuvor beschriebenen unbemerkten Ausfällen kommt.

Governance: EC stellt CP/CPS-Dokumentation und -Vorlagen für die Governance, rollenbasierte Zugriffskontrolle sowie bezeugte und dokumentierte Schlüsselzeremonien bereit – genau die Governance, die ein Prüfer im Rahmen eines Audits verlangt. Zertifikatsprofile sind speziell für diese Migration entwickelt und bieten dank integrierter Krypto-Agilität die Möglichkeit, hybride und PQC-fähige Zertifikatsprofile im Zuge der Weiterentwicklung von Standards bereitzustellen, anstatt später ein weiteres Migrationsprojekt durchführen zu müssen.

Im Vergleich zum vierphasigen Ablaufplan: Entdecken und Entwerfen sind typischerweise eine gemeinsame Aufgabe mit Ihrem Team; In der Bereitstellungsphase übernimmt PKIaaS die Hauptarbeit und errichtet innerhalb von Wochen eine geregelte Hierarchie anstatt der Monate, die ein komplett neuer Aufbau normalerweise in Anspruch nimmt; und die Umstellung wird durch die Automatisierung von CertSecure Manager unterstützt, sodass die parallele Einführung nicht zu einer manuellen, fehleranfälligen Einführung wird.

Häufig gestellte Fragen

Was ist die clientAuth EKU und warum wird sie aus öffentlichen TLS-Zertifikaten entfernt?

Die erweiterte Schlüsselverwendung für Client-Authentifizierung (OID 1.3.6.1.5.5.7.3.2) ermöglicht es einem TLS-Zertifikat, sich zusätzlich zur Serverauthentifizierung gegenüber Browsern auch als Client zu authentifizieren. Die Chrome-Root-Programmrichtlinie v1.8 entfernt diese Funktion aus öffentlichen Endbenutzerzertifikaten, da bei der öffentlichen Ausstellung ausschließlich die Identität von Domänen oder Organisationen validiert wird, niemals jedoch die Client-Autorisierung. Zudem verdoppelt ein Zertifikat mit doppelter Zweckbestimmung die Möglichkeiten eines gestohlenen Schlüssels.

Ist meine tatsächliche Deadline der 15. März 2027, das Datum von Chrome, oder ein anderes Datum?

Mit ziemlicher Sicherheit etwas früher. Öffentliche Zertifizierungsstellen wie DigiCert, Sectigo, Let's Encrypt, Google Trust Services und SSL.com haben alle ihre eigenen Stichtage vor dem Stichtag der Chrome-Richtlinien festgelegt, einige bereits im Jahr 2025. Prüfen Sie die Hinweise Ihrer jeweiligen Zertifizierungsstelle, anstatt Ihre Planung allein auf dem branchenweiten Datum zu basieren.

Kann ich die Clientauthentifizierung aufrechterhalten, indem ich mein aktuelles Zertifikat neu ausstelle oder fixiere?

Nein. Verifizierer berechnen die effektive EKU als Schnittmenge aller Zertifikate in der Kette. Sobald die Hierarchie Ihrer ausstellenden Zertifizierungsstelle auf reine Serverauthentifizierung umgestellt ist, kann ein Zwischenzertifikat die Clientauthentifizierung für alle darunterliegenden Zertifikate ausschließen, und die Neuausstellung oder das Festlegen des Endzertifikats ändert daran nichts.

Was geht zuerst kaputt, wenn clientAuth aus meinen Zertifikaten verschwindet?

Alles, was auf gegenseitigem TLS für die Maschinen- oder Clientidentität basiert: Service-Mesh-Sidecars, Partner-API-Gateways, IoT-Geräteflotten, VPN-Clients und alle Load Balancer oder Middleware, die explizit zur Durchsetzung der ClientAuth-EKU konfiguriert sind. Der Fehler tritt nicht am Stichtag der Durchsetzung auf, sondern bei der nächsten Zertifikatserneuerung und dem darauffolgenden mTLS-Handshake.

Hilft die Migration zu einer privaten PKI auch bei der Vorbereitung auf die Zeit nach der Quantenphysik?

Ja, indirekt, aber dennoch nützlich. Da Sie die Hierarchie kontrollieren, können Sie hybride und ML-DSA-Zertifikatsprofile innerhalb Ihrer eigenen privaten PKI testen, lange bevor das öffentliche Zertifikatsökosystem nach der Quantenintegration eingeführt wird. Dadurch wird diese Migration zu einem Vorsprung und nicht zu einem späteren, separaten Projekt.

Bereit zu sehen, wo Sie stehen?

Führen Sie diese Woche die obige Checkliste zur Zertifikatsanalyse anhand Ihrer eigenen Zertifikatslandschaft durch. Wenn Sie bereit sind, die private PKI-Komponente zu entwerfen und bereitzustellen, erfahren Sie, wie PKI-as-a-Service diese Migration unterstützt , oder wenden Sie sich an das PKI-Team von Encryption Consulting, um eine Analyse und Migrationsbewertung durchführen zu lassen.