Wenn der Konnektor nicht kaputt ist, sondern der Schlüssel im Hintergrund wechselt
Am 11. Oktober 2026, 21:35 Uhr, meldete der TI-Konnektor einer von uns betreuten Zahnarztpraxis: Verbindung getrennt. Der Konnektor war nicht defekt – Ursache war ein bundesweiter DNSSEC-Schlüsseltausch, zeitgleich mit der Abschaltung alter RSA-Zertifikate. Workaround, Prüfschritte und ein offener Einzelbefund.
21:35 Uhr, 11. Oktober 2026: Der TI-Konnektor einer von uns betreuten Zahnarztpraxis meldet die Verbindung zur Telematikinfrastruktur getrennt. Kein Kartenlesen, kein KIM, keine eAU-Signatur. Am nächsten Vormittag versuchen wir das Naheliegende – Konnektor stromlos machen, neu starten. Ohne Wirkung. Die Meldung bleibt dieselbe: „Verbindungsaufbau des TI VPN Kanals wurde abgebrochen.“
Der Konnektor war zu keinem Zeitpunkt defekt. Die Ursache lag nicht bei der Praxis und nicht bei ihrem Internetanschluss, sondern in einem bundesweiten, seit Jahren angekündigten Schlüsseltausch im Domain Name System – zusammengefallen mit einer zweiten, unabhängigen Frist für alte TI-Zertifikate. Beides traf im Oktober 2026 nahezu jede TI-angebundene Praxis in Deutschland.
Warum ein Neustart hier das Falsche ist
Ein Konnektor, der die TI-Verbindung verliert, verleitet reflexhaft zum Neustart. Genau das rät gematik bei diesem Fehlerbild ausdrücklich nicht, solange die Ursache nicht verstanden ist: Ein Konnektor, der im falschen Moment neu startet, kann zusätzliche, überlagernde Fehlerzustände erzeugen und damit die eigentliche Ursache verdecken, statt sie sichtbar zu machen. Wir haben den Neustart danach erst wieder ganz am Ende eingesetzt – nachdem die Ursache feststand und die Korrektur bereits eingetragen war.
Zwei geplante Änderungen, ein gemeinsamer Monat
Zum 11. Oktober 2026 löste ICANN den sogenannten Root-KSK (Key Signing Key) im DNS aus – einen planmäßigen Schlüsseltausch mit der Bezeichnung KSK-2024 (KeyTag 38696). Der TI-Konnektor prüft die DNS-Antworten, die er für die Namensauflösung der TI-Gegenstellen erhält, kryptographisch gegen genau diesen Schlüssel ab (DNSSEC). Ein Konnektor, dessen hinterlegter Trust Anchor noch den alten Schlüssel enthält, bewertet jede DNS-Antwort für die TI-Namensräume plötzlich als nicht vertrauenswürdig – und verweigert den VPN-Verbindungsaufbau, obwohl Internetanschluss, Router und Konnektor-Hardware einwandfrei arbeiten.
Parallel dazu liefen zwei weitere, unabhängige Fristen ab: Am 14. Oktober 2026 wurde der Status der RSA-Zertifizierungsstellen für Praxisausweise (RSA-SMCB-CAs) in der TI-Vertrauensliste (TSL) auf „revoked“ gesetzt, am 19. Oktober 2026 wurden die OIDs der Stufe 2 für die Komponenten-CAs (Komp-CA) aus der TSL entfernt. Die RSA-Komp-CAs selbst fallen laut gematik erst am 1. April 2027 weg. Beide Termine gehören zur seit Längerem laufenden Umstellung von RSA- auf ECC-Zertifikate (RSA2ECC) für Konnektor, Praxisausweis (SMC-B), Heilberufsausweis (eHBA), Kartenterminal (SMC-KT) und Konnektor-eigene Sicherheitsmodule (SMC-K).
Für die Fehlersuche ist das die eigentliche Schwierigkeit: Ein Konnektor, der die TI-Verbindung verliert, sieht von außen in beiden Fällen identisch aus. Ob DNS, Zertifikat oder etwas Drittes die Ursache ist, lässt sich an der Fehlermeldung allein nicht unterscheiden.
Der Workaround: Trust Anchor am Konnektor aktualisieren
Für den secunet-Konnektor – bei den von uns betreuten Praxen der häufigste Typ – sieht das Vorgehen so aus:
- In der Konnektor-Verwaltungsoberfläche (
https://<Konnektor-IP>:8500) unter VPN → VPN-Zugangsdienst → VPN-Zugangsdienstanbieter den Eintrag „DNSSEC Trustanchor Internet“ öffnen. - Den aktuellen Inhalt sichern, bevor irgendetwas verändert wird – eine einfache Kopie des bestehenden XML reicht.
- Den Eintrag durch die aktuelle, offiziell von gematik veröffentlichte Trust-Anchor-Liste ersetzen, die den neuen Schlüssel KSK-2024 (KeyTag 38696) enthält.
- Speichern, danach den Konnektor vollständig neu starten – jetzt, nicht vorher.
- Nach dem Neustart den TI-Status prüfen: VPN-Verbindung TI und VPN-Verbindung SIS sollten „Verbunden“ zeigen, und die Protokollmeldung sollte „… mit ECC/256bit“ lauten statt der alten RSA-Variante.
Trust-Anchor-Werte gehören nicht per Copy-Paste aus einer Anleitung in die Konnektor-Oberfläche, auch nicht aus dieser hier. Es handelt sich um sicherheitsrelevantes kryptographisches Material, das ausschließlich aus der offiziellen gematik-Quelle bezogen werden sollte – eine veraltete oder falsch übertragene Kopie öffnet im schlechtesten Fall genau die Lücke, die DNSSEC eigentlich schließt.
Bei der Praxis aus diesem Fall war die Verbindung ab 10:04 Uhr wieder da – TI und SIS gleichzeitig, mit der Meldung „SIS VPN Kanal wurde aufgebaut (mit ECC/256bit)“.
Wie lange gilt dieser Workaround?
Der Schlüssel KSK-2024 hat kein festes Ablaufdatum. Er bleibt gültig, bis ICANN den nächsten Schlüsseltausch durchführt – der Vorgänger KSK-2017 war rund neun Jahre im Einsatz. Damit ist der Workaround dauerhaft wirksam, nicht nur eine Überbrückung. Wichtig ist, am Konnektor die automatische Firmware-Aktualisierung aktiviert zu lassen, damit künftige Trust-Anchor-Wechsel nicht erneut von Hand eingetragen werden müssen, sobald der Hersteller sie per Firmware ausliefert.
Der zweite Teil: ECC statt RSA, Komponente für Komponente
Der DNSSEC-Workaround löst nur die eine Hälfte des Problems. Ab den beiden RSA-Abschaltterminen funktionieren Prüfungen nur noch zuverlässig, wenn die jeweilige Komponente ein gültiges ECC-Zertifikat trägt. Das lässt sich vollständig ohne PIN in der Konnektor-Oberfläche kontrollieren:
| Prüfpunkt | Wie | Soll |
|---|---|---|
| VPN mit ECC | Meldungszeile in der Konnektor-Oberfläche | „… aufgebaut (mit ECC/256bit)“ |
| Dienstversionen | Dienstverzeichnis https://<Konnektor-IP>/connector.sds abrufen | CertificateService ≥ 6.0.1, AuthSignatureService ≥ 7.4.1, EncryptionService ≥ 6.1.1 |
| Firmware | Konnektor-Oberfläche, System bzw. Dienstverzeichnis | aktuelle Version des Herstellers |
| Karten (SMC-B, eHBA, SMC-KT, SMC-K) | Praxis → Karten → Karte anklicken → „ECC Authentifizierungs-Zertifikat prüfen“ (ruft den Sperrstatus per OCSP online ab) | „gültig – von OCSP“, Ablaufdatum in der Zukunft |
Alternativ prüft der Sammel-Eintrag „Zertifikate für gesteckte SMC-B, HBA, SMC-KT und SMC-K prüfen“ alle gesteckten Karten auf einmal. Während der Prüfung sollte an diesem Arbeitsplatz nicht gearbeitet werden, insbesondere nicht an einem, an dem gerade Patientenkarten gelesen werden – in der Kartenübersicht erscheinen gesteckte Gesundheitskarten mit dem Namen der Patientin oder des Patienten.
Was die Prüfung bei dieser Praxis ergab
Konnektor, primäre und sekundäre SMC-K, Praxisausweis (SMC-B) und Heilberufsausweis (eHBA) zeigten durchweg ein gültiges ECC-Zertifikat mit bestätigtem OCSP-Status und einem Ablaufdatum, das deutlich in der Zukunft lag. Eine Komponente fiel aus dem Bild: Das Kartenterminal an der Rezeption (SMC-KT) meldete sein ECC-Zertifikat als „ungültig von OCSP“.
Das Terminal selbst arbeitete trotzdem weiter – eine Test-Gesundheitskarte wurde zuverlässig erkannt, der Konnektor nutzt dafür die bestehende Kopplung (Pairing) mit dem Terminal, die von der Zertifikatsprüfung unabhängig ist. Entscheidend war deshalb, nicht vorschnell zu handeln: Das Terminal wurde nicht neu gekoppelt und der Konnektor nicht ohne Not zurückgesetzt, um die bestehende, funktionierende Kopplung nicht zu gefährden. Stattdessen haben wir den Befund dokumentiert, für eine Woche später eine erneute Prüfung terminiert und für den Fall, dass der Status bestehen bleibt, den Kontakt zum Hersteller des Kartenterminals vorbereitet. Das ist der typische Umgang mit einem Einzelbefund in einer sonst sauberen Prüfung: beobachten, terminieren, erst eskalieren, wenn der zweite Prüfzeitpunkt denselben Befund bestätigt.
Funktionstest nach den Stichtagen
Nach dem 14. und erneut nach dem 19. Oktober 2026 empfiehlt sich je ein kurzer Funktionstest, unabhängig davon, ob zuvor Auffälligkeiten aufgetreten sind:
| Test | Ablauf | Soll |
|---|---|---|
| Kartenlesen (VSDM) | eGK einer Patientin bzw. eines Patienten in die Praxissoftware einlesen | Versichertendaten und Prüfnachweis werden übernommen |
| KIM senden und empfangen | Testnachricht aus der Praxissoftware an das eigene KIM-Postfach | Nachricht kommt an |
| Signatur mit eHBA | eAU bzw. E-Rezept signieren (falls genutzt) | Signatur ohne Fehlermeldung |
| Konnektor-Status | Konnektor-Oberfläche, Startseite | TI und SIS verbunden, keine neuen Fehlermeldungen |
Treten nach dem 19. Oktober Fehler bei KIM oder anderen Fachdiensten auf, obwohl alle Karten ein gültiges ECC-Zertifikat tragen, liegt die Ursache in aller Regel nicht mehr am Konnektor, sondern beim KIM-Anbieter oder in der Praxissoftware selbst.
Was das für andere Praxen bedeutet
Dieser Ausfall war kein Einzelfall einer Praxis und keine Fehlkonfiguration – er betraf, zeitlich konzentriert um den 11. Oktober 2026, praktisch jede TI-angebundene Praxis mit einem Konnektor, dessen Trust Anchor noch nicht den neuen Root-Schlüssel kannte. Für jede TI-Praxis, die diesen Zeitraum noch vor sich hat oder ähnliche Symptome zeigt, in Kurzform:
- Meldet der Konnektor die TI- oder SIS-Verbindung als getrennt: nicht reflexhaft neu starten, erst die Fehlermeldung genau lesen und die Ursache eingrenzen.
- Trust Anchor in der Konnektor-Oberfläche kontrollieren und bei Bedarf auf die aktuelle, offizielle gematik-Version bringen – Werte ausschließlich aus der offiziellen Quelle, nie aus einer Anleitung kopieren.
- Nach dem Fix: ECC-Zertifikate aller Komponenten prüfen, nicht nur des Konnektors – gerade Kartenterminals und ältere Karten der Generation 2.0 fallen sonst erst auf, wenn sie bereits gebraucht werden.
- Ablaufdaten von SMC-B, eHBA und SMC-KT im Blick behalten; Lieferzeiten für Folgekarten liegen oft bei mehreren Wochen.
- Automatische Firmware-Aktualisierung am Konnektor aktiviert lassen, damit künftige Trust-Anchor-Wechsel nicht erneut manuell nachgezogen werden müssen.
Praxisname, Adresse und alle Gerätekennungen in diesem Beitrag sind entfernt bzw. anonymisiert. Zeitangaben, technische Abläufe und Prüfergebnisse sind unverändert.