Die Root-Programmrichtlinie von Chrome v1.8 verstehen: Was ändert sich am 15. Juni 2026?

Im sich ständig wandelnden Umfeld der Internetsicherheit haben nur wenige Änderungen das Potenzial, grundlegende Praktiken so grundlegend zu verändern wie die Aktualisierung der Root-Programmrichtlinie von Google Chrome. Ab 2026 ändert Chrome schrittweise die Verwendung von SSL/TLS-Zertifikaten . Öffentliche Zertifikatshierarchien müssen künftig ausschließlich der TLS-Serverauthentifizierung dienen, wodurch die Unterstützung für die TLS-Clientauthentifizierung im Bereich öffentlicher Zertifikate entfällt. Wenn Ihre Organisation öffentliche Zertifizierungsstellen (CAs) zur Authentifizierung von Benutzern, Geräten oder Anwendungen nutzt, ist diese Änderung dringend zu beachten.

Lasst uns genauer betrachten, was das bedeutet, warum es passiert und wie ihr euch vorbereiten könnt.

Kern der Änderung: Chrome-Root-Programmrichtlinie v1.8

Kernstück dieses Übergangs ist die Chrome-Root-Programmrichtlinie v1.8 (zuletzt aktualisiert am 5. Februar 2026), die den Fokus des Programms auf dedizierte PKI- Hierarchien für die TLS-Serverauthentifizierung weiter verstärkt. Gemäß dieser Richtlinie dürfen Zertifikatshierarchien im Chrome-Truststore ausschließlich der TLS-Serverauthentifizierung dienen, und Mehrzweck-Root-Zertifikate werden schrittweise abgeschafft.

Das bedeutet in der Praxis, dass öffentliche Zertifizierungsstellen keine Zertifikate mehr ausstellen , die sowohl die erweiterten Schlüsselverwendungen (EKUs) „id-kp-serverAuth“ als auch „id-kp-clientAuth“ enthalten. Diese EKUs definieren, wofür ein Zertifikat verwendet werden darf: entweder für die Server- oder die Clientauthentifizierung, aber nicht für beides. Die Umstellung erfolgt an zwei wichtigen Terminen.

Ab dem 15. Juni 2026 muss jedes neue Zwischenzertifikat (untergeordnetes Zertifikat), das der CCADB unter einer Stammzertifizierungsstelle im Chrome Root Store gemeldet wird, ausschließlich die ServerAuth-EKU enthalten. Ab dem 15. März 2027 gilt dieselbe Regel auch für die tatsächlich eingesetzten Zertifikate: Jedes neu ausgestellte Endzertifikat, das auf eine von Chrome als vertrauenswürdig eingestufte Stammzertifizierungsstelle verweist, muss ebenfalls ausschließlich ServerAuth enthalten. Danach wird ClientAuth in öffentlichen Zertifikaten nicht mehr unterstützt.

Vor dem jeweiligen Stichtag ausgestellte Zertifikate bleiben bis zu ihrem Ablaufdatum gültig (sofern sie nicht widerrufen werden). Neue und erneuerte öffentliche Zertifikate enthalten jedoch keine Client-Authentifizierung mehr. Die meisten großen Zertifizierungsstellen , darunter DigiCert, Sectigo und Let's Encrypt, haben die Client-Authentifizierungs-EKU bereits lange vor diesen Fristen standardmäßig entfernt.

Warum dies wichtig ist

Die TLS-Clientauthentifizierung ist ein wichtiger Mechanismus zur Überprüfung der Identität von Clients – seien es Benutzer, Geräte oder Anwendungen – beim Verbinden mit einem Server. Sie unterscheidet sich von der Serverauthentifizierung, die die meisten Menschen mit HTTPS assoziieren.

Die Client-Authentifizierung wird häufig verwendet in:

• VPN-Zugang: Überprüfung der Fernverbindung von Mitarbeitergeräten.
• Wi-Fi-Onboarding: Geräteauthentifizierung ohne statische Passwörter.
• Gegenseitiges TLS (mTLS): Sicherung der API-Kommunikation in Microservices.
• Einmaliges Anmelden (SSO): Einbetten von Zertifikaten in Endgeräte.
• DevOps-Umgebungen: Workloads und Container identifizieren.

Viele Organisationen haben für diese Zwecke öffentliche Zertifizierungsstellen genutzt, oft unwissentlich, weil es bequem und kostengünstig ist. Mit der neuen Richtlinie von Chrome ist dieser Ansatz jedoch nicht mehr praktikabel.

Warum passiert dies?

Dieser Schritt ist Teil eines branchenweiten Trends hin zu dedizierten PKI- Hierarchien. Mehrzweckzertifikate, die sowohl für die Server- als auch für die Clientauthentifizierung verwendet werden, bringen Komplexität und potenzielle Sicherheitsrisiken mit sich. Durch die Trennung dieser Anwendungsfälle verfolgen Browser wie Chrome folgende Ziele:

• Zertifikatsmanagement verbessern.
• Das Vertrauen in die öffentliche PKI stärken.
• Das Risiko von Missbrauch oder Fehlkonfiguration verringern.

Öffentliche Zertifizierungsstellen wurden nie für interne Authentifizierungsprozesse konzipiert. Sie unterliegen externen Prüfungen, Compliance-Vorgaben und Browserrichtlinien. Daher eignen sie sich nicht für die Flexibilität und Kontrolle, die in Client-Authentifizierungsszenarien erforderlich sind.

Die Lösung: Umstellung auf private Zertifizierungsstellen

Wenn Ihre Organisation öffentliche Zertifikate zur Clientauthentifizierung verwendet, ist der weitere Weg klar: Migration zu einer privaten Zertifizierungsstelle (CA).

Zu den Vorteilen privater Wirtschaftsprüfer gehören:

• Anpassbare Zertifikatsprofile.
• Volle Kontrolle über Ausstellung und Widerruf.
• Keine Abhängigkeit von Browser-Truststores.
• Unterstützung für Protokolle wie ACME, EST und SCEP.

Dieser Wandel versetzt Organisationen in die Lage, Authentifizierungsabläufe zu entwickeln, die auf ihre Bedürfnisse zugeschnitten sind, ohne durch die Beschränkungen öffentlicher Zertifizierungsstellen eingeschränkt zu werden.

Was Sie als nächstes tun sollten

Hier ist ein praktischer Fahrplan, um sich auf die Chrome-Termine 2026 und 2027 vorzubereiten:

1. Überprüfen Sie Ihre Zertifikatsnutzung: Ermitteln Sie, wo die TLS-Clientauthentifizierung eingesetzt wird. Nutzen Sie öffentliche ACME-Workflows wie Let's Encrypt? Welche Geräte und Dienste sind betroffen?
2. Bewerten Sie Ihr Risiko: Ermitteln Sie, welche Zertifikate betroffen sein werden und wann. Planen Sie, diese zu ersetzen, bevor sie ablaufen oder nicht mehr vertrauenswürdig sind.
3. Bereitstellung einer privaten Zertifizierungsstelle: Wählen Sie eine Lösung, die zu Ihrer Umgebung passt: Cloud-basiert, On-Premise oder hybrid. Stellen Sie sicher, dass sie Automatisierung und Integration mit Ihren bestehenden Tools unterstützt.
4. Implementieren Sie CLM und migrieren Sie Ihre öffentlichen CA-Zertifikate zu einer privaten CA: Nachdem Ihre private Zertifizierungsstelle eingerichtet ist, implementieren Sie eine CLM Die Plattform dient der Verwaltung von Zertifikatslebenszyklen, der Durchsetzung von Richtlinien und der Gewährleistung der Transparenz Ihrer gesamten Umgebung. Definieren Sie vor der Migration die entsprechenden Zertifikatvorlagen und EKUs auf der privaten Zertifizierungsstelle (CA), damit die neu ausgestellten Zertifikate die korrekten Verwendungszwecke aufweisen (für die Clientauthentifizierung die clientAuth-EKU ohne serverAuth). Nutzen Sie anschließend die Funktion zum Wechseln der CA im CLM, um Ihre bestehenden Clientauthentifizierungszertifikate der öffentlichen CA gesammelt auf die private CA zu übertragen, anstatt jedes einzelne Zertifikat manuell zu suchen und neu auszustellen.
5. Schulen Sie Ihre Teams: Stellen Sie sicher, dass die IT DevOps, und die Sicherheitsteams verstehen die Auswirkungen und sind sich hinsichtlich der Migrationsstrategie einig.

Wie kann Verschlüsselungsberatung helfen?

CertSecure Manager von Encryption Consulting ist eine herstellerneutrale Lösung für das Zertifikatslebenszyklusmanagement, die Erkennung, Automatisierung, Registrierung, Richtliniendurchsetzung und Integrationen zentralisiert. Sie verhindert Ausfälle durch automatisierte Verlängerungen, verbessert die Compliance, optimiert den IT-Betrieb und vereinheitlicht die Verwaltung öffentlicher und privater Zertifizierungsstellen über eine einzige, automatisierte und skalierbare Plattform.

Speziell für die Chrome-Änderung ermöglicht die Erkennungs- und Inventarisierungsfunktion, genau zu ermitteln, welche Ihrer Zertifikate heute die clientAuth EKU enthalten, und die Ein-Klick-Migration öffentlicher CAs hilft Ihnen, diese Workloads massenhaft auf eine private CA zu übertragen, ohne dass Sie Zertifikate manuell einzeln suchen und neu ausstellen müssen.

Benötigen Sie zusätzlich eine Möglichkeit zur Ausstellung von Client-Authentifizierungszertifikaten, nachdem diese den öffentlichen Vertrauensspeicher verlassen haben, bietet Ihnen Encryption Consulting mit PKI-as-a-Service eine vollständig verwaltete private Zertifizierungsstelle. Diese übernimmt Ihre PKI-Implementierung von A bis Z – von der Zertifikatsausstellung über das automatisierte Lebenszyklusmanagement und die Durchsetzung von Richtlinien bis hin zur Einhaltung branchenüblicher Sicherheitsstandards. So können Sie eine dedizierte private Hierarchie für VPN, WLAN, mTLS und SSO einrichten, ohne die Infrastruktur selbst aufbauen und betreiben zu müssen.

Fazit

Das Root-Programm-Update von Chrome ist nicht nur eine technische Anpassung; es markiert einen grundlegenden Wandel im Umgang mit digitaler Identität und Vertrauen im Internet. Zwar kann es bestehende Authentifizierungsprozesse beeinträchtigen, bietet Unternehmen aber gleichzeitig die Chance, ihre PKI-Architektur zu modernisieren und eine sicherere, skalierbarere und robustere Grundlage zu schaffen.

Wenn Ihre Organisation noch öffentliche Zertifikate zur Client-Authentifizierung verwendet, ist jetzt der richtige Zeitpunkt zum Handeln. Die Fristen sind festgelegt, die Durchsetzung ist streng, und Chromes Umstellung auf eine dedizierte, ausschließlich serverseitige PKI macht private Zertifizierungsstellen zum einzig zukunftsfähigen Weg.

Gleichzeitig machen das steigende Zertifikatsvolumen, die sinkende Gültigkeitsdauer von Zertifikaten und die zunehmende Komplexität verteilter Umgebungen das Zertifikatslebenszyklusmanagement (CLM) unerlässlich. Eine robuste CLM-Lösung verhindert Ausfälle, automatisiert Verlängerungen, gewährleistet die Einhaltung von Vorschriften und bietet Unternehmen volle Transparenz und Kontrolle über ihre kryptografischen Assets.

In einem Ökosystem, in dem die Anforderungen an das Vertrauen in Browser immer strenger werden, sich PKI- Umgebungen diversifizieren und digitale Identitäten sich in Cloud-, DevOps-, IoT- und Zero-Trust-Architekturen vervielfachen, wird ein effektives Zertifikatslebenszyklusmanagement zur Grundlage einer sicheren, effizienten und zukunftsfähigen Authentifizierungsstrategie.