SSL.com rotiert Root-Zertifikate am 5.5.2026; es hat bei der Denic gerumpelt

Ich kippe noch ein Thema hier im Blog ein, was ich am gestrigen 5. Mai 2026 geplant hatte, aber nicht mehr geschafft habe. SSL.com hat am 5.5.2026 seine Root-Zertifikate geplant rotiert. Sollte keine Probleme geben, wenn die betreffenden Stellen ihre Hausaufgaben gemacht haben, hieß es. Wenn ich die Kommentare hier im Blog richtig deute, ist der Austausch der Zertifikate bei einigen Internet-Anbietern bzw. bei der DENIC aber "irgendwie daneben gegangen" und es gab Probleme. Die DENIC hat die Nacht, nach einer Großstörung, einen Incident-Report eröffnet, weil viele Seiten standen. Ich zeichne mal nach, was bei mir liegen geblieben und dann die Nacht passiert ist. Ich interpretiere die beiden oben angerissenen Punkte als zusammenhängend – mag mich aber täuschen. Ergänzung: Hab mich getäuscht, waren zwei unabhängige Fehler – bei der DENIC ist ein DNSSEC ZSK-Rollover fehlgeschlagen. DENIC hat Zonendaten mit dem ZSK-Schlüssel Keytag 33834 signiert, aber nicht als DNSKEY-Eintrag veröffentlicht.

SSL.com rotiert am 5.5.2026 Root-Zertifikate

Mir ist am 5. Mai 2026 am Nachmittag der nachfolgende Tweet des SANS-Institute (Internet Storm Center) zur SSL.com Zertifikatsrotation untergekommen. Es heißt dort "SSL.com wechselt heute sein Stammzertifikat" – die Details werden hier beschrieben.

Jemand wurde gemäß obigem Text informiert, dass das Root-Zertifikat von SSL.com rotiert (also ausgetauscht werde). Musste irgendwann in der Nacht vom 5. auf den 6. Mai 2026 in Deutschland wirksam werden.

Ich hatte den SANS-Beitrag (siehe auch nachfolgenden Auszug) kurz überflogen und die folgende Aussagen mitgenommen:

Das ist für eine Zertifizierungsstelle ganz normaler Tagesgeschäft, aber Zertifikate werden für alle möglichen Zwecke verwendet, und manchmal werden sie nicht so eingesetzt, wie sie sollten, sodass es gelegentlich zu kleinen Problemen kommen kann. Wenn du sie nur für einfache Zertifikate und Websites nutzt, brauchst du dir keine Sorgen zu machen. Wenn Sie jedoch über diese grundlegende Implementierung hinausgehen, sollten Sie die Mitteilung lesen, um sicherzustellen, dass diese Änderung keine Auswirkungen auf Ihre Dienste hat.

Ist also Tagesgeschäft, hieß es, es sollte keine Probleme geben, außer die oben genannten Spezialitäten treffen zu. Nachfolgend noch der Original-Text des SANS-Beitrags:

I just got an email from SSL.com last night, they are rotating  out their root certificate today (May 5,2026).  This is normal, business as usual stuff for a CA, but certificates get used for all kinds of things, and sometimes they aren't used like they should be, so sometimes hiccups happen.

If you are using them for basic cert+website stuff, there's no need to worry.  But if you go past that basic implementation, you should read their note to make sure that this change won't be affecting any of your services.  Even if you don't use ssl.com, it's a good read, as every certificate expires, which means that everyone's root cert rotates out eventually – so forewarned if forearmed and all that ..

In particular (from the email):

• If you have pinned trust anchors, custom trust stores, or certificate validation logic tied to the 2016 roots, please audit those configurations promptly to avoid disruptions.
• Use cross-certificates. If you need backward compatibility with the 2016 root hierarchy during the transition, cross-certificates can bridge the gap.
• Migrate to dedicated Client Certificates. These are purpose-built for client authentication and are unaffected by Google Chrome's upcoming server authentication requirements, which impact SSL/TLS certificates with the ClientAuth EKU.

Their full post is here:

https://www.ssl.com/article/what-ssls-root-migration-means-for-you

===============
Rob VandenBrink
rob@coherentsecurity.com

Unter dieser Prämisse kam ich gestern (5.5.2026) aus Zeitmangel nicht dazu, obigen Hinweis im Blog einzustellen. Es sollte ja nichts passieren – und das Ereignis von SSL.com würde passieren, wenn es in Deutschland Nacht ist, "also alles schläft und im Internet das Licht ausgeknipst ist". Ich deute nachfolgende Sachverhalte mal so, dass ich mich dann "irgendwie geirrt habe", denn es hat am gestrigen 5.5.2026 geruckelt. Bevor ich das aufarbeite, aber noch ein kurzer Einschub mit einem Hinweis.

D-Trust zieht am 8. Mai 2026 S/MIME-Zertifikate zurück

Tomas Jakobs merkte gestern (5.5.2026) noch im Diskussionsbereich folgendes an – ich ziehe es mal separat raus, weil ich die Einträge im Diskussionsbereich zyklisch bereinige:

Bei D-Trust (also D minus Trust) läufts… alle S/MIME Certs werden am 8. Mai zurückgezogen. Die haben wieder als CA schlampig gearbeitet.

Quelle ist der D-Trust Post Personenzertifikate. Jakobs merkt an "Ja sind die gleichen mit den faulen Ostereiern" und verlinkte auf den Blog-Beitrag D-Trust verlangt bis 6.4.2026 (Ostermontag) Zertifikatsausstausch, wo ein Zertifikatswechsel ein "bisserl kurz" passieren musste. Jakobs merkt zudem an, dass D-Trust nicht mal ein Datum oder Changelog ihrer Meldung beigeführt haben. Immerhin: Vom 5. bis zum 8. Mai 2026 ist ja noch massig Zeit, um zu reagieren.

Mein zarter Hinweis auf ssl.com Zertifikatsablauf

Ich hatte auf obigen Kommentar von Jakobs am 5. Mai 2026 gegen 22:20 Uhr nur kurz mit "Hab es gelesen, heute laufen ssl.com certs ab. Bin aber ein bisschen zu kaputt." geantwortet. Hätte es deutlicher ausführen müssen, statt nur einen zarten Hinweis, dass die Nacht was passieren könnte, zu posten.

Und so hat obiger Hinweis des SANS es gestern aus Zeitmangel nicht in den Blog geschafft – ich war schlicht "platt" und habe einige Minuten später "an der Matratze gehorcht". Wird schon nichts passieren […].

Ist mutmaßlich nicht "glatt" gegangen: DENIC-Störung

Als ich heute früh den Blog aufgerufen habe (ja, der war erreichbar), war der Diskussionsbereich mit Kommentaren geflutet. Es hat am Abend "hickups" (Schluckauf) in diesem Internet gegeben. Auch meine Social Media Kanäle waren mit Direktnachrichten geflutet – hab es erst im Nachgang gesehen. Spoiler: Es waren aber zwei unabhängige Sachverhalte – ohne DENIC-Problem hätten wir nichts mitbekommen.

1. Leserhinweis auf DNS-Auflösungen in .de-Zone

Ein Leser mit dem Alias dima meint am 5. Mai um 23:09 Uhr "DNS Auflösungen für die .de Zone gerade mit Problemen." und hat nach reddit.com PSA: Die .de-Zone löst gerade großflächig nicht mehr auf, Problem vermutlich bei der DENIC verlinkt. Glücklicherweise hilft die Blog-Leserschaft. Norddeutsch merkt an:

 Statusgator schlägt bei Denic Service rot an – Hacker News diskutiert hier

Jemand der Nameserver in Kaskade oder Fallback mit etwas Puffer konfiguriert hat merkt es evtl. verspätet oder (noch) nicht.

Macht Euch keine Sorge – laut Denic-Blog hier sind die "bereit, wenn es ernst wird"! Die gucken zu dritt auf einen Monitor, nicht 5-Eyes, Six Eyes!

Die DENIC ist also sofort rein gegrätscht, weil es deftige Probleme gab.

2. Leserhinweis auf Probleme

Wenn der Blog seine Leser nicht hätte (wäre alles an mir vorbei gegangen, denn ich habe geschlafen) Heute morgen waren meine Social Media-Kanäle mit Direktnachrichten zur Störung geflutet (danke an alle Leser für diese Hinweise). Und Bolko hat alles im Diskussionsbereich zeitnah protokolliert und schrieb einige Minuten später zur Störung:

Mehrere Seiten sind gleichzeitig Down (2026-05-05 — ca 22:58 – 23:30 Uhr MESZ):

amazon.de
dhl.de
Spiegel.de
faz.de
frankfurterallgemeine.de
easyapotheke.de

Bolko wies darauf hin, dasss, laut diesem Kommentar bei heise, bei anderen Usern auch andere Seiten (gegen 22:58 Uhr MESZ) nicht mehr funktionieren:

Juvalis.de
Kabelscheune.de

Bolko schrieb: "Ab ca 23:30 Uhr MESZ funktionierte es bei mir wieder. Was war denn da los?". Er wies darauf hin, dass es bei deskmodder.de, im heise-Newsticker und bei reddit auch Meldungen zu den Ausfällen von de-Domains gebe. Das Problem sei unabhängig von Providern und DNS-Anbietern. Zitat aus dem Bolko-Kommentar zu einem heise-Post:

"Erste Hinweise auf das Problem erreichten uns gegen 21:50"

"Einen Ausweg für Nutzer gibt es derzeit noch nicht. Es hilft auch nicht, den DNS-Anbieter auf dem eigenen Rechner oder im Router zu ändern"

Zum reddit.com-Post hatte Bolko folgenden Textauszug als Kommentar im Diskussionsbereich hinterlassen.

23:37 – 23:50 Uhr …: wieder down:
dhl.de
faz.de
stern.de
easyapotheke.de
die-staemme.de
seitedown.de

Mir sprang sofort der obige SANS-Hinweis als Ursache in den Sinn, wobei ich nicht weiß, zu welcher Uhrzeit der SSL.com-Zertifikatswechsel genau passierte. Wenn dort ein Root-Zertifikat bei der DENIC ungültig wird, kann ich mir schon Kollateralschäden vorstellen.

Die DENIC wartet und meldete eine Störung

Viel interessanter ist aber, dass die DENIC (laut einem Kommentar von Bolko) gegen 23:28 CEST am 5. Mai 2026 bereits von einer "DNSSEC disruption" auf deren Statusseite chreibt, die .de-Domains beeinträchtigt. Hier der Kommentartext von Bolko:

DENIC-Status:
"Active Incident"
"DNSSEC disruption affecting .de domains"

May 5, 2026 23:28 CEST
May 5, 2026 21:28 UTC
INVESTIGATING

Frankfurt am Main, 5 May 2026 – DENIC eG is currently experiencing a disruption in its DNS service for .de domains. As a result, all DNSSEC-signed .de domains are currently affected in their reachability.

The root cause of the disruption has not yet been fully identified. DENIC's technical teams are working intensively on analysis and on restoring stable operations as quickly as possible.
Based on current information, users and operators of .de domains may experience impairments in domain resolution. Further updates will be provided as soon as reliable findings on the cause and recovery are available.
DENIC asks all affected parties for their understanding.
For further enquiries, DENIC can be contacted via the usual channels."

https://status.denic.de/

Bolko hinterließ noch das Wort "Cyberwar" im Kommentar, würde ich aber ausschließen. Interessanter ist die Ergänzung von Bolko, der am 6. Mai gegen 0:06 Uhr dazu im Diskussionsbereich schrieb:

Es gab heute am 5. Mai geplante Wartungsarbeiten beim DENIC:

"[COMPLETED] DENIC (.DE) Registry Scheduled Maintenance – May 5, 2026

Dear Customers,
This is to let you know that on May 5, 2026, DENIC, the registry of .DE domains will be processing a scheduled maintenance."

*ttps://www.namecheap.com/status-updates/planned-denic-de-registry-scheduled-maintenance-may-5-2026/

Sind diese geplanten Wartungsarbeiten beim DENIC fehlgeschlagen?

Norddeutsch scheint auch nicht schlafen gekonnt zu haben und hat dauernd geschaut, ob jemand das Licht in diesem Internet ausgeknipst hat. Er schrieb um 0:14 Uhr heute früh als Antwort auf die obige Frage von Bolko, ob die DENIC-Wartung fehlgeschlagen sei, folgendes:

Laut Denic selbst Nein @Bolko: status[.]denic.de/ 21:28 UTC – INVESTIGATING:

"Frankfurt am Main, 5 May 2026 – DENIC eG is currently experiencing a disruption in its DNS service for .de domains. As a result, all DNSSEC-signed .de domains are currently affected in their reachability.
The root cause of the disruption has not yet been fully identified. DENIC's technical teams are working [..] as quickly as possible."

ausserdem gucken die mit 6-Eyes auf einen Monitor – die sind gerüstet wenn es ernst wird, s.o.. Rettet nicht nur Timmy – rettet auch DE!

Bolko ergänzte dann heute (6.5.2026) 0:20 Uhr im Diskussionsbereich:

"Die Ursache ist scheinbar ein fehlgeschlagener DNSSEC ZSK-Rollover bei DENIC. DENIC hat Zonendaten mit dem ZSK-Schlüssel Keytag 33834 signiert, diesen Schlüssel aber nicht im DNSKEY-Eintrag veröffentlicht. Jeder DNSSEC-validierende Resolver sieht die Signatur als ungültig an und antwortet mit  SERVFAIL  und dem Fehler:"

EDE: 6 (DNSSEC Bogus): RRSIG with malformed signature found for de/soa (keytag=33834)

Sobald DENIC das fixt dauert die Propagation ca. 2 Stunden.

gefunden bei reddit.com in diesem Kommentar

2. Cloudflare-Status:

Resolution Issues for .de Domains

Update – We are continuing to work on a fix for this issue.
May 05, 2026 – 22:14 UTC

Update – The issue has been identified as a DNSSEC signing problem at DENIC, the organization responsible for the .DE top-level domain. Cloudflare is temporarily disabling DNSSEC validation on 1.1.1.1 resolver in order to allow .DE names to continue to resolve. DNSSEC validation will be re-enabled when the signing problems at DENIC are known to have been resolved.

May 05, 2026 – 22:01 UTC

Identified – The issue has been identified and a fix is being implemented.
May 05, 2026 – 21:20 UTC

cloudflarestatus.com

Dann hat Bolko gegen 0:59 Uhr heute früh einen Signaturfehler beim DENIC im Diskussionsbereich dokumentiert. Ich ziehe es mal heraus, da ich die Einträge im Diskussionsbereich zyklisch lösche:

Signaturfehler beim DENIC

Befehl:
dig f.nic.de @8.8.8.8

Ergibt:
(DNSSEC BOGUS): RRSIG with malformed signature

Screenshot:
*ttps://pbs.twimg.com/media/HHlTw4oWwAI-hJ7.jpg?name=orig

Das bedeutet, dass die Antworten auf DNS-Abfragen als gefälscht angesehen werden, weil die Signatur ungültig ist.

Eine unsichere temporäre Abhilfe ist es, als DNS-Server die IP 9.9.9.10 einzutragen, weil dieser DNS-Server die Signatur ignoriert.

2.
Cloudflare hat jetzt die Signaturprüfung für ihren DNS-Server 1.1.1.1 abgeschaktet, damit de Domains wiedser aufgelöst werden können.

"Cloudflare has temporarily disabled DNSSEC validation on 1.1.1.1 resolver in order to allow .DE names to continue to resolve"

*ttps://www.cloudflarestatus.com/

Diese Abschaltungen der Signaturprüfungen könnten aber auch gefährlich werden, falls mal einer der DNS-Server die IPs falsch auflöst und die angefragten Daten dann von einem anderen Server kommen, ohne dass das dann auffällt.

Aus meiner Sichtweise deutete ich diese Probleme in obigem Beschreibungen (fälschlicherweise) schlicht als Folgen aus dem oben berichteten Wechsel des SSL.com-Root-Zertifikats.

Fehleranalyse in kurz

Ergänzung: Die Aussage "ZSK-Schlüssel Keytag 33834 signiert" deutet zwar etwas anderes an, und ich lag falsch. Aber mir sah es bei der ersten Sichtung von Meldungen so aus, dass die SSL.com-Geschichte und die DENIC-Wartung möglicherweise zusammen hängen. Dann gab es noch einen Fehler, so dass der alte Spruch "Koinzidenz ist keine Kausalität" doch wieder zutrifft. Es geht ja bei genauem Lesen der DENIC Statusmeldungen bereits hervor. Bolko hat es in einem weiteren Kommentar aufgeschlüsselt:

Fehleranalyse von Blackfort Technology zu dem DNS-Problem:

DNSSEC-Fehler in der .de-Zone: Warum bahn.de, spiegel.de und blackfort-tec.de per SERVFAIL ausfielen

Ursache: fehlerhafter NSEC3-RRSIG (Keytag 33834).

Lösung: DENIC hat den betroffenen NSEC3-Hash-Bereich um 20:15 UTC mit einem neuen Schlüssel (Keytag 32911) neu signiert.

Kann alles so einfach sein. Inzwischen sollte dieses Internet aber eigentlich wieder bei allen Beteiligten funktionieren, oder ruckelt es noch?