DNSSEC-Schlüsseltausch: Secunet- und RISE-Konnektoren verlieren TI-Verbindung

Seit Montag haben etliche Arztpraxen, Apotheken und Kliniken Probleme mit der Telematikinfrastruktur (TI). Nach bisherigem Stand betrifft das Einrichtungen, die mit einem Konnektor von Secunet oder RISE angebunden sind. Die Gematik meldet Störungen bei der Verbindung zur TI. Das gilt für Leistungserbringer, die über die VPN-Zugangsdienste von Arvato und T-Systems angeschlossen sind. Bei ihnen funktionieren diese Dienste derzeit nicht oder nur eingeschränkt: das Versichertenstammdatenmanagement (VSDM), KIM (Kommunikation im Medizinwesen), das E-Rezept, die elektronische Patientenakte (ePA) und die elektronische Arbeitsunfähigkeitsbescheinigung (eAU).

Ohne Korrektur dürften nach aktuellem Kenntnisstand im Laufe der Woche alle Secunet- und RISE-Konnektoren im Feld betroffen sein. Konnektoren anderer Hersteller nennt die Gematik bisher nicht. Die Störung könnte aber auch Einrichtungen ohne eigenen Konnektor treffen, etwa wenn sie über einen Konnektor im Rechenzentrum angebunden sind.

Ursache: Wechsel des Root-KSK

Auslöser ist der angekündigte Wechsel des obersten Schlüssels der DNSSEC-Vertrauenskette, des sogenannten Root-KSK (Key Signing Key). Laut Zeitplan der IANA signiert seit dem 11. Oktober 2026 der neue Root-Schlüssel KSK-2024 mit dem Key Tag 38696 den DNSKEY-Datensatz der Root. Der bisherige Schlüssel KSK-2017 (Key Tag 20326) tut das nicht mehr. Verisign hatte darauf hingewiesen, dass DNSSEC-validierende Resolver ohne KSK-2024 als Trust Anchor ab diesem Datum keine Namen mehr auflösen können. Bei den betroffenen Konnektoren fehlt anscheinend dieser neue Internet-Root-Vertrauensanker. Sie können deshalb die Adressen der VPN-Zugangsdienste nicht auflösen und bauen keinen neuen Tunnel zur TI auf.

Dass nicht alle Geräte sofort ausgefallen sind, hat zwei Gründe. Bestehende VPN-Tunnel brauchen keine neue Namensauflösung. Konnektoren mit aktiver Verbindung arbeiten also vorerst weiter. Außerdem hilft das Caching. Die DNSKEY-Einträge der Root haben eine TTL von 48 Stunden. Solange ein Resolver die alten, schon geprüften Schlüssel im Cache hat, funktioniert die Namensauflösung weiter. Nach einem Neustart ist der Cache leer, bei einer regulären Neuverbindung kann er abgelaufen sein. In beiden Fällen kann der Konnektor keinen Tunnel mehr aufbauen.

Betroffene Konnektoren sollen deshalb nicht einfach neu gestartet werden. Ohne vorherige Korrektur führt ein Neustart wahrscheinlich zum Verlust der TI-Verbindung. Laut Gematik gibt es einen Workaround. Den muss der jeweilige Dienstleister vor Ort (DvO), also der technische Support der Einrichtung, von Hand einspielen.

Für Secunet-Konnektoren steht im Fachportal der Gematik eine Anleitung.

Empfohlen wird, den neuen Trust Anchor vorsorglich auch auf Konnektoren einzuspielen, die noch normal laufen. Wer den XML-Block aus dem PDF kopiert, sollte genau hinsehen. In einem Fachforum weisen Admins darauf hin, dass zusätzliche Leerzeilen beim Kopieren zu Fehlern führen können. Einrichtungen mit Verbindungsproblemen sollen sich an ihren DvO wenden. DvO sollen Auffälligkeiten mit Angabe von Einrichtung, Konnektortyp und Firmware-Version über die bekannten Supportkanäle melden.

Für RISE-Konnektoren gibt es noch keine eigene Anleitung. Die veröffentlichte Anleitung beruht auf dem Workaround, der für Secunet-Geräte bestätigt ist. Bei einzelnen RISE-Konnektoren können andere Schritte nötig sein. Hinweise dazu will die Gematik in Kürze veröffentlichen. Bis dahin sollen sich Einrichtungen an ihren DvO oder den Hersteller-Support wenden. Die Hersteller arbeiten an einer automatischen Lösung. Laut Ankündigung sollte RISE ab dem 8. Oktober die Firmware 6.2.3 mit einer „wichtigen Korrekturmaßnahme“ über das Konfigurations- und Software-Repository (KSR) bereitstellen. Ob sie das DNSSEC-Problem behebt, ist nicht bekannt.

Warum die Konnektoren den neuen Schlüssel nicht übernommen haben, ist noch nicht geklärt. Für den Vertrauensanker des TI-eigenen Namensraums schreibt die Netz-Spezifikation der Gematik (gemSpec_Net) vor, dass er automatisch nach RFC 5011 aktualisiert wird. Für den Internet-Vertrauensanker, den die Konnektoren für die Verbindung zu den VPN-Zugangsdiensten brauchen, enthält die Spezifikation eine eigene Anforderung. Ob auch dort ein automatisches Update vorgesehen ist, ist bislang unklar. Resolver, die nach RFC 5011 arbeiten, übernehmen einen neuen Root-Schlüssel selbstständig, nachdem er eine Zeit lang in der Root-Zone veröffentlicht ist.

Der Schlüsselwechsel war seit Längerem angekündigt. Der neue Schlüssel steht seit dem 11. Januar 2025 in der Root-Zone. ICANN hatte Administratoren empfohlen, ihre Konfiguration von Hand zu prüfen.

Ähnliche DNSSEC-Störungen

Bereits 2020 hatte c’t darauf hingewiesen, dass den Konnektoren offenbar eine Rollback-Strategie für solche Fälle fehle. Mit der TI 2.0 und einer souveränen und redundanten Open-Source-Plattform soll sich das aber ändern. Ende Mai 2020 konnten rund 80.000 der damals etwa 130.000 angeschlossenen Praxen und Kliniken bestimmte TI-Dienste nicht mehr erreichen. Betroffen waren Konnektoren von T-Systems, RISE und Secunet. Die Gematik nannte als Ursache einen falschen Eintrag in der Trust-Service Status List (TSL). Eine Analyse der c’t ergab damals, dass im Mai 2020 ein neuer DNSSEC-Root-Trust-Anchor gesetzt worden war. Zusammen mit einem Fehler bei der Administration dürfte das laut c’t die Störung ausgelöst haben. Damals ging es um den Trust Anchor für die Namensauflösung innerhalb der TI, den die Gematik über die TSL verteilt. Diesmal geht es um den des Internets.

CGM nicht betroffen

Von den KoCoBoxen von CGM war 2020 laut Hersteller nur ein Prozent betroffen. Das Unternehmen sprach damals von einer „robusten Implementierung“. Die c’t kam später zu einer anderen Erklärung, dass DNSSEC bei der KoCoBox optional und bei 99 Prozent der Geräte nicht aktiviert war. Ohne DNSSEC waren die Geräte allerdings anfälliger für Angriffe im Bereich des Routings. CGM widersprach dieser Darstellung und erklärte, die KoCoBox führe stets eine DNSSEC-Validierung durch.

Auch die Behebung lief 2020 ähnlich ab. Weil die Konnektoren offline waren, konnten sie die korrigierte TSL nicht automatisch laden. Die DvO mussten das Update vor Ort einspielen, da Fernwartung oft nicht freigegeben war. Mitte Juni 2020 war der Stammdatenabgleich laut Gematik bei mehr als 40.000 Praxen noch gestört. c’t berichtete außerdem, dass Unstimmigkeiten zwischen Gematik und Dienstleistern die Reparatur verzögerten. Viele DvO waren nicht bereit, einen Fehler zu beheben, den sie nicht zu verantworten hatten. Auch zum Start der E-Rezept-Pflicht Anfang 2024 gab es Störungen, bei der die Ursache vermutlich ebenfalls auf einem Problem mit DNSSEC zurückzuführen war.