Montagmorgen in deutschen Praxen und Apotheken
Seit Montag, dem 12. Oktober, haben viele Arztpraxen, Apotheken und Kliniken in Deutschland Probleme, die Telematikinfrastruktur zu erreichen, das nationale Gesundheitsnetz, und die Gematik meldet Störungen bei Anbietern, deren Konnektoren von Secunet oder RISE stammen. Ausfälle oder Teilausfälle gibt es beim Versichertenstammdaten-Abgleich (VSDM), beim sicheren Nachrichtendienst (KIM), bei E-Rezepten, bei der elektronischen Patientenakte und bei elektronischen Krankschreibungen.
Konnektoren von CGM sind laut Gematik nicht betroffen, weil CGM die fragliche Funktion nicht nutzt. Ursache ist der planmäßige Wechsel des DNS-Root-Schlüssels.
Die Gematik rechnet damit, dass im Laufe der Woche alle Secunet- und RISE-Konnektoren im Feld betroffen sind, wenn es keine Korrektur gibt, und Einrichtungen ohne eigenen Konnektor können getroffen werden, wenn sie über einen Rechenzentrumskonnektor angebunden sind. Wie viele Konnektoren betroffen sind, kann die Gematik noch nicht sagen.
Ein Kalender, der 21 Monate öffentlich war
Der Schlüsselwechsel stand 21 Monate lang im öffentlichen Kalender, und der erste Werktag danach brachte trotzdem einen Ausfall.
| Datum | Ereignis |
|---|---|
| 11. Januar 2025 | Der neue Root-Schlüssel KSK-2024 (Key Tag 38696) wird im DNSKEY-Satz der Root-Zone veröffentlicht |
| 11. August 2026 | ICANN veröffentlicht Hinweise, was beim Wechsel zu erwarten ist |
| 6. Oktober 2026 | Cloudflare warnt, dass validierende Resolver dem neuen Schlüssel vertrauen müssen |
| 11. Oktober 2026 | KSK-2024 beginnt, den DNSKEY-Satz der Root-Zone zu signieren, KSK-2017 (Key Tag 20326) hört auf |
| 12. Oktober 2026 | Die Gematik meldet Störungen bei Secunet- und RISE-Konnektoren |
| 13. Oktober 2026 | heise aktualisiert seinen Bericht um Antworten der Gematik |
Die Hinweise der ICANN baten Betreiber DNSSEC-validierender Resolver, DNS-Softwarehersteller und alle mit manuell konfigurierten Vertrauensankern, vor dem 11. Oktober zu bestätigen, dass ihre Systeme bereit sind. Cloudflare ergänzte, dass ein validierender Resolver, der dem neuen Schlüssel nicht vertraut, gesunde Websites unerreichbar machen kann und dass die Root-Zone ihren Key-Signing-Key erst einmal zuvor gewechselt hatte.
Warum bestehende Tunnel überlebten und neue scheitern
Den betroffenen Konnektoren fehlt offenbar der neue Internet-Root-Vertrauensanker, sodass sie die Adressen der VPN-Zugangsdienste von Arvato und T-Systems nicht auflösen und keinen neuen Tunnel ins Gesundheitsnetz aufbauen können.
Bereits aufgebaute Tunnel brauchen keine neuen Namensabfragen und laufen deshalb weiter. Die DNSKEY-Einträge der Root-Zone bleiben zudem 48 Stunden im Cache, was den Fehler bis zu einem Neustart oder Reconnect verbirgt, der einen leeren oder abgelaufenen Cache vorfindet. Deshalb berichtet heise, dass betroffene Betreiber ihre Konnektoren nicht neu starten sollten.
Die Gematik beschreibt eine Umgehung, die der Dienstleister vor Ort von Hand einspielen muss, und ihre Anleitung für Secunet-Konnektoren empfiehlt, den neuen Vertrauensanker auch bei noch funktionierenden Konnektoren vorsorglich einzutragen. Für RISE gibt es noch keine eigene Anleitung, und RISE kündigte ab dem 8. Oktober die Firmware 6.2.3 mit einer von ihm als wichtig bezeichneten Korrektur an, ob sie diesen Fehler behebt, ist unbekannt. Warum die Konnektoren den neuen Schlüssel nicht übernahmen, ist weiter unklar: Die Spezifikation verlangt automatische RFC-5011-Updates für den eigenen Anker des Gesundheitsnetzes, aber nicht erkennbar für den Internet-Anker.
Der Präzedenzfall vom Mai 2020
Ende Mai 2020 konnten rund 80.000 von etwa 130.000 angeschlossenen Praxen und Kliniken einige Dienste des Gesundheitsnetzes nicht erreichen, und die betroffenen Konnektoren stammten von T-Systems, RISE und Secunet.
Die Gematik machte zuerst einen fehlerhaften Eintrag in ihrer Trust-Service-Status-Liste verantwortlich. Das Magazin c't brachte den Ausfall später mit einem im Mai 2020 gesetzten neuen DNSSEC-Root-Vertrauensanker in Verbindung, kombiniert mit einem Administrationsfehler. Mitte Juni 2020 war der Stammdatenabgleich bei mehr als 40.000 Praxen noch gestört, und die Behebung brauchte Updates vor Ort durch Dienstleister, weil Fernwartung oft nicht freigegeben war.
Was Sie Ihre Hersteller vor dem nächsten Root-Wechsel fragen sollten
Beginnen Sie mit jedem Gerät, das VPN-Tunnel aufbaut oder DNS selbst validiert, etwa Gateways, medizinische Konnektoren und eingebettete Appliances. Lassen Sie sich von jedem Hersteller schriftlich bestätigen, wie sein Vertrauensanker aktualisiert wird, per RFC 5011 oder von Hand, und ob er KSK-2024 bereits kennt.
Testen Sie einen Neustart oder Reconnect erst nach dieser Bestätigung in einem Wartungsfenster und halten Sie die manuelle Umgehung des Herstellers bereit. Cloudflare bietet einen Bereitschaftstest nach RFC 8509 für den Resolver an, den Ihr Browser nutzt, und sagt, die meisten Website-Betreiber müssten nichts tun.
Setzen Sie Root-Schlüsselwechsel und Zertifikatsabläufe in denselben Änderungskalender wie Software-Releases. Dieser Ausfall hatte ein Datum, einen öffentlichen Schlüssel und eine veröffentlichte Anleitung, und der Fehler zeigte sich erst, nachdem das Datum verstrichen war.
Weiterlesen: Yandex Cloud riet Kunden, anderswo zu hosten | Drei Windows-Supportfristen enden binnen 30 Tagen
