|
13.10.2026
07:23 Uhr
|
Secunet- und RISE-Konnektoren verlieren nach einem DNSSEC-Schlüsselwechsel die Verbindung zur Telematikinfrastruktur. Jetzt stehen Updates bereit.
Seit Montag haben etliche Arztpraxen, Apotheken und Kliniken Probleme mit der Telematikinfrastruktur (TI). Das betrifft 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. Inzwischen stehen Updates für RISE und Secunet bereit. Das Update für RISE-Konnektoren wurde nach Angaben des Unternehmens um 8:50 Uhr von der Gematik freigegeben.
Die Gematik informiert auf ihren Kanälen zum Update und empfiehlt das Einspielen der Updates, damit die Konnektoren über die aktuelle Firmware-Version verfügen – auch wenn sie bereits den „manuellen Workaround durchlaufen haben“. Wer keine automatischen Updates erhält, sollte seinen Dienstleister vor Ort (DvO) informieren. „Einrichtungen, die die ‚Auto-Update-Funktion‘ ihres Konnektors aktiviert haben, sollten abhängig vom konfigurierten Wochentag für das Auto-Update ebenfalls tätig werden. Einrichtungen sollten sich daher am besten an ihren DvO wenden, wenn der selbst gewählte Installationstag für Updates nicht auf heute/Mittwoch fällt“, heißt es von der Gematik. Das Update sollte schnellstmöglich installiert werden.
Konnektoren von CGM sind laut Gematik nicht betroffen, weil CGM „dieses Feature nicht nutzt“. Ohne Korrektur dürften im Laufe der Woche alle Secunet- und RISE-Konnektoren im Feld betroffen sein. Die Störung könnte aber auch Einrichtungen ohne eigenen Konnektor treffen, etwa wenn sie über einen Konnektor im Rechenzentrum angebunden sind. Wie viele Konnektoren betroffen sind, kann die Gematik wegen der dynamischen Entwicklung nach eigenen Angaben derzeit nicht verlässlich sagen.
Die Gematik nennt als Ursache eine „Anpassung einer zentralen Internet-Komponente (DNSSEC)“ seit dem 11. Oktober. 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.
Ein Leser wies zudem auf auffällige Parallelen mit einem Fehler bei der DNSSEC-Validierung mit DNSKEY-Vertrauensankern hin. Im systemd-Projekt wurde am 12. Oktober einen Workaround veröffentlicht. Einen Zusammenhang hat die Gematik inzwischen bestätigt.
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.
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). Die 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.
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. So konfiguriert seien die Geräte allerdings anfälliger für Angriffe im Bereich des Routings, schrieb die c't. 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.
Ergänzt, dass es auffällige Parallelen zu einem Bug in systemd-resolved gibt.
Antworten der Gematik, Secunet und von RISE ergänzt.
(mack)