PKI / Zertifikate

Austausch zehntausender TLS- und S/MIME-Zertifikate bei D-Trust und SwissSign

D-Trust hat im April 2026 zehntausende TLS-Zertifikate wegen formaler Verstöße gegen die Baseline Requirements ausgetauscht; SwissSign hat einen vergleichbaren S/MIME-Widerruf zum 22. April 2026 angekündigt.

Yannic Röcken

21 Apr. 2026 — 11 Min. Lesezeit

Photo by Peter Conrad / Unsplash

Kurz vor und über Ostern 2026 haben zwei große europäische Certificate Authorities in rascher Folge Massenwiderrufe angekündigt. D-Trust, Tochter der Bundesdruckerei, zog bis Ostermontag, 6. April 2026, 17:00 Uhr 57.565 TLS-Zertifikate aus dem Verkehr. [1] Kurz darauf zog die Schweizer SwissSign nach und kündigte für den 22. April 2026 um 15:00 Uhr MESZ (13:00 UTC) den Widerruf aller Zertifikate vom Typ "Personal S/MIME E-Mail ID Silver" an, die seit Juli 2025 ausgestellt worden sind. Der Stichtag steht zu Redaktionsschluss noch aus. [5] Beide CAs sprechen von formalen Konformitätsverstößen, nicht von kompromittierten Schlüsseln oder Fehlausstellungen. Hinter beiden Vorgängen steht eine Reihe neuer Regeln des CA/Browser Forums, die seit August 2024 stufenweise greifen und zuletzt im März 2026 scharfgeschaltet wurden.

Zeitlicher Ablauf

D-Trust schickte seine Benachrichtigung am Gründonnerstag, 2. April 2026, per E-Mail an die Kunden. Austauschen musste wer ein Zertifikat hatte, das zwischen dem 15. März 2025 und dem 2. April 2026, 10:45 Uhr MESZ (08:45 UTC) ausgestellt worden war. Frist: Ostermontag, 6. April 2026, 17:00 Uhr. Was dann noch nicht ersetzt war, revozierte D-Trust aktiv. [2]

Das BSI reagierte noch am selben Tag mit einer Pressemeldung und rief "alle Kunden der D-Trust GmbH dazu auf, schnellstmöglich neue Zertifikate für alle Dienste zu beantragen". [1] Betroffen waren nicht nur Websites, sondern jeder Dienst, der auf einem D-Trust-TLS-Zertifikat beruht: MDM-Anbindungen, Mail-Gateways, VPN-Endpunkte, interne Authentifizierung und vieles mehr. [4]

Zwei Wochen später folgte SwissSign mit einem ähnlichen Schritt. Die E-Mail-Zertifikate vom Typ "SwissSign Personal S/MIME E-Mail ID Silver", ausgestellt zwischen dem 15. Juli 2025, 00:00 UTC und dem 17. April 2026, werden am 22. April 2026 um 15:00 Uhr MESZ (13:00 UTC) widerrufen. [5] Auch hier geht es nicht um kompromittierte Kryptografie, sondern um einen Formverstoß gegen die Baseline Requirements. Die dahinterliegenden Ballots im CA/Browser Forum wurden zwischen 2024 und 2025 beschlossen.

Der D-Trust-Vorfall im Detail

Erster Befund: 19 Precertificates mit 203 Tagen Laufzeit

Den Anfang markiert der 15. März 2026, 11:34 UTC. An diesem Tag greift eine neue Vorgabe des CA/Browser Forums: Neu ausgestellte TLS-Zertifikate dürfen nur noch maximal 200 Tage gelten (Ballot SC-081v3, siehe unten). [9] Wie andere CAs lässt D-Trust jedes neu signierte Precertificate automatisch von ZLint und PKILint auf Baseline-Konformität prüfen. Kurz nach 11:34 UTC schlugen diese Tools an: 19 Precertificates vom Produkttyp TLS OV waren mit einer Laufzeit von 203 Tagen in die Certificate-Transparency-Logs gewandert. [6]

Die Ursache steckte in einer internen Dauerberechnung, die D-Trust im Bug-Report "Trio-Logik" nennt und die seit 2014 im Einsatz ist. Sie zerlegt Laufzeiten in Jahre, Monate und Tage, gerechnet relativ zum 1. Januar 1970. Im Zusammenspiel mit den Monatslängen des März kamen bei der neuen 200-Tage-Grenze drei Tage zu viel heraus. Sicherheitsrelevant war das nicht. Formal aber ein Verstoß: Precertificates dürfen die maximale Laufzeit nicht überschreiten. [6]

D-Trust reagierte binnen Stunden. Um 14:10 UTC stand die Notfall-Konfigurationsänderung, die weitere Fehlausstellungen verhinderte. Um 16:34 UTC waren alle 19 Precertificates widerrufen. Bis 21:45 UTC hatte das Unternehmen den Issuance-Pfad dauerhaft umgebaut. Ein Detail aus dem Bug-Report ist bemerkenswert: Die fehlerhaften Precertificates landeten zwar in den CT-Logs, zu final ausgelieferten Endkunden-Zertifikaten führten sie aber nicht. Das automatisierte Linting mit ZLint und PKILint entdeckte den Fehler in genau dem Zeitfenster zwischen Precertificate-Signatur, CT-Submission und der Ausstellung des finalen Zertifikats. Dokumentiert ist der Vorgang in Mozillas Bugzilla als Bug 2023458. [6]

Zweiter Befund: fehlendes Pre-Signing Linting

Bei der Aufarbeitung des ersten Befunds fiel ein zweiter, viel größerer auf. D-Trust räumte öffentlich ein, dass die bisher eingesetzten, intern entwickelten RA- und CA-seitigen Prüfungen nicht der Vorgabe aus Section 4.3.1.2 der TLS Baseline Requirements entsprachen. Diese Regelung ist seit dem 15. März 2025 verbindlich. [8] Sie fordert eine "independent, programmatic validation using widely adopted industry linting tools" ("SHALL"). Zuvor war dieselbe Anforderung zunächst als "MAY" (ab 6. August 2024) und dann als "SHOULD" (ab 15. September 2024) in Kraft. [7]

Die interne Risikoeinschätzung von D-Trust hatte die vorhandenen Prüfungen für ausreichend gehalten. Im Bug-Report heißt es nun, sie "lack the programmatic independence and technical rigor of a dedicated linting library". [7] Die Prüfungen liefen also, aber nicht unabhängig und nicht gegen die etablierten Bibliotheken ZLint und PKILint. Für das CA/Browser Forum und die angeschlossenen Root-Store-Programme ist das ein klarer Verstoß gegen eine verbindliche Regel, inklusive Revocation-Pflicht.

Am 2. April 2026 rollte D-Trust die geforderten Linting-Tools aus und nahm die Zertifikatsausstellung mit korrekter Validierung wieder auf. Alle zwischen dem 15. März 2025 und dem 2. April 2026 ausgestellten Zertifikate gelten seitdem als formal fehlerhaft, auch wenn sie inhaltlich sauber sind. Die Bilanz: 57.565 TLS-Zertifikate, verteilt über alle drei Validierungsstufen DV (Domain Validation), OV (Organization Validation) und EV (Extended Validation). Dokumentiert ist dieser größere Vorgang in Mozillas Bugzilla als Bug 2029013. [7]

Einordnung der 5-Tage-Frist

Warum die Deadline ausgerechnet am Ostermontag lag, steckt in Section 4.9.1.1 der Baseline Requirements. Dort sind zwei Fristen definiert: 24 Stunden bei kompromittierten Schlüsseln oder besonders schweren Regelverstößen, fünf Tage bei allen anderen Verstößen gegen die BR oder die CA-eigene Certificate Policy. [8] D-Trust machte den Fall am 2. April öffentlich; die Revocation musste bis spätestens 7. April abgeschlossen sein. Ostermontag, 17:00 Uhr, war damit das letzte Zeitfenster, das den Kunden überhaupt noch eine realistische Chance auf den Austausch ließ.

Hinter dieser Frist steht eine harte Konsequenz: Die Root-Store-Programme von Mozilla, Microsoft, Google und Apple setzen die Einhaltung der Baseline Requirements voraus. Wiederholte oder schwere Verstöße können im Extremfall dazu führen, dass eine komplette CA aus den Root-Stores fliegt. In den letzten Jahren ist das mehrfach passiert: Symantec flog mit Chrome 66 und Chrome 70 aus dem Browser [14], TrustCor wurde im November 2022 von Mozilla und Microsoft entfernt, Anfang 2023 zog Chrome 111 nach [15], und bei Entrust strichen Chrome (ab 11.11.2024) und Mozilla (ab 30.11.2024) nach einer mehrjährigen Incident-Kette die Reißleine [16]. Wer die Revocation-Fristen reißt, setzt den eigenen Status als öffentlich vertrauenswürdige CA aufs Spiel.

Wer war betroffen?

Die Liste der betroffenen Organisationen fiel entsprechend lang aus. D-Trust ist als Tochter der Bundesdruckerei Stammlieferant großer Teile der deutschen öffentlichen Verwaltung. Öffentlich bestätigt sind bislang unter anderem:

die Bundesverwaltung inklusive des ITZBund (zentraler IT-Dienstleister der Bundesverwaltung), das in einer eigenen Pressemitteilung vom 6. April 2026 Stellung nahm, [23]
das BSI selbst, das laut Berichten während des Austauschs Probleme beim Zugriff auf eigene Dienste mit D-Trust-Zertifikaten hatte, [4]
Dataport mit rund 1.000 betroffenen Zertifikaten; Dataport ist IT-Dienstleister unter anderem für Hamburg, Schleswig-Holstein, Bremen, Sachsen-Anhalt und den Kreis Dithmarschen, [11]
privatwirtschaftliche D-Trust-Kunden mit öffentlichen TLS-Flotten.

In der Folge meldeten mehrere Häuser temporäre Ausfälle ihrer Webservices, nicht erreichbare Behördenportale und Verzögerungen bei VPN-Einwahl und Mail-Gateways. Dass Kunden und Dienstleister zusätzlich über Performance-Probleme am D-Trust-Portal berichteten, überraschte angesichts der Kombination aus kurzer Frist, Osterwochenende und hohem Ausstellungsvolumen wenig. [3]

Wichtig ist die Abgrenzung zum parallel laufenden eHBA-Austausch im Gesundheitswesen. Bis zum 30. Juni 2026 müssen alle elektronischen Heilberufsausweise mit Idemia-Chips der Generation 2.0 erneuert werden. Das ist eine eigene D-Trust-Aktion, die mit sicherheitsrelevanten Erkenntnissen am Kartenchip begründet wird, und keine Folge des TLS-Vorfalls. Beide Vorgänge fallen zeitlich zusammen und treffen teils denselben Personenkreis: Ärztinnen, Ärzte, Psychotherapeutinnen und Psychotherapeuten. [12]

Paralleler Vorgang bei SwissSign: S/MIME Silver

Wenige Tage nach dem D-Trust-Austausch kündigte SwissSign einen vergleichbaren Schritt für den S/MIME-Bereich an. Betroffen sind ausschließlich Zertifikate vom Typ "SwissSign Personal S/MIME E-Mail ID Silver", die DV-Variante der persönlichen E-Mail-Zertifikate, ausgestellt zwischen dem 15. Juli 2025 um 00:00 UTC und dem 17. April 2026. [5]

Der Widerruf ist für den 22. April 2026, 15:00 Uhr MESZ (13:00 UTC) angekündigt und steht zum Zeitpunkt dieses Beitrags (20. April 2026) noch aus. Bis dahin haben Kunden Zeit, ihre Zertifikate durch neu ausgestellte zu ersetzen. Was bis dahin nicht ausgetauscht ist, revoziert SwissSign anschließend. Als Grund nennt die CA einen Formfehler ohne Auswirkung auf die kryptografische Sicherheit. Seit 2023 werden die S/MIME Baseline Requirements der CA/Browser-Forum-Arbeitsgruppe separat gepflegt; auch sie sehen bei formalen Verstößen eine Revocation vor. [5]

Wer seine Zertifikate über Managed-PKI oder ähnliche automatisierte Wege bezieht, soll den Austausch laut SwissSign kaum bemerken. SEPPmail hat seine Kunden informiert, dass SEPPmail-Appliances und seppmail.cloud den Rollover eigenständig abwickeln. Lastspitzen am SwissSign-Portal und am MPKI-Connector schließt der Hersteller allerdings nicht aus. [5]

Speziell für SEPPmail-Betreiber empfiehlt der Hersteller in einer Korrekturmeldung, bis spätestens 22. April 2026, 15:00 Uhr MESZ die Einstellung "Automatically renew expiring certificates if validity days left less than" im MPKI-Setup zu aktivieren und den Schwellwert für die Restlaufzeit auf 362 Tage zu setzen. So kann der nächtlich laufende Auto-Renewal-Job alle zum Widerruf markierten Zertifikate rechtzeitig erneuern, ohne Unterbrechung der Zertifikatsdienste. Wer diese Anpassung nicht bereits vor Dienstag, 21. April 2026, 21:00 Uhr vorgenommen hat, sollte zusätzlich "Automatically create certificates for active users without certificates" aktivieren, damit der Job auch die bereits revozierten SwissSign-Zertifikate neu ausstellen kann. Ab dem 23. April 2026 lassen sich die Einstellungen wieder auf die ursprünglichen Werte zurücksetzen. Betroffen sind SEPPmail-Appliances sowie die Licence- und Update-Services. [10]

Für manuell gepflegte S/MIME-Flotten bleibt der übliche Aufwand: Client-Zertifikat neu ausrollen, Directory-Einträge aktualisieren, Funktionspostfächer und interne Schlüsselablagen abgleichen.

Hintergrund: Das CA/Browser Forum und seine Ballots

Beide Fälle ergeben erst Sinn, wenn man das Regelwerk dahinter kennt. Das CA/Browser Forum ist ein Industriegremium, in dem sich öffentlich vertrauenswürdige Certificate Authorities und die Betreiber der Root-Store-Programme von Mozilla, Microsoft, Apple, Google, Opera und weiteren auf technische Mindestanforderungen für die Ausstellung und Verwaltung von Zertifikaten einigen. Das zentrale Regelwerk für TLS heißt Baseline Requirements (BR). Aktuell gilt Version 2.2.6 vom 31. März 2026, beschlossen durch Ballot SC-095v3 "Clean-up 2025". Für S/MIME gibt es seit 2023 ein separates Pendant. [8] Formal sind die BR keine Gesetze. Praktisch schon: Wer sie verletzt, riskiert den Ausschluss aus den großen Root-Stores und damit das Vertrauen der Browser in alle ausgelieferten Zertifikate. Dann erscheinen Zertifikatswarnungen, Mail-Clients verweigern die Verschlüsselung, und die CA verliert faktisch ihren Markt.

Ballot SC-075: Pre-Sign Linting als Pflicht

Die Linting-Pflicht kam über Ballot SC-075 und wurde in drei Stufen scharfgeschaltet: zuerst als optionales "MAY" ab 6. August 2024, dann als empfehlendes "SHOULD" ab 15. September 2024 und schließlich als zwingendes "SHALL" ab 15. März 2025. [7] Gemeint ist damit explizit unabhängiges, programmatisches Linting mit etablierten Open-Source-Werkzeugen. Wichtigste Vertreter: ZLint [17] aus dem ZMap-Projekt der University of Michigan (Apache-2.0, im produktiven Einsatz bei Let's Encrypt, DigiCert, Sectigo/crt.sh, GlobalSign und GoDaddy) sowie PKILint [18] von DigiCert (MIT-Lizenz, ursprünglich ein "20-%-Projekt" von DigiCert-Ingenieur Corey Bonnell). Beide prüfen ein Zertifikat gegen ein breites Regelwerk aus RFC 5280, RFC 6962, Mozilla-Policies, Browser-Anforderungen und CA/Browser-Forum-Profilen. Typischerweise laufen sie zweimal: einmal vor der Signatur (Pre-Sign, gegen das "to-be-signed-Object") und einmal danach (Post-Sign). Seit SC-075 reichen interne Eigenbau-Checks nicht mehr aus. Wer nicht gegen die etablierten Linter-Bibliotheken prüft, verletzt seit März 2025 eine MUSS-Regel.

Ballot SC-081v3: Kürzere Laufzeiten

Parallel drückt das CA/Browser Forum die Gültigkeit öffentlicher TLS-Zertifikate deutlich nach unten. Der aktuelle Ballot SC-081v3 wurde vom 4. bis 11. April 2025 abgestimmt. Eingebracht hat ihn Clint Wilson von Apple, unterstützt von Sectigo, Google Chrome und Mozilla. Der Ballot definiert einen klaren Stufenplan, an dessen Ende 2029 eine maximale Zertifikatslaufzeit von 47 Tagen steht. [9]

Balkendiagramm zu Ballot SC-081v3: proportionale Darstellung der maximalen TLS-Zertifikatslaufzeit und maximalen DCV-Reuse-Periode je Stufe; bis 14.03.2026 je 398 Tage, ab 15.03.2026 je 200 Tage, ab 15.03.2027 je 100 Tage, ab 15.03.2029 Laufzeit 47 Tage und DCV-Reuse nur 10 Tage

Die Werte stammen aus dem veröffentlichten Ballot-Text und aus Industrie-Zusammenfassungen zur SC-081v3-Roadmap; eine Zwischenstufe für 2028 ist öffentlich nicht dokumentiert. [13] Treiber der Entwicklung sind Apple und Google. Beide argumentieren mit dem gleichen Dreiklang: Kurze Laufzeiten schrumpfen das Zeitfenster für Angreifer bei kompromittierten Schlüsseln, die ohnehin schwache Revocation-Infrastruktur aus CRL und OCSP wird entlastet, und Automatisierung via ACME wird faktisch zur Pflicht. Für Zertifikatskunden heißt das: Was bisher alle gut 13 Monate im Kalender stand, kommt ab 2029 rund alle sieben Wochen. Die darunterliegende Domain-Validierung läuft dann sogar nur noch zehn Tage. Händisch ist das kaum zu stemmen.

Precertificates und Certificate Transparency

Dass die D-Trust-Vorfälle überhaupt öffentlich wurden, hat einen Namen: Certificate Transparency. Jede CA schreibt ein geplant auszustellendes Zertifikat zuerst als Precertificate (RFC 6962) in öffentlich lesbare CT-Logs. Der Grund liegt bei den Browsern. Chrome akzeptiert seit Version 68 (Juli 2018) TLS-Zertifikate, die nach dem 30. April 2018 ausgestellt wurden, nur mit ausreichend Signed Certificate Timestamps (SCTs) aus öffentlichen CT-Logs. [19] Apple zog am 15. Oktober 2018 plattformweit für macOS und iOS nach. [20] Mozilla Firefox hingegen schaltete CT-Enforcement erst im Februar 2025 mit Version 135 auf Desktop scharf. Die CT-Logs sind damit eine öffentliche, in Echtzeit durchsuchbare Datenquelle. Forschende, andere CAs und Browser-Hersteller entdecken Regelverstöße darüber oft schneller als die ausstellende CA selbst. Dokumentiert werden die Vorfälle dann typischerweise in Mozillas Bugzilla, im D-Trust-Fall unter den Nummern 2023458 und 2029013.

Der Trend dahinter: Das Zeitalter kurzlebiger Zertifikate

Ein Blick zurück zeigt die Richtung, in die das CA/Browser Forum die vergangenen zehn Jahre gelaufen ist:

vor April 2015: keine zentrale CA/B-Forum-Obergrenze; in der Praxis waren Zertifikate mit bis zu fünf Jahren Laufzeit üblich,
ab April 2015: 39 Monate (CA/B-Forum Baseline Requirements),
ab März 2018: 825 Tage (rund 27 Monate, Ballot 193), [21]
ab September 2020: 398 Tage (Apple setzte diese Grenze zunächst unilateral für Safari/macOS/iOS durch; Chrome und Mozilla folgten), [22]
ab März 2026: 200 Tage (Ballot SC-081v3), [9]
ab März 2027 (geplant): 100 Tage, [13]
ab März 2029 (geplant): 47 Tage. [13]

Mit jeder Stufe verschiebt sich das Gleichgewicht weiter Richtung Automatisierung. Mehrjährige Zertifikate waren 2020 mit dem Sprung auf 398 Tage Geschichte. Bei 200 Tagen (2026) wird die manuelle Bestellroutine in mittleren Zertifikatsflotten zäh. Bei 47 Tagen (2029) ist der Betrieb einer öffentlich vertrauenswürdigen CA-Beziehung ohne ACME, EST oder ein vergleichbares Lifecycle-Protokoll kaum noch praxistauglich.

Die beiden D-Trust-Vorfälle zeigen außerdem, wo kürzere Laufzeiten Nebenwirkungen haben. Kalendarische Spezialfälle wie Monatslängen, Schaltjahre und Zeitzonengrenzen werden zu echten Fehlerquellen, sobald Dauerberechnungen im Bereich weniger Hundert Tage arbeiten. Wer seine Ausstellungslogik nicht auf absolute Zeiteinheiten umstellt und die Zertifikatsprofile formal prüft, trägt auch in Zukunft ein Risiko.