Google verschärft das Chrome Root Program und setzt ab dem 15. Juni 2026 neue Regeln für öffentlich vertrauenswürdige TLS-Zertifikate durch. Die Änderungen betreffen vor allem Certificate Authorities, PKI-Betreiber, Hoster und Unternehmen mit eigener Zertifikatsverwaltung. Webseitenbetreiber sollten ihre Zertifikatsketten trotzdem prüfen, da Chrome Zertifikate aus betroffenen Hierarchien später als nicht vertrauenswürdig einstufen kann.
Für Google Chrome ist das ein Sicherheits- und Infrastrukturthema zugleich. Nutzer sehen am Ende nur eine Warnung vor einer unsicheren Verbindung. Die Ursache liegt aber oft tiefer: Root-Zertifikat, Intermediate-Zertifikat, Extended Key Usage, Certificate Transparency oder ein veralteter Zertifikatspfad.
Chrome setzt ab Juni neue Phase-out-Regeln für PKI-Hierarchien durch
Die Chrome Root Program Policy Version 1.8 erklärt, wie Google künftig mit PKI-Hierarchien umgeht, die Anforderungen verletzen. Ab dem 15. Juni 2026 kann das Chrome Root Program solche Hierarchien ausphasen. Der Phase-out-Termin liegt dann in der Regel 90 Kalendertage nach Erkennung des Verstoßes.
Das hat eine praktische Folge. TLS-Zertifikate, die vor dem Phase-out-Termin ausgestellt wurden, bleiben in Chrome bis zum Ablauf vertrauenswürdig. Zertifikate aus derselben betroffenen Hierarchie, die nach dem Phase-out-Termin ausgestellt werden, werden in Chrome standardmäßig nicht mehr vertraut. Für Webseiten kann das wie ein plötzlicher HTTPS-Ausfall wirken.
Google will außerdem die Angriffsfläche im Chrome Root Store verkleinern. Root-Zertifikate sollen moderner, klarer getrennt und besser verwaltet werden. Multi-Purpose-PKI-Hierarchien geraten dadurch unter Druck. Der Chrome Root Store soll für TLS-Server-Authentifizierung genutzt werden und nicht als allgemeiner Vertrauensanker für mehrere PKI-Zwecke.
| Regelbereich | Stichtag | Auswirkung |
|---|---|---|
| Phase-out fehlerhafter PKI-Hierarchien | Ab 15. Juni 2026 | Phase-out in der Regel 90 Tage nach Verstoß |
| Neue Subordinate CAs | Ab 15. Juni 2026 | Neue CA-Zertifikate müssen nur serverAuth ausweisen |
| Bestehende Subordinate CAs | Übergangslogik laut Chrome Policy | Bestehende Ketten dürfen begrenzt Übergangsprofile behalten |
| Neue Leaf-Zertifikate | Ab 15. März 2027 | Neue Endnutzerzertifikate dürfen nur serverAuth enthalten |
| Certificate Transparency | Ab 15. Juni 2026 | Precertificates müssen vor Ausstellung in anerkannten CT-Logs stehen |
| Root-Konsolidierung | Pläne vor 15. Juni 2026, Limit ab 15. September 2027 | Maximal zwei selbstsignierte Root-CAs pro CA Owner |
| Automatisierung | Ab 15. März 2027 | CA-Hierarchien brauchen nachweisbare Ausgabe- und Erneuerungsautomatisierung |
Ein zentraler Punkt ist Extended Key Usage. Öffentliche TLS-Zertifikate sollen künftig klar auf serverAuth ausgerichtet sein. Zertifikate, die gleichzeitig für Server- und Client-Authentifizierung genutzt werden, passen nicht mehr zur neuen Chrome-Linie. Für Unternehmen mit mTLS, Geräteauthentifizierung, VPN-Zugängen oder alten Client-Zertifikatsprozessen kann das relevant werden.
Die Änderung bedeutet nicht, dass jede Webseite am 15. Juni sofort ausfällt. Viele öffentliche TLS-Zertifikate werden bereits heute korrekt ausgestellt und in Certificate-Transparency-Logs veröffentlicht. Das Risiko liegt bei Sonderfällen, alten Zertifikatsketten, manueller PKI-Verwaltung, falsch genutzten ClientAuth-Profilen und Anbietern, die ihre Root- oder Intermediate-Struktur noch migrieren.
Webseitenbetreiber sollten Zertifikatsketten und CA-Wechsel prüfen
Für Admins zählt jetzt nicht nur das Ablaufdatum des Zertifikats. Wichtig ist die komplette Kette vom Endzertifikat über das Intermediate bis zum Root. Wenn eine CA ihre Hierarchie umstellt, kann ein Reissue oder eine Verlängerung plötzlich über einen neuen Pfad laufen. Hoster, CDNs und Managed-SSL-Anbieter sollten diese Umstellung sauber kommunizieren.
Certificate Transparency wird ebenfalls wichtiger. Chrome verlangt, dass TLS-Precertificates vor Ausstellung des finalen Zertifikats in einem anerkannten CT-Log stehen. DigiCert entfernt deshalb Opt-out-Optionen für öffentliche TLS-Zertifikate und verweist auf Private TLS für Namen, die nicht in öffentlichen CT-Logs erscheinen sollen. Webseitenbetreiber sollten keine öffentlichen Zertifikate mehr für interne oder geheime Hostnamen planen.
Ein konkretes Beispiel liefert GlobalSign. Der Anbieter nennt für mehrere Multi-Purpose-Roots einen Chrome-SCTNotAfter-Termin am 13. September 2026. Zertifikate, die vor diesem Datum ausgestellt wurden, bleiben laut GlobalSign bis zum Ablauf vertrauenswürdig. Zertifikate nach diesem Datum werden von Google Chrome nicht mehr vertraut. Solche Anbieterhinweise sollten Admins ernst nehmen, auch wenn die eigene Webseite aktuell keine Warnung zeigt.
| Admin-Prüfung | Warum prüfen? | Mögliche Aktion |
|---|---|---|
| Zertifikatskette | Chrome bewertet die gesamte Vertrauenskette | Mit SSL-Test, Browser-Details und CA-Portal prüfen |
| Issuing CA | CA-Wechsel kann andere Intermediate-Zertifikate bringen | CA-Hinweise und Migrationspläne lesen |
| Root-CA | Multi-Purpose-Roots werden ausphasen | Zertifikate auf TLS-dedizierte Hierarchie umstellen |
| Extended Key Usage | clientAuth passt künftig nicht mehr zu öffentlichen TLS-Zertifikaten | Nur serverAuth für öffentliche Webseiten nutzen |
| Certificate Transparency | Öffentliche TLS-Zertifikate landen in CT-Logs | CT-Eintrag und SCTs prüfen |
| Interne Hostnamen | CT-Logs veröffentlichen Namen sichtbar | Private PKI oder interne Namen verwenden |
| mTLS und Client-Zertifikate | Öffentliche TLS-Zertifikate sind dafür langfristig ungeeignet | Private CA oder spezialisiertes Unternehmens-PKI nutzen |
| CDN und Hoster | Managed SSL kann ohne eigenes Zutun wechseln | Support-Tickets und Statusseiten verfolgen |
| Monitoring | Warnungen kommen oft erst bei Ausgabe oder Renewal | Ablauf, Issuer und CT überwachen |
| Verlängerungsprozess | Manuelle Erneuerung erhöht Ausfallrisiko | ACME oder CLM automatisieren |
Für deutsche Unternehmen ist der DACH-Bezug klar. Viele Firmen nutzen öffentliche TLS-Zertifikate nicht nur für Webseiten, sondern auch für Portale, APIs, Extranets, VPN-Einstiege, Kundensysteme und Gerätekommunikation. Chrome-Regeln treffen solche Systeme besonders dann, wenn Mitarbeiter, Kunden oder Partner sie im Browser öffnen.
Die sichtbare Fehlermeldung kann dabei irreführend wirken. Chrome meldet eine nicht private oder unsichere Verbindung. Der eigentliche Grund kann ein Zertifikat aus einer auslaufenden Hierarchie sein. Auch ein falsch ausgestelltes Zertifikat ohne passende Transparenzdaten kann Probleme auslösen. Admins sollten deshalb nicht nur das Enddatum prüfen, sondern Issuer, EKU, CT-Status und Zertifikatspfad.
Die Umstellung passt in einen größeren Trend. Browserhersteller verkürzen Zertifikatslebenszeiten, stärken Certificate Transparency und verlangen mehr Automatisierung. Webseitenbetreiber profitieren langfristig von sauberer Zertifikatsverwaltung, bekommen kurzfristig aber mehr Prüfaufwand. Wer Zertifikate noch manuell beantragt, installiert und erneuert, sollte spätestens jetzt ein Zertifikatsinventar und automatische Erneuerung einführen.
Chrome verschärft die Regeln nicht für einzelne Webseiten, sondern für das Vertrauen in die öffentliche PKI. Webseitenbetreiber spüren die Folgen trotzdem direkt, wenn ein Anbieter die Hierarchie wechselt oder ein Renewal über einen nicht mehr akzeptierten Pfad läuft. Die sicherste Vorbereitung ist ein aktueller Zertifikatsbestand mit dokumentierter CA-Kette, serverAuth-only-Profil, CT-Prüfung und automatisierter Erneuerung.