Zertifizierungsstelle wechseln: Plan B für TLS-Zertifikate

Warum eine Zertifizierungsstelle plötzlich ausfallen kann

Ob ein Browser einem Website-Zertifikat vertraut, entscheidet nicht die Zertifizierungsstelle, sondern das Root-Programm des Browsers oder Betriebssystems. Es führt einen Vertrauensspeicher (Root Store) mit den Root-Zertifikaten, die es akzeptiert, und behält sich vor, diesen Bestand zu ändern. Die Richtlinie des Chrome-Root-Programms sagt das ausdrücklich: Google nimmt Zertifikate nach eigenem Ermessen in den Chrome Root Store auf oder entfernt sie (Chrome Root Program Policy). Die Root-Store-Richtlinie von Mozilla enthält eine entsprechende Klausel für den Bestand, den Firefox und viele weitere Programme nutzen (Mozilla Root Store Policy).

Wie schnell das gehen kann, zeigte der Oktober 2026. Am 17. Oktober erhielt das Chrome-Root-Programm den Hinweis, dass die privaten Schlüssel mehrerer Zwischenzertifikate einer Zertifizierungsstelle mit zu wenig Zufall erzeugt worden waren (Google). Chrome sperrte die betroffenen Zwischenzertifikate noch am selben Tag über eine eigene Sperrliste (Google). Am 20. Oktober kündigte Google an, auch die zugehörige Root aus dem Chrome Root Store zu nehmen, und nannte als Termin den 27. Oktober (Google). Zwischen Ankündigung und geplanter Entfernung lagen damit sieben Tage (Google).

Für Betreiber war ein anderer Satz der wichtigste: Auch einige rechtmäßig ausgestellte Zertifikate unter dieser Root funktionieren in Chrome danach nicht mehr, und wer betroffen ist, muss sofort ein neues Zertifikat aus einer anderen Hierarchie beschaffen und einsetzen (Google). Betroffen waren also auch Websites mit gültigem Zertifikat, vollständiger Kette und ausreichender Restlaufzeit; nur der Vertrauensanker am oberen Ende sollte wegfallen.

Dazu kommt eine Pflicht, die auch ohne Root-Entfernung wirkt. Die Grundregeln für öffentlich vertrauenswürdige TLS-Zertifikate verlangen von Zertifizierungsstellen, ausgestellte Zertifikate unter bestimmten Umständen binnen 24 Stunden zu sperren (CA/Browser Forum). Das Gremium folgert daraus, dass Zertifikate so verwaltet werden sollen, dass sie sich innerhalb von 24 Stunden ersetzen lassen (CA/Browser Forum). Wie eine Sperrung heute beim Browser ankommt, beschreibt der Beitrag zur Zertifikatssperrung nach dem OCSP-Ende.

Geplante Wechsel: Altersgrenzen und weniger Roots

Neben Notfällen ändern die Root-Programme ihren Bestand nach festen Regeln. Die wichtigste ist eine Altersgrenze: Chrome nimmt Root-Zertifikate, deren Schlüsselmaterial vor mehr als 15 Jahren erzeugt wurde, fortlaufend aus dem Chrome Root Store (Chrome Root Program Policy). Mozilla entzieht Root-Zertifikaten für die Server-Authentifizierung das Vertrauen für Websites, sobald ihr Schlüsselmaterial älter als 15 Jahre ist (Mozilla Root Store Policy). Für ältere Roots hat Chrome einen Stufenplan veröffentlicht (Chrome Root Program Policy):

Für andere Fälle beschreibt die Richtlinie ein sanfteres Verfahren, das Auslaufen einer Hierarchie: Zertifikate, die vor dem Stichtag ausgestellt wurden, bleiben in Chrome bis zu ihrem Ablauf gültig, später ausgestellte gelten standardmäßig nicht mehr (Chrome Root Program Policy). Für Betreiber heißt das: Beim nächsten Erneuern kann die Kette aus einer neuen Hierarchie kommen, auch wenn sie die Zertifizierungsstelle gar nicht gewechselt haben. Wer die Kette fest in der Serverkonfiguration hinterlegt hat, liefert dann die falsche aus.

Eine zweite Regel verkleinert den Bestand weiter: Ab dem 15. September 2027 nimmt der Chrome Root Store höchstens zwei selbstsignierte Root-Zertifikate je CA-Betreiber auf (Chrome Root Program Policy). Auch ohne Vorfall wechseln deshalb in den nächsten Jahren manche Zertifikate ihre Hierarchie, und mit ihr die Kette, die der Server ausliefert.

Wie stark sich ein Bestand bewegt, zeigt die Kopie des Mozilla-Bestands, die das curl-Projekt als Datei für Programme ohne eigenen Vertrauensspeicher bereitstellt. Die Fassung vom 19. März 2026 enthielt 145 Zertifikate, die Fassung vom 14. Mai 2026 noch 121 (curl). Wer eine solche Datei einmal in eine Anwendung kopiert und danach nicht mehr aktualisiert, prüft gegen einen Stand, den es so nicht mehr gibt.

Wer welchem Bestand vertraut

Ein Zertifikat ist nicht für sich gültig, sondern gültig für einen bestimmten Client. Chrome prüft auf Windows, macOS, ChromeOS, Linux und Android gegen den eigenen Chrome Root Store und stützt sich dabei nicht auf den Standardbestand des Betriebssystems (Chrome Root Store FAQ). Auf iOS lassen Apples Vorgaben das nicht zu (Chrome Root Store FAQ). Firefox nutzt den Mozilla-Bestand, und Werkzeuge wie curl beziehen eine Kopie davon (curl). Java-Laufzeiten, Mobil-Apps, Zahlungsterminals und Geräte im Internet der Dinge (IoT) können eigene Bündel mitbringen.

Daraus folgt, dass eine Root in einem Bestand fehlen und im anderen noch stehen kann. Der Chrome Root Store wird im Normalbetrieb etwa vierteljährlich aktualisiert, bei Bedarf auch außer der Reihe, und die Änderungen kommen über einen eigenen Update-Mechanismus ohne neue Browserversion beim Nutzer an (Chrome Root Store FAQ). Andere Bestände folgen eigenen Takten: ein Betriebssystem-Update, ein Paket der Linux-Distribution, eine neue App-Version. Ein Gerät, das keine Updates mehr bekommt, behält seinen Stand.

Wie lang der Nachlauf alter Bestände sein kann, hat eine große ACME-CA beim Umstieg auf ihre eigene Root dokumentiert. Ende 2021 lief noch mehr als ein Drittel der Android-Geräte mit Betriebssystemständen, die Websites mit Zertifikaten dieser CA plötzlich nicht mehr vertraut hätten (Let's Encrypt 2023). In den drei Jahren bis Juli 2023 stieg der Anteil der Android-Geräte, die der neuen Root vertrauen, von 66 auf 93,9 Prozent (Let's Encrypt 2023). Android 14 kann seinen Vertrauensspeicher ohne komplettes Betriebssystem-Update erneuern (Let's Encrypt 2023).

Für Schnittstellen galt bei diesem Wechsel eine eigene Liste: Alle Clients einer API mussten die neue Root kennen, und Clients mit OpenSSL brauchten mindestens Version 1.1.0 (Let's Encrypt 2021). Genau diese Clients sieht kein Browsertest. Der Beitrag Bei uns geht die Seite, beim Kunden nicht zeigt, wie sich solche Unterschiede zwischen zwei Umgebungen eingrenzen lassen, und der Beitrag zur unvollständigen Zertifikatskette erklärt, warum ein Browser verzeiht, was eine Anwendung ablehnt.

Schritt 1: Wissen, wer Ihre Zertifikate ausstellt

Ein Plan B beginnt mit einer Bestandsaufnahme. Für jeden Hostnamen mit öffentlichem Zertifikat braucht es drei Angaben: die ausstellende Zertifizierungsstelle, die Root, an der die Kette endet, und den Weg, auf dem das Zertifikat erneuert wird. Ohne diese Liste lässt sich bei einer Meldung wie im Oktober nicht schnell beantworten, ob man betroffen ist.

Die Hauptdomain macht selten Schwierigkeiten, eher Subdomains, die ein Dienstleister, eine Fachabteilung oder ein früheres Projekt eingerichtet hat, etwa die Schnittstelle zur Warenwirtschaft oder ein Testsystem. Hier hilft Certificate Transparency: Seit dem 15. Juni 2026 müssen Zertifizierungsstellen unter dem Chrome Root Store jedes Vorzertifikat in mindestens ein von Chrome anerkanntes CT-Log eintragen, bevor sie das Zertifikat ausstellen (Chrome Root Program Policy). Die Logs bilden damit die öffentlich vertrauenswürdigen Zertifikate für Ihre Domain ab, auch die vergessenen. Wie man sie auswertet, beschreibt der Beitrag zum Überwachen von CT-Logs.

• Hostname und Zweck: www, Shop, Schnittstellen, Testsysteme, Weiterleitungsdomains.
• Aussteller und Root: ausstellende Zertifizierungsstelle, Zwischenzertifikat und das Root-Zertifikat am Ende der Kette.
• Erneuerungsweg: ACME-Client und Konto, Hosting-Oberfläche, vorgeschaltetes Netz oder Handarbeit.
• Zuständigkeit: wer das Zertifikat erneuert und wer bei einer Meldung entscheidet.
• Clients außerhalb des Browsers: Apps, Partner-Schnittstellen und Geräte, die den Hostnamen aufrufen.

Die Angaben zur Kette lassen sich für jeden Hostnamen mit einem Befehl ablesen. Die Ausgabe nennt für jedes Glied der Kette den Inhaber (s) und den Aussteller (i); der Aussteller des letzten Glieds ist die Root, an der die Kette endet.

Im laufenden Betrieb übernimmt das die SSL-Überwachung von XICTRAQ®. Der SSL-Tab zeigt Aussteller, Gültigkeit und Vertrauenskette, ein Website-Scan liest zusätzlich Kettenlänge und Root-CA aus (XICTRAQ-Dokumentation). Der Verlauf markiert einen Aussteller-Wechsel als eigenes Ereignis und reicht bis zu 90 Tage zurück (XICTRAQ-Dokumentation). Ab dem Business-Plan führt XICTRAQ® zusätzlich ein Inventar aller Zertifikate, die laut CT-Logs für die eigene Domain ausgestellt wurden, mit Aussteller und Ablaufdatum je Zertifikat; Details stehen beim DNS- und Domain-Monitoring.

Schritt 2: CAA mit Platz für eine zweite CA

Ein CAA-Eintrag im DNS legt fest, welche Zertifizierungsstellen für eine Domain ausstellen dürfen. Vor jeder Ausstellung muss eine Zertifizierungsstelle nach diesem Eintrag suchen; steht er da und passt die Anfrage nicht dazu, darf sie nicht ausstellen (RFC 8659). Das schützt vor fremden Ausstellungen, wird beim Wechsel aber zur Falle: Wer nur die bisherige Zertifizierungsstelle einträgt, sperrt im Notfall genau den Ausweichweg.

Die Norm sieht mehrere erlaubte Aussteller ausdrücklich vor. Ihr eigenes Beispiel erlaubt die Ausstellung für einen Hostnamen nur durch zwei bestimmte Zertifizierungsstellen (RFC 8659). Berechtigungen addieren sich, jeder issue-Eintrag erlaubt eine weitere Stelle (RFC 8659). Für Wildcard-Zertifikate kann ein eigener issuewild-Eintrag gelten, und iodef nennt eine Adresse, an die Zertifizierungsstellen abgelehnte Anfragen melden können.

; Haupt-CA und vorbereitete Ausweich-CA
beispiel.invalid.  3600  IN  CAA  0 issue "ca1.example.net"
beispiel.invalid.  3600  IN  CAA  0 issue "ca2.example.org"
; ohne issuewild gelten die issue-Einträge auch für Wildcards
; Meldungen abgelehnter Anfragen
beispiel.invalid.  3600  IN  CAA  0 iodef "mailto:pki@beispiel.invalid"

Wer die Ausstellung zusätzlich an ein bestimmtes Konto binden will, nutzt den Parameter accounturi (RFC 8657). Er gilt je Eintrag: Nennt er ein Konto bei einer anderen Zertifizierungsstelle als der im Eintrag genannten, ist der Eintrag unerfüllbar (RFC 8657). Für den Plan B heißt das, das Ausweich-Konto vorher anzulegen und seine Kennung in den zweiten issue-Eintrag zu schreiben. Das Chrome-Root-Programm verlangt von Zertifizierungsstellen mit ACME-Schnittstelle, diese Konto-Bindung zu unterstützen (Chrome Root Program Policy). Mehr zu den Einträgen und zur Absicherung mit DNSSEC steht im Beitrag zu CAA-Records und DNS-Härtung.

XICTRAQ® fragt die DNS-Records samt CAA in den bezahlten Plänen alle 6 Stunden ab, im Free-Plan alle 24 Stunden (XICTRAQ-Funktionsseite). Jede Änderung des CAA-Satzes löst einen Alarm aus, das Entfernen jeder Sperre als kritischen Alarm, und die Bewertung zeigt, ob die Einträge den Aussteller Ihres aktiven Zertifikats decken (XICTRAQ-Dokumentation). Passt der CAA-Satz nicht mehr zum aktiven Aussteller, etwa weil nach einem Wechsel nur der alte Eintrag zurückgesetzt wurde, erscheint „Aussteller nicht gedeckt“, und die nächste Erneuerung bei dieser Stelle wäre nicht zulässig. Einzelheiten stehen im Handbuch unter DNS und E-Mail.

Schritt 3: Einen ACME-Ausweichweg vorbereiten

Ein Plan B ist nur so schnell wie die Ausstellung bei der zweiten Zertifizierungsstelle. Mit dem Automatic Certificate Management Environment (ACME) lässt sie sich ohne Handarbeit anstoßen, sofern Konto, Validierung und Auslieferung vorher eingerichtet sind. Die Voraussetzungen dafür werden besser: Ab dem 15. März 2027 müssen alle gültigen Zwischenzertifikate unter einer Root im Chrome Root Store an eine Automatisierungslösung angebunden sein, ACME oder ein vergleichbares Verfahren (Chrome Root Program Policy). Unterstützt eine Hierarchie ACME, muss sie außerdem ACME Renewal Information anbieten (Chrome Root Program Policy).

1. Zweite Zertifizierungsstelle wählen: aus einer anderen Hierarchie, mit ACME und mit einer Root, die Ihre wichtigsten Clients kennen. Organisationsvalidierte Zertifikate brauchen Vorlauf für die Prüfung der Firmendaten.
2. Konto anlegen und eintragen: das ACME-Konto bei der zweiten Stelle registrieren und sie in CAA aufnehmen, bei Konto-Bindung samt accounturi.
3. Ausstellung testen: auf einem Testsystem oder einer Test-Subdomain einmal ein echtes Zertifikat ziehen, inklusive Validierung über HTTP oder DNS.
4. Kette mitnehmen: den ACME-Client so einstellen, dass er bei jeder Ausstellung die Kette der Zertifizierungsstelle lädt und keine fest eingetragene Kette ausliefert.
5. Umschalten dokumentieren: welche Konfiguration geändert wird, wer den Dienst neu lädt und wie die neue Kette von außen geprüft wird.

Der vierte Punkt ist weniger selbstverständlich, als er klingt. Eine Zertifizierungsstelle hat beim Umbau ihrer Kette die Fehlerbilder bei ACME-Clients aufgezählt: Die Kette wurde gar nicht geladen und nur das Website-Zertifikat ausgeliefert, die Kette wurde nicht geladen und stattdessen eine fest eingetragene ausgeliefert, oder die Kette wurde nur bei der ersten Ausstellung geladen und bei Erneuerungen nicht mehr (Let's Encrypt 2023). Jeder dieser Fehler führt beim Wechsel zu einer anderen Zertifizierungsstelle zu einer ungültigen Kette, weil die alte Kette nicht zum neuen Zertifikat passt.

Als kurze Datei neben der Serverkonfiguration kann der Ausweichweg so aussehen:

hostnamen:
  - www.beispiel.invalid
  - shop.beispiel.invalid
  - api.beispiel.invalid
haupt_ca:
  acme_directory: https://acme.ca1.example.net/directory
  caa: "ca1.example.net"
ausweich_ca:
  acme_directory: https://acme.ca2.example.org/directory
  caa: "ca2.example.org"
  konto_angelegt: 2026-11-08
  testausstellung: test.beispiel.invalid, 2026-11-10
umschalten:
  verantwortlich: Betrieb, Bereitschaft
  dienst_neu_laden: systemctl reload nginx
  kontrolle_extern: openssl s_client -showcerts
weitere_clients:
  - App iOS und Android
  - Partner-Schnittstelle Warenwirtschaft

Die ACME-Erweiterung ACME Renewal Information ist für den Plan B mehr als eine Komfortfunktion. Sie erlaubt der Zertifizierungsstelle, Clients einen früheren Erneuerungszeitpunkt vorzuschlagen, etwa vor einer Massensperrung, damit deren Folgen kleiner ausfallen (RFC 9773). Ein Client, der diese Hinweise auswertet, erneuert dann rechtzeitig bei der bisherigen Stelle. Fällt die Stelle selbst aus dem Vertrauen, hilft nur das zweite Konto. Wie man die Erneuerung insgesamt testet, beschreiben die Beiträge zu ACME-Erneuerung testen und zur SSL-Automatisierung mit ACME.

Kürzere Laufzeiten machen den Ausweichweg zum Normalfall. Das CA/Browser Forum hat beschlossen, die Höchstlaufzeit öffentlicher TLS-Zertifikate von 398 auf 47 Tage zu senken (CA/Browser Forum), in Stufen von März 2026 bis März 2029 (CA/Browser Forum). Wer ohnehin alle paar Wochen erneuert, kann einen Wechsel der Zertifizierungsstelle wie eine gewöhnliche Erneuerung behandeln, sofern der zweite Weg einmal funktioniert hat.

Schritt 4: Was beim Wechsel sonst bricht

Auch wenn das neue Zertifikat in allen Browsern gültig ist, können Clients außerhalb des Browsers daran scheitern. Vier Stellen verdienen dabei besondere Aufmerksamkeit.

Die Client-Authentifizierung hat ein festes Datum: Website-Zertifikate unter Roots im Chrome Root Store, die ab dem 15. März 2027 ausgestellt werden, dürfen als Verwendungszweck nur noch die Server-Authentifizierung tragen (Chrome Root Program Policy). Wer ein Website-Zertifikat heute auch für gegenseitig authentifizierte Verbindungen nutzt, braucht dafür spätestens dann einen anderen Weg, unabhängig davon, ob er die Zertifizierungsstelle wechselt.

Für die Prüfung der Clients reicht kein Browser; sinnvoll ist ein Test der Clients aus Schritt 1 gegen ein Zertifikat der Ausweich-Stelle auf einem Testsystem. Der kostenlose SSL-Check zeigt von außen, welche Aussteller-Kette ein Server ausliefert und welche TLS-Version er aushandelt. Ob eine bestimmte App der neuen Root vertraut, lässt sich nur mit dieser App klären.

Der Ablauf am Tag X

Kommt eine Meldung wie im Oktober, entscheidet die Reihenfolge. Mit vorbereitetem Plan B sieht sie so aus:

1. Betroffenheit prüfen: in der Inventarliste nachsehen, welche Hostnamen an der genannten Root oder dem Zwischenzertifikat hängen.
2. Frist lesen: Gilt die Änderung für neue oder auch für bestehende Zertifikate, und ab wann in welchem Client?
3. Ausweich-Stelle anstoßen: Zertifikate für die betroffenen Hostnamen über das vorbereitete Konto ausstellen.
4. Ausliefern: Zertifikat und Kette einsetzen, Dienste neu laden, Lastverteiler und vorgeschaltete Netze einbeziehen.
5. Von außen prüfen: Kette, Root und Hostnamen extern kontrollieren, danach die Clients außerhalb des Browsers.
6. Nachziehen: CAA, Inventar und Zuständigkeiten aktualisieren.

Ohne Vorbereitung kommen zu diesen sechs Schritten weitere hinzu: ein Konto bei einer neuen Zertifizierungsstelle eröffnen, CAA ändern und auf die Resolver warten, die Validierung erstmals einrichten, die Freigabe im eigenen Haus einholen. Das kann in eine Frist von sieben Tagen passen (Google), in eine Frist von 24 Stunden kaum (CA/Browser Forum).

Was XICTRAQ® dabei sieht und was nicht

Ein Monitoring ersetzt keinen Plan B, aber es zeigt, wo er gebraucht wird und ob er gewirkt hat. XICTRAQ® prüft Gültigkeit, Aussteller, Protokoll und Restlaufzeit im Dauerbetrieb, in den bezahlten Plänen alle 6 Stunden, im Free-Plan alle 24 Stunden (XICTRAQ-Dokumentation). Scheitert die Prüfung der Kette, löst XICTRAQ® einen eigenen kritischen Alarm aus, unabhängig von der Ablauf-Vorwarnung (XICTRAQ-Dokumentation). Über welche Kanäle er Sie erreicht, legen Sie unter Alerting und Benachrichtigungen fest.

Wichtig ist, gegen welchen Bestand geprüft wird. XICTRAQ® validiert die Kette gegen das Mozilla-Root-Bundle des Prüfservers (XICTRAQ-Dokumentation). Wie aktuell dieser Bestand ist, hängt am Systempaket des Servers. Entfernt nur Chrome eine Root aus dem Chrome Root Store, während sie im Mozilla-Bestand noch steht, sieht diese Prüfung den Vertrauensentzug nicht, und XICTRAQ® meldet das Zertifikat dann weiter als gültig.

Was XICTRAQ® beiträgt, ist das Wissen über den Bestand. Damit lässt sich bei einer Meldung eingrenzen, welche Hostnamen an welcher Hierarchie hängen, und nach dem Wechsel belegen, dass die neue Kette ausgeliefert wird. Alle Felder beschreibt das Handbuch unter SSL und TLS.

Plan B vorbereiten, solange keine Frist läuft

Ein Wechsel der Zertifizierungsstelle lässt sich am ruhigsten vorbereiten, solange niemand ihn erzwingt. Die Bausteine sind überschaubar: eine Inventarliste, ein zweiter CAA-Eintrag, ein Konto bei einer zweiten Stelle und eine Testausstellung. Danach ist ein Vertrauensentzug in einem Root-Programm ein Termin im Kalender und keine Nachtschicht.

Wer den Bestand nicht von Hand pflegen will, kann Aussteller, Ketten und CAA-Einträge seiner Websites mit XICTRAQ® überwachen lassen. Was die einzelnen Pläne enthalten, steht auf der Preisseite; wie SSL-Tab und Zertifikats-Inventar aussehen, zeigt die Live-Demo ohne Anmeldung.