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 das Root-Programmrichtlinien-Update von Google Chrome. Ab 2026 wird Chrome in mehreren Schritten die Vorgehensweise von Google Chrome anpassen. SSL/TLS-Zertifikate Öffentliche Zertifikatshierarchien müssen nun ausschließlich der TLS-Serverauthentifizierung dienen, was bedeutet, dass die Unterstützung für die TLS-Clientauthentifizierung in der Welt der öffentlichen Zertifikate wegfällt. Wenn Ihre Organisation auf öffentliche Zertifikate angewiesen ist, Zertifizierungsstellen Bei Zertifizierungsstellen (CAs) zur Authentifizierung von Benutzern, Geräten oder Anwendungen erfordert diese Änderung sofortige Aufmerksamkeit.

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 Kurs des Programms hin zu dedizierter TLS-Serverauthentifizierung fortsetzt. PKI Hierarchien. Gemäß dieser Richtlinie dürfen Zertifikatshierarchien, die im Chrome-Truststore enthalten sind, nur noch der TLS-Serverauthentifizierung dienen, und Mehrzweck-Root-Zertifikate werden schrittweise abgeschafft.

In der Praxis bedeutet dies, dass sich öffentliche Wirtschaftsprüfer von Folgendem zurückziehen Zertifikate Diese Zertifikate enthalten sowohl die erweiterten Schlüsselverwendungen (EKUs) id-kp-serverAuth als auch id-kp-clientAuth. Diese EKUs definieren, wofür ein Zertifikat verwendet werden kann: entweder für die Server- oder die Clientauthentifizierung, aber nicht für beides. Die Umstellung erfolgt an zwei wichtigen Terminen, die Sie sich vormerken sollten.

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 Zertifikate Zertifizierungsstellen, darunter DigiCert, Sectigo und Let's Encrypt, haben schon lange vor diesen Fristen damit begonnen, die clientAuth EKU standardmäßig zu entfernen.

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 der Serverauthentifizierung assoziieren. HTTPS.

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 Diensten. PKI Hierarchien. Mehrzweckzertifikate, die sowohl für die Server- als auch für die Clientauthentifizierung verwendet werden, führen zu Komplexität und potenziellen Sicherheitsrisiken. 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?

Verschlüsselungsberatung CertSecure Manager 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.

Sollten Sie darüber hinaus eine Stelle benötigen, an der Client-Authentifizierungszertifikate ausgestellt werden können, sobald diese den öffentlichen Vertrauensspeicher verlassen haben, bietet Encryption Consulting die passende Lösung. PKI-as-a-Service Sie erhalten eine vollständig verwaltete private Zertifizierungsstelle. Diese übernimmt Ihre PKI-Implementierung von Anfang bis Ende, 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 Browservertrauen immer strenger werden, PKI Da sich die 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.