Ostern gibt es Eier als Überraschung; von D-Trust, einer Tochter der Bundesdruckerei gibt es eine Überraschung dre anderen Art (könnte man als faules Ei ansehen, da die Problematik seit dem 15. März 2026 bekannt ist). Unschön dabei: Administratoren, die D-Trust TLS-Zertifikate auf Websites oder anderswo einsetzen, müssen diese bis Ostermontag, den 6. April 2026, 17:00 Uhr austauschen. Es handelt sich um einen kurzfristigen Rückruf neu ausgegebener TLS-Zertifikate.
Wer ist D-Trust?
Wie bereits oben hingewiesen, ist die D–Trust GmbH ein Unternehmen der Bundesdruckerei-Gruppe und fungiert als ein zertifizierter Vertrauensdiensteanbieter. Das Unternehmen bietet laut Webseite rechtssichere und zertifizierte Vertrauensdienste wie digitale Zertifikate und elektronische Signaturen sowie Lösungen zum sicheren Datenmanagement wie Datentreuhänder-Plattformen an.
Obiger Screenshot zeigt, dass die D-Trust GmbH stark im Geschäft ist, und mit dem virtuellen Institutionsausweis in Kliniken und Praxen, aber auch mit dem Austausch des elektronischen Heilberufsausweis (eHBA) für Ärzte und Therapeuten befasst ist (läuft zum 30.6.2026 ab).
D-Trust und BSI informieren über Zertifikatsaustausch
Es wäre an mir vorbei gegangen, aber Blog-Leser haben mich auf den Sachverhalt und diesen heise-Artikel zum Thema hingewiesen. D-Trust scheint ein Fehler bei der Ausstellung von TLS-Zertifikaten für Webseiten passiert zu sein. Gemäß Einblendung auf der D-Trust-Webseite werden kurzfristig TLS-Zertifikate zurückgerufen.
Betroffen sind TLS-Website-Zertifikate, die von der D-Trust GmbH zwischen dem 15.03.2025 und dem 02.04.2026, 10:45 Uhr ausgestellt wurden. Diese Zertifikate verlieren bereits am Montag, 06.04.2026, 17:00 Uhr, ihre Gültigkeit und sind ab diesem Zeitpunkt nicht mehr einsetzbar! Betroffene Administratoren müssen neue TLS-Zertifikate beantragen und dann ihre Systeme aktualisieren.
Auch das BSI hat zum 4. April 2026 eine Pressemitteilung herausgegeben, in der das Bundesamt für Sicherheit in der Informationstechnik alle Kunden der D-Trust GmbH dazu aufruft, schnellstmöglich neue Zertifikate für alle Dienste zu beantragen, die mit den betroffenen D-Trust-Zertifikaten abgesichert werden. Neben Webseiten können hier auch weitere Dienste wie zum Beispiel MDM-Verbindungen einen Zertifikatsaustausch erfordern.
Ergänzung: Ich habe es initial nicht erwähnt, dachte es liegt an meinem Chromium-Browser, den ich einige Tage nicht mehr aktualisiert habe. Die Webseiten des BSI wurden mir heute Nacht beim Schreiben des Beitrags im Chromium als "nicht sicher" verweigert. Ein Edge in einer VM konnte die Seite anzeigen. Der Firefox auf meinem Produktivsystem auch. Nachdem ein Kommentar das unten auch andeutet, habe ich die Ergänzung mal aufgenommen. Muss ich das bereits so interpretieren, dass die BSI TLS-Zertifikate bereits ausgetauscht wurden?
Im Zuge dieser kurzfristig seitens der D-Trust GmbH erfolgten Maßnahme kann es während des Austauschs zu temporären Ausfällen zahlreicher Websites kommen – auch Institutionen der Bundesverwaltung sind betroffen. Die Maßnahme und in der Folge gegebenenfalls temporär auftretende Ausfälle stehen jedoch nicht im Zusammenhang mit einem Cyberangriff, stellt das BSI klar.
Hintergrund des Schlamassels
Bei Bugzilla gibt es einen Eintrag D-Trust: TLS Precertificates Exceeding the Maximum Validity Period Allowed by the TLS Baseline Requirements, der nach meiner Zählweise am 15. März 2026 entdeckt wurde. Dort heißt es, dass die D-Trust festgestellt habe, dass 19 TLS-Pre-Zertifikate mit einer Gültigkeitsdauer ausgestellt wurden, die die in den TLS-Baseline-Anforderungen festgelegte maximale Gültigkeitsdauer von 200 Tagen überschreitet.
Das Problem wurde eine Weile diskutiert und dann wohl von D-Trust so am 1. April 2026 behoben. Die zwischenzeitlich ausgestellten TLS-Zertifikate müssen dann binnen fünf Tagen verworfen werden (daher der 1. April, oben im Screenshot sagt D-Trust 2.4.2026, was bei 5 Tagen den 7.4.2026 für den Zertifikatswechsel bedeutet hätte). Von daher verstehe ich den 6.4.2026 als Ablaufdatum nicht. Doppelt doof ist halt, dass das Auslaufdatum in Deutschland auch noch ein Feiertag ist.
MVP: 2013 – 2016
Laut den Qualys SSL Labs ist die Seite vom BSI auf Apple, Android und für aktuelle Java Trust Stores als nicht mehr vertrauenswürdig eingestuft. Kann ich auf meinem Apple iPhone ebenfalls nachvollziehen. Die ausstellende CA für das Zertifikat der BSI Seite kommt auch von D-Trust.
Danke, hab mich die Nacht nicht getraut, zu gestehen, dass mein einige Tage nicht aktualisierter Ungoogled Chromium auch gestreikt hat. Der Firefox hat gespurt. Ist jetzt oben nachgetragen.
Das geht aber wieder seit kurzem, das Zertifikat wird mit Cross-Signing einer vertrauenswürdigen CA ausgeliefert
Genau, D-Trust hat die Root CA von 2023 auch mit der alten Root CA von 2009 signiert. Diese muss dann einfach als zusätzliche Intermediate-CA in die Webserver Konfiguration. Es gibt aber leider auch (ältere) Clients die mit zwei Intermediate-CAs nicht umgehen können, selten aber die gibt es.
Die 2009er CA hat aber einen 2048 bit Publickey und entspricht eigentlich nicht mehr den BSI Richtlinien. Die ganzen Anforderungen im Cryptobereich sind schon verrückt (ETSI,eIDAS,CAB-F,RFC,BSI,NIST usw. usf.) ETSI ist am schlimmsten, weil so abstrakt.
Die neuen D-Trust Zertifikate sind genauso kaputt wie die Alten.
Jetzt verwendet man einen völlig unüblichen SHA-512.
Den unterstützt nicht nur ältere Soft- und Hardware nicht, sondern z. B. auch der aktuelle Apple Safari. Mit DoS und SHA512 könnte man heute noch sehr viel in die Knie zwingen. Seine Berechnung wird nicht hardwareunterstützt und der Rechenaufwand selbst steigt auch merklich. Er wird deshalb bisher als nur optionaler Algorithmus völlig zu Recht deaktiviert.
Zuvor hat man mit zwei 2048 bit RSA Schlüsseln, statt einem 4096 bit RSA Schlüssel signiert. Genauso kaputt anders herum. Aua was diesen "Sicherheitsgewinn" betrifft.
Massenrevokt hat man jetzt aber, weil man ein volles Jahr lang verpennt hat, dass ab dem 15. März Zertifikate nur noch maximal für 200 Tage ausgestellt hätten werden dürfen.
Da haben anscheinend viele nicht nur bei D-Trust als Aussteller, sondern auch noch bei BSI, BfDI als überhastete Verwender und eigentlich vorgesehene Überwacher keinerlei Dunst davon was sie überhaupt tun.
Immerhin kann ich Bundeskanzler, Ministerpräsident und Bürgermeister aber weiterhin erreichen um mich darüber zu beschweren. Sie verwenden alle mittlerweile viel billigere und funktionierende Let's Encrypt Zertifikate :)
Das CA-Browserforum hält ein sehr scharfes Schwert in der Hand.
Wenn sie einer gelisteten Root-CA das Vertrauen entzieht ist diese CA praktisch tot – kein Browser erkennt sie mehr an. Beispiele gab es in der Vergangenheit einige.
Ich denke es gab einen Wink mit dem Zaunspfahl, der bei D-Trust ein paar bürokratische Prozesse extrem beschleunigt hat.
Verstehe ich das richtig, es müssen ALLE Zertifikate, die in dem genannten Zeitraum ausgestellt wurden, erneuert werden oder nur die in dem Bug-Report genannten 19 gefundenen Zertifikate?
Wenn ersteres, dann knallt es am Dienstag.
Ich würde die D-Trust-Mitteilung so interpretieren, dass alle TLS-Zertifikate als ungültig erklärt werden, wenn Sie im Zeitraum erstellt wurden.
Was ist mit noch älteren D-Trust-Zertifikaten?
Ich gehe von aus, dass die nicht revoked werden, da die 200 Tagefrist bei Ausstellung noch nicht galt.
Nun ja, sie haben aber scheinbar so gut wie alle zurückgezogen. Das 200 Tage Limit galt ab dem 15.03.2026 – es wurden aber alle Zertifikate ab dem 15.03.2025! zurückgezogen. Davor galt das 398 Tage Limit. Es gibt sicherlich nur eine Handvoll Zertifikate, die vor dem 15.03.2025 ausgestellt wurden, aber noch gültig sind.
Knallt es dann am Dienstag nur im Browser oder auch bei der Gesundheits-Telematik, weiss das jemand?
Die Gematik Meldung dazu.
*https://fachportal.gematik.de/ti-status
05.04.2026 – Widerruf der seit dem 15.03.2025 ausgestellten TLS Zertifikate der D-Trust ab 06.04. 17:00 Uhr!
Die D-Trust wird kurzfristig alle seit dem 15.03.2025 TLS Zertifikate ersetzen und hat im Zuge dessen am vergangenen Donnerstag Nachmittag alle betroffenen Kunden informiert, ihre Zertifikate bis zum 06.04. 17:00 Uhr gegen neue auszutauschen. Ab dann werden die alten Zertifikate von der D-Trust widerrufen.
In den vergangenen zwei Tagen wurden bereits für diverse zentrale Dienste der Telematik Infrastruktur neue TLS Zertifikate angefordert und implementiert (e.g. TLS-Downloadpunkt, PMS, KSR, VZD und FHIR & BDE).
Jeder Anbieter sollte sorgfältig prüfen, inwiefern er von der notwendigen Zertifikatserneuerung betroffen ist, und rechtzeitig Maßnahmen ergreifen.
Links
Kurzfristige Maßnahmen erforderlich: Austausch von TLS-Zertifikaten der D-Trust GmbH
*https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/Austausch_Zertifikate_260404.html
Donnerstag Nachmittag?
Da werden die meisten Leute schon auf dem Weg in die Osterfeiertage gewesen sein.
Und bis Montag sollen die Zertifikate ausgetauscht sein?
Das werden die meisten Leute gar nicht mitbekommen haben und dann Dienstag vor dem Scherbenhaufen sitzen.
Ganz toll gemacht von D-Trust!
Man hätte auch gut bis Dienstag warten können.
> Man hätte auch gut bis Dienstag warten können.
Die Feiertage in Deutschland spielen hier keine Rolle. Im CAB-Forum sind die Baselines für alle Browser und CAs verbindlich. Unabhängig davon, wo auf der Welt man sich befindet.
> Donnerstag Nachmittag?
Eine Information von D-Trust zu den betroffenen Zertifikaten bzw. Kunden wurde bereits vor über zwei Wochen per E-Mail verschickt. Wer über Zwischenhändler bezieht, hat diese Nachricht möglicherweise nicht erhalten.
Die Frage von heute Mittag war: Knallt es Dienstag auch in der TI?
Dazu schrieb die Gematik heute, auch per Mail an die NL-Abonnenten, dass sie die Zertifikate gerade fixt.
So gesehen, sollte ab Dienstag alles laufen. Denn die betroffen Stellen machen bei der Gematik offenbar auch an Ostern ihren Job.
Drücken wir mal die Daumen.
Da werden viele Webseiten offline gehen, denn wer kann denn bis Morgen die Zertifikate tauschen?
Viele Leute sind im Osterurlaub und/oder kommen gar nicht in die Firma rein, weil die wegen des Feiertags geschlossen ist.
"Willkommen im fortschrittlichsten Deutschland 2026!"
Deutschland ≠ Digitalisierung
War es nie, ist es nicht und wird es nie sein!
> "Willkommen im fortschrittlichsten Deutschland 2026!"
Ich weiß nicht, wie du darauf kommst, dass das ein deutsches Problem sein soll. So etwas ist schon fast allen kleinen und großen CAs passiert. Wer mag, kann sich die entsprechenden Reports der letzten fünf Jahre anschauen.
So dämlich ist man nur in Deutschland. Weil potenziell zukünftig Zertifikate knackbar sein könnten, sollen die Pre-Zertifikate ein kurzes Ablaufdatum haben. Soweit sinnvoll. Weil man das verpennt hat, korrigiert man es kurzfristig. Soweit sinnvoll. Aber nur in Deutschland ist man so dämlich, Wegen eines zukünftig möglichen potenziellen Problems durch die Behebungsmassnahme heute (genauer: morgen) schon ein definitives Problem bei sehr vielen Nutzern zu schaffen. Erst schläft man lange, dann übereilter Aktionismus und dabei auch noch einige andere Probleme an Bord.
Sollte jemand einen DOS-Angriff planen: Bitte hier abgucken, wie wir so etwas selbst orchestrieren. Es braucht nur ein kleiner Fehler in die Zertifikatskette eingeschleust zu werden.
Das ist falsch! Die TLS Baseline Requirements des CA Browser Forums gelten selbstverständlich weltweit und die erzwingrn einen Widerruf binnen 5 Tagen
Das Ganze ist ein ziemlich mittelprächtiges Desaster v.a. im Behördenumfeld, wo D-Trust z.B. Let's Encrypt o.a. vorgezogen wurde…
D.h. alle externen Verbindungen die auf SSL/TLS basieren müssen mal kurzfristig durch die Changemanagement-Verfahren laufen – und das sind nicht nur Webseiten, das sind Mailgateways, VPN-Zugänge, EntraID/Azure-Federation (MFA/ADFS) undsoweiter…
Und das innerhalb von 3 Tagen, bei Feiertagen & Urlaub, unterschiedliche Systeme/Teams, … könnte mir aktuell nichts besseres vorstellen…
Da laufen gerade die Cert-Requests heiß…
Und bis die alle von D-Trust abgearbeitet worden sind werden mehrere Wochen vergehen, ich darf leider schon leider seit einer ganzen Weile mit dieser Würstchenbude arbeiten. Wird ein astreines Chaos werden fürchte ich.
Bei D-Trust ist wohl aktuell die Hotline 7/24 besetzt… unsere online Cert-Request (rd. 20 für die Prodsysteme) liefen aber alle gestern ohne sonstige Interaktion sauber durch…
Sollte dann für morgen (bzw. heute ab 17 Uhr) passen… aber müsste ja nicht sein, dass uns D-Trust so ein Ei ins Osternest legt… mann, mann, mann
Etwas kurios – nun ist es Dienstag, die Zertifikate müssten zurückgerufen sein.
Es gibt auch viele (superseeded) Zertifikate die am 05./06.04. neu in die CRL aufgenommen wurden, aber Zertifikate, die eig. in den Zeitraum fallen, die unsererseits nicht getauscht wurden (da nicht kritisch) sind heute dennoch gültig….
http://crl.d-trust.net/crl/d-trust_br_ca_2-23-1_2023.crl
Wenn das nun doch ein April-Scherz war, dann war er *nicht* lustig….
Anscheinend haben schon einige Rücksprache mit dem BSI gehalten.
Source administrator.de:
ACHTUNG – D-Trust – Alle Zertifikate müssen bis Montag getauscht werden!
Zum Thema was nicht geht.
Bei uns geht die Website der Lokalen Volksbank nicht.
Die lokale Hotline behauptet felsenfest das Problem würde nicht bei ihnen liegen. Naja sie sind trotzdem in der Handlungspflicht…
Mals sehn wann das Onlinebanking wieder geht :) wenigstens sind alle Gehälter gezahlt.
Zum Hintergrund, da ich auch betroffen war: D-Trust hat Selbstanzeige beim CAB-Forum gestellt, was der vollkommen richtige Schritt war. Problem war offensichtlich nicht die Gültigkeit von 200 Tagen, denn die ist erst am 15.03.2026 Pflicht, sondern der Linting Prozess, der seit dem 15.03.2025 Pflicht ist (SHALL). Das Linting auf das Zertifikat, das sicher stellt, dass Zertifikate den Forderungen entsprechen, wird auf einem Vorabzertifikat durchgeführt. Dieses wird vor dem eigentlichen Zertifikat erstellt, darf aber nicht mit dem produktiven Issuing CA Key signiert werden, sondern muss mit einem Dummy Key signiert werden. D-Trust hat diese aber mit dem realen CA-Key signiert, und damit verwendbare und gültige Vorabzertifikate erzeugt, bei denen nicht sicher war, ob das Linting durchgeht. D-Trust konnte das auch nicht verbergen, da auch diese Vorab-Zertifikate (precertificates) in einem öffentlich zugänglichen Log hinterlegt werden müssen. Daher war eine Selbstanzeige Pflicht und D-Trust hat fachlich korrekt reagiert. Leider zu einem für die Kunden sehr ungünstigem Zeitpunkt. Die Selbstanzeige war auch etwas unvollständig mit viel Rumgeeier und die CAB-Forum Leute haben übel nachgebohrt. Ich hoffe, dass die Kollegen bei D-Trust da mit einem blauen Auge davon kommen. SSL Zertifikate auszustellen, die dem CAB-Forum Anforderungen genügen, ist kein triviales Geschäft. Ich fühl da mit den Kollegen bei D-Trust.
Edit: Die Sperrung macht auch nur Probleme bei Clients die eine OCSP Prüfung auf das Zertifikat durchführen. Firefox tut das, Chrome nicht. Also Chrome-User merken das gar nicht, wenn noch das gesperrte Zertifikat installiert ist.
Was ich nicht verstehe, dass in einigen Browsern die Webseiten immer noch erreichbar waren. Selbst auf komplett neu installierten Geräte, die vorher noch nie die betroffenen Seiten aufgerufen haben.
Bei Firefox ging es grundsätzlich nicht, da scheint alles korrekt zu laufen. Beim Microsoft können wir die Seiten noch immer aufrufen.
Im CA/Browser Forum sind doch auch die Browser-Hersteller? Müssten die nicht eigentlich auch gesperrte bzw. abgelaufene Zertifikate Zeitah "ungültig machen" oder zumindest eine funktionierende Routine haben?
Wieso werden Webseiten (auf neuen Geräten) noch als sicher angezeigt, wenn das Zertifikat letzte Woche zurückgezogen wurde und eigentlich ab Montag "tot" hätte sein müssen? Wie ist es den, wenn es wirklich mal ein Sicherheitsproblem mit dem Zertifikat gibt? Da gilt die Frist von 5 Tagen doch nicht, dann müssten es die Browser aber auch "zeitnah" raffen?
[Altbewährtes Prinzip: No risk -> no fun!]
OCSP-/CRL-Prüfungen sind in Microsoft Edge/Google Chrome per Voreinstellung deaktiviert, weil kürzeren Ladezeiten gegenüber einem möglichen Sicherheitgewinn ein höherer Wert beigemessen wird, und müssten folglich für eine Wirksamkeit erst aktiviert werden:
learn.microsoft.com/en-us/deployedge/microsoft-edge-browser-policies/enableonlinerevocationchecks
chromeenterprise.google/policies/enable-online-revocation-checks/
Ja, hier zeigt sich das im CA/Browser Forum zwar beide Seiten vertreten sind, aber die "Macht" effektiv nur auf einer Seite liegt, da die Browser CAs rauswerfen können, aber umgekehrt keine direkte Sanktionsmöglichkeit besteht (die CAs sind ja immer daran interessiert, dass ihre Zertifikate von allen genutzt werden können).
Dazu kommt noch das alle im Forum vertretenen Browserhersteller in den USA beheimatet sind, was eine weitere gewisse Abhängigkeit bzw. Einflussnahme möglich macht (Herr Trump lässt grüßen).