Der 15. April 2026 ist ein wichtiges Datum für Organisationen, die weiterhin Teile älterer DigiCert-Hierarchien nutzen. An diesem Tag entfernen Mozilla und Google Chrome die DigiCert G1 Roots aus ihren Trust Stores, was bedeutet, dass TLS-Zertifikate, die ausschließlich zu diesen Roots verketten, in Umgebungen, die auf diesen Trust-Programmen basieren, nicht mehr als vertrauenswürdig gelten. Aus Sicht vieler Organisationen ist dies keine spektakuläre Änderung, da die überwiegende Mehrheit der Deployments bereits früher auf die neueren G2- und G3-Hierarchien migriert wurde. Für einige Umgebungen, insbesondere solche mit Legacy-Komponenten, eigenen Trust Stores, Pinning oder nicht standardisierter Validierungslogik, kann dies jedoch ein reales Risiko für Serviceunterbrechungen, Validierungsfehler und unerwartete Vorfälle auf Seiten von Clients, Anwendungen und Geräten bedeuten.

In der Praxis geht es also nicht nur um die Änderung auf Seiten der Browser. Es geht um einen breiteren Trend zur Bereinigung der öffentlichen WebPKI, bei dem ältere Root- und Intermediate-Hierarchien schrittweise auslaufen und das Vertrauen auf neuere, besser strukturierte und an aktuelle Anforderungen angepasste Issuance-Modelle verlagert wird. DigiCert begann bereits am 8. März 2023 mit der Standard-Issuance aus der G2-Hierarchie, um die Auswirkungen der späteren G1-Abkündigung zu begrenzen. Das bedeutet, dass das Problem nicht jedes DigiCert-, GeoTrust-, RapidSSL- oder Thawte-Zertifikat betrifft, sondern nur den Teil aktiver Deployments, die weiterhin auf dem älteren Verkettungspfad verbleiben.

Was genau wird zurückgezogen?

Die wichtigste Aussage ist einfach: Ab dem 15. April 2026 vertrauen Mozilla und Google Chrome den DigiCert G1 Roots, die für öffentliches TLS verwendet werden, nicht mehr. In den DigiCert-Materialien werden insbesondere drei Haupt-Roots dieser Generation genannt: DigiCert Assured ID Root CA, DigiCert Global Root CA und DigiCert High Assurance EV Root CA. Für aktive TLS-Zertifikate bedeutet dies einen Vertrauensverlust nach diesem Datum, wenn ihr Vertrauenspfad ausschließlich bei diesen Roots endet.

Das ist eine sehr wichtige Unterscheidung. Allein die Tatsache, dass ein Zertifikat von einer Marke ausgestellt wurde, die zu DigiCert gehört, bedeutet noch nicht automatisch ein Problem. DigiCert stellt öffentliche Zertifikate schon seit längerer Zeit aus neueren G2-Hierarchien aus, und einige Produkte nutzen auch neuere G3-Pfade. Cloudflare betont bei der Beschreibung dieser Änderung aus Sicht der eigenen Kunden, dass der primäre Risikobereich kundenspezifische Zertifikate sind, die weiterhin zu Legacy G1 verketten. Zertifikate, die in G2 enden, bleiben vertrauenswürdig und sind von dieser konkreten Distrust-Maßnahme nicht betroffen.

Warum ist diese Änderung gerade jetzt wichtig?

In vielen Organisationen wird das Thema Roots und Intermediates erst dann wieder relevant, wenn etwas nicht mehr funktioniert. Das ist ein Fehler. Die Vertrauenskette ist ein Bestandteil kritischer Infrastruktur, bleibt aber gleichzeitig oft außerhalb des täglichen Monitorings. In der Praxis bedeutet das, dass eine Organisation ein korrekt installiertes End-Entity-Zertifikat mit gültigem Ablaufdatum haben kann und dennoch auf der Client-Seite Probleme bekommt, weil der Validierungspfad bei einem Root endet, der gerade aus dem Trust Store entfernt wurde.

Das Risiko ist besonders hoch dort, wo gemischte Umgebungen vorhanden sind: moderne Browser auf der einen Seite und auf der anderen ältere Anwendungen, Geräte, kryptografische Bibliotheken, Netzwerk-Appliances, B2B-Integrationen, Mail-Clients, Applikationsserver oder eigene agentenbasierte Komponenten, die nicht dasselbe Validierungsmodell verwenden. Einige dieser Systeme funktionieren jahrelang korrekt, weshalb ihre Eigentümer annehmen, dass keine Änderungen notwendig sind. Tatsächlich sind es aber gerade diese Umgebungen, in denen Hard-Coded Trust, Certificate Pinning oder Abhängigkeiten von älteren Cross-Signed Chains besonders häufig vorkommen. DigiCert weist ausdrücklich darauf hin, dass Umgebungen, die die Akzeptanz von Roots und Intermediates pinnen oder hard-code’n oder eigene Trust Stores pflegen, zusätzliche Aufmerksamkeit erfordern.

Wen kann diese Änderung am stärksten betreffen?

Am wenigsten gefährdet sind typische Web-Deployments, die in den letzten Jahren im Standardprozess erneuert wurden und nicht auf nicht standardisierten Ausnahmen beruhten. Wenn ein Zertifikat im normalen Zyklus erneuert oder neu ausgestellt wurde, nachdem DigiCert auf G2 umgestellt hatte, arbeitet ein großer Teil solcher Umgebungen heute bereits auf unterstützten Hierarchien. DigiCert gibt an, dass die meisten Kunden bereits migriert wurden und keine zusätzlichen Maßnahmen ergreifen müssen.

Deutlich vorsichtiger sollten Organisationen sein, die mindestens eine der folgenden Bedingungen erfüllen:

• sie haben aktive TLS-Zertifikate, die aus der G1-Hierarchie ausgestellt wurden,
• sie benötigen Vertrauen in Umgebungen, die auf Chrome oder Mozilla Firefox basieren,
• sie pflegen eigene Trust Stores oder eigene CA-Bundles,
• sie pinnen Roots oder Intermediates,
• sie nutzen ältere Geräte, Agenten, Bibliotheken oder Server, die auf den früheren Zertifizierungspfad ausgerichtet wurden,
• sie setzen Zertifikate außerhalb des klassischen Webs ein, zum Beispiel in Appliances, B2B-Integrationen, Geräten, vermittelnden Diensten oder Komponenten, die nicht häufig aktualisiert werden.

Ein Sonderfall sind auch Umgebungen, in denen historisch Kompatibilitäts-Workarounds verwendet wurden, etwa Cross-Signing, um Vertrauen in älteren Trust Stores zu erhalten. Solche Lösungen haben in der Übergangsphase oft korrekt funktioniert, sollten aber nicht als langfristige Zielstrategie betrachtet werden. DigiCert hat bereits 2023 darauf hingewiesen, dass der Cross-Signed Root nur Übergangscharakter hatte und dass die vollständige Aufrechterhaltung des Vertrauens nach dem Distrust-Datum eine Migration auf eine neuere Hierarchie erfordert.

Welche operativen Folgen kann es nach dem 15. April 2026 geben?

Die offensichtlichste Folge werden Warnungen über ein nicht vertrauenswürdiges Zertifikat in Browsern und Anwendungen sein, die Trust Stores verwenden, die auf den Chrome- und Mozilla-Programmen basieren. Für Endnutzer bedeutet dies eine Sicherheitswarnung, für die Organisation bedeutet es Vertrauensverlust, Unterbrechung von Login-Prozessen, blockierten Zugriff auf Panels, Formulare, APIs oder Einkaufsprozesse.

In der Praxis können die Auswirkungen jedoch weiter reichen als nur eine Browser-Warnung. Wenn das Zertifikat in maschinellen Integrationen, Reverse Proxys, Load Balancern, Shared Services, Telemetrie-Agenten oder vermittelnden Sicherheitsschichten verwendet wird, kann sich das Problem als TLS-Verbindungsfehler, Unfähigkeit zum Aufbau einer Sitzung, Ablehnung des Vertrauens durch den Client, fehlende Möglichkeit zur Wiederaufnahme der Kommunikation oder als unklare Applikationsfehler zeigen. Ein Teil dieser Probleme wird nicht sofort als Root-CA-Thema erkannt, weil in den Logs nur eine allgemeine Information über einen Zertifikatsvalidierungsfehler erscheint. Genau deshalb erfordert dieses Thema eine frühzeitige Inventarisierung und nicht erst eine Reaktion nach Eintritt eines Vorfalls.

Wie lässt sich prüfen, ob eine Organisation betroffen ist?

Der erste Schritt sollte nicht sein, sofort neue Zertifikate zu bestellen, sondern festzustellen, wo aktive G1-Ketten überhaupt noch existieren. Das ist eine Aufgabe aus dem Bereich Certificate Inventory und kein einzelner Support Case.

In der Praxis lohnt sich ein Vorgehen in vier Ebenen.

1. Inventarisierung aktiver öffentlicher Zertifikate.

Erfasst werden sollten nicht nur öffentliche Domains, sondern auch Zertifikate in Administrationsportalen, B2B-Schnittstellen, Integrationsdiensten, Edge-Geräten, WAFs, Appliances, VPNs, Mail-Gateways und überall dort, wo ein öffentliches Zertifikat außerhalb einer klassischen Website verwendet wird. Die meisten Probleme finden sich in der Regel genau an diesen weniger sichtbaren Stellen.

2. Identifikation des tatsächlichen Verkettungspfads.

Für jedes aktive Deployment muss festgestellt werden, zu welchem Intermediate und Root der Vertrauenspfad tatsächlich führt. Das End-Entity-Zertifikat allein reicht nicht aus. Die Tatsache, dass die Handelsmarke des Zertifikats RapidSSL, GeoTrust oder Thawte ist, entscheidet noch nicht darüber, ob es sich um G1 oder eine neuere Hierarchie handelt. DigiCert veröffentlicht Zuordnungen zwischen früheren G1-Intermediates und ihren Nachfolgern in G2, was solche Vergleiche erleichtert. Für RapidSSL betraf der Übergang zum Beispiel den Wechsel von RapidSSL Global TLS RSA4096 SHA256 2022 CA1 unter DigiCert Global Root CA zu RapidSSL TLS RSA CA G1 unter DigiCert Global Root G2. Ähnliche Zuordnungen existieren für GeoTrust, Thawte und DigiCert-Produkte.

3. Überprüfung der Abhängigkeiten auf Client- und Geräteseite.

Selbst wenn der Server nach einem Reissue den korrekten Chain sendet, kann das Problem auf Seiten von Clients, Agenten oder Geräten bestehen bleiben, die den alten Root erwarten, einen bestimmten Pfad pinnen oder ihr eigenes CA-Bundle verwenden. Gerade dieser Bereich entscheidet oft darüber, ob die Migration trivial verläuft oder sich in eine Serie von Vorfällen über verschiedene Teams hinweg verwandelt.

4. Prüfung historischer Ausnahmen.

Es lohnt sich zu prüfen, ob in der Vergangenheit Kompatibilitäts-Workarounds in Verbindung mit einem Cross-Signed Root, einer benutzerdefinierten Chain-Datei, manuell aufgebauten Bundles oder appliance-spezifischen Ausnahmen eingeführt wurden. Solche Entscheidungen sind oft schlecht dokumentiert, kehren aber genau bei dieser Art von Änderungen wieder zurück.

Welche Maßnahmen empfiehlt DigiCert?

Die zentrale Empfehlung von DigiCert ist eindeutig: Betroffene Zertifikate sollten vor dem Rückzugsdatum in die G2- oder G3-Hierarchie erneuert oder neu ausgestellt werden, um untrusted Warnungen nach dem 15. April 2026 zu vermeiden. Gleichzeitig betont DigiCert, dass die meisten Standard-Renewals Zertifikate bereits automatisch in unterstützte Hierarchien verschieben und dass die Ausstellung neuer Zertifikate in G1 nicht mehr der Standardpfad ist.

Es lohnt sich, noch auf einen weiteren wichtigen Aspekt hinzuweisen. Cloudflare macht darauf aufmerksam, dass bei betroffenen Zertifikaten ein Standard-Reissue nach G2 in der Regel ausreicht und in den meisten Fällen keine Generierung eines neuen privaten Schlüssels erfordert. Das ist operativ wichtig, weil einige Teams befürchten, dass eine solche Migration einer vollständigen Neuimplementierung des Deployments gleichkommt. In vielen Szenarien ist das nicht der Fall. Zunächst muss jedoch die Policy des konkreten Produkts, des Issuance-Prozesses und der eigenen Sicherheitsanforderungen in Bezug auf Key Rotation bestätigt werden.

Was sollte man nicht annehmen?

Der größte Fehler wäre anzunehmen, dass sich das Thema von selbst erledigt, weil „das Zertifikat ja noch nicht abgelaufen ist“. Das Problem ist hier nicht das Ablaufdatum des End-Entity-Zertifikats selbst, sondern das Datum des Vertrauensentzugs für den Root, zu dem dieses Zertifikat verkettet. Man kann also ein formal gültiges Zertifikat haben, das in der Praxis trotzdem nicht vertrauenswürdig ist. DigiCert weist ausdrücklich darauf hin, dass aktive TLS-Zertifikate, die zu G1 verketten, nach dem 15. April 2026 in Chrome und Mozilla ihr Vertrauen verlieren.

Der zweite Fehler ist die Annahme, dass das Thema abgeschlossen sei, wenn die Hauptwebsite des Unternehmens funktioniert. In Wirklichkeit sind häufig die Nebensysteme am problematischsten: ältere administrative Subdomains, Geräte, Service-Panels, Partnerintegrationen, Testumgebungen mit externem Zugriff und Dienste, die in standardmäßigen Sicherheitsüberprüfungen nur selten auftauchen.

Der dritte Fehler besteht darin, Cross-Signing als strategische Ziel-Lösung zu betrachten. Solche Mechanismen waren als Kompatibilitätsbrücke nützlich, aber langfristig bewegt sich der Markt klar in Richtung Vereinfachung, Auslaufen alter Hierarchien und größerer Vorhersehbarkeit der Vertrauenspfade.

Warum passt dieses Thema in die breitere Richtung der WebPKI-Veränderungen?

Die Abkündigung von DigiCert G1 ist kein isolierter Vorfall. Sie ist ein weiteres Element eines größeren Bereinigungsprozesses innerhalb der öffentlichen PKI. Im Jahr 2026 führt die Branche parallel kürzere maximale Laufzeiten für TLS-Zertifikate, strengere Validierungsregeln, MPIC sowie weitere Einschränkungen für die Nutzung öffentlicher WebPKI außerhalb der klassischen Serverauthentifizierung ein. DigiCert und das Chrome Root Program signalisieren zudem weitere Maßnahmen zur Vereinfachung von Hierarchien und zur Eliminierung multifunktionaler Strukturen zugunsten klarerer, dedizierter TLS-Pfade.

Für Infrastrukturverantwortliche bedeutet das eines: Ein Zertifikat ist kein einmaliger Kauf mehr, sondern Teil eines kontinuierlichen Managementprozesses. Man muss wissen, wem das Zertifikat gehört, wo es eingesetzt wird, welchen Chain es verwendet, wie es erneuert wird, wer für die Domainvalidierung verantwortlich ist, wie das Monitoring funktioniert und ob die Umgebung sicher auf eine neue Hierarchie ohne manuelle Ausnahmen umgestellt werden kann.

Empfohlener Maßnahmenplan für Organisationen.

Der sinnvollste Ansatz ist nicht ein panischer Austausch von allem, sondern eine geordnete Impact-Prüfung und eine kontrollierte Migration.

Zunächst sollte eine Liste aller öffentlichen Zertifikate erstellt und geschäftlichen sowie technischen Verantwortlichen zugeordnet werden. Anschließend muss festgestellt werden, welche davon tatsächlich in G1 enden und welche Client-Systeme vom historischen Vertrauenspfad abhängen. Der nächste Schritt ist Reissue oder Renewal nach G2 oder G3, wo dies erforderlich ist, gefolgt von Kompatibilitätstests auf Seiten von Clients, Geräten und Integrationen. Am Ende sollte ein Monitoring stehen, das nicht nur das Ablaufdatum überprüft, sondern auch Änderungen im Chain, beim Intermediate und das operative Risiko bei künftigen Migrationen.

Aus geschäftlicher Sicht ist dies ein guter Moment, das Thema breiter zu betrachten als nur als „Bestellung eines neuen Zertifikats“. Organisationen, die heute ihr Inventory, ihr Monitoring und ihren Renewal-Prozess ordnen, werden nicht nur auf die Abkündigung von DigiCert G1 deutlich besser vorbereitet sein, sondern auch auf die nächsten Phasen des WebPKI-Wandels, einschließlich weiterer Verkürzungen der Zertifikatslaufzeit und strengerer Issuance-Regeln.

Fazit.

Die ab dem 15. April 2026 geltende Änderung bedeutet keine allgemeine Krise für alle DigiCert-Kunden. Sie markiert jedoch einen sehr konkreten Risikopunkt für jene Organisationen, die weiterhin aktive Zertifikate nutzen, die zu G1-Roots verketten, oder Umgebungen betreiben, die von älteren Vertrauensmodellen abhängen. In solchen Fällen wird das Problem nicht theoretisch sein. Es wird Vertrauensverlust in Browsern und potenzielle Fehler in TLS-basierten Diensten bedeuten.

Entscheidend ist daher nicht nur, sich das Datum zu merken, sondern drei Fragen zu beantworten: Wissen wir, wo in der Organisation noch G1-Ketten existieren, verstehen wir die Abhängigkeiten auf Seiten von Clients und Geräten, und haben wir einen Prozess, der es erlaubt, solche Deployments sicher und ohne Chaos oder Ausfallzeiten auf eine unterstützte Hierarchie zu migrieren. Organisationen, die dies jetzt tun, werden den 15. April 2026 als routinemäßige operative Änderung behandeln. Wer das Thema ignoriert, könnte das Problem erst dann entdecken, wenn ein Nutzer eine Warnung über ein nicht vertrauenswürdiges Zertifikat sieht.

Quelle:
– https://knowledge.digicert.com/alerts/digicert-tls-root-strategy-aligning-with-industry-standards
– https://www.digicert.com/blog/tls-certificate-rule-changes
– https://knowledge.digicert.com/general-information/digicert-root-and-intermediate-ca-certificate-updates-2023
– https://developers.cloudflare.com/ssl/reference/migration-guides/digicert-g1-distrust/