Auf dieser Seite sind die bekannten potentiellen Probleme, welche im Zusammenhang der RSA-Abschaltung auftreten können zum Zweck der Unterstützung aller RU-Nutzer zur Behebung aufgelistet.
Diese Seite wird entsprechend des aktuellen Kenntnisstandes stetig erweitert. Wir empfehlen Ihnen diese Seite zu "beobachten", um bei Aktualisierungen informiert zu werden.
Sollten Ihnen weitere hier nicht aufgeführte Probleme bekannt sein, so bitten wir Sie, diese über das ServiceDesk Portal zu melden.
Troubleshooting-Guide
| Titel | Detailbeschreibung | Troubleshooting-Prozedur | Kommentare / Hinweise | |
|---|---|---|---|---|
| 1 | JWT Authentisierung mittels JWT schlägt fehl. | Die Konnektor/Consumer-Operation ExternalAuthenticate gibt einen mit ECC signierten Binärstring derzeit im DER ASN.1 Encoding zurück. Die IDPs verlangen jedoch bei der ECC Signatur einer JWT Challenge, dass diese im "concatenated" format zurückgegeben werden. Mögliche weitere Indizien für dieses Problem:
| Konvertiere die DER ASN.1 encoded Signatur in eine "concatenated" encoded Signatur um, bevor diese via JWT an den IDP übergeben wird. Eine Beispiel-Implementierung der Konvertierung kann hier bei der authenticator-app gefunden werden: Ein weiteres Beispiel dafür gibt es hier in Java (special thanks to Manuel Blechschmidt Experimental: Signatur-Umkodierung in python (ohne irgendwelche Bibliotheken): https://bitbucket.org/andreas_hallof/vsdm2/src/main/sig-conv.py dort Funktion SigConvert() | Das Problem tritt bei RSA basierten Signaturen nicht auf, da es für PKCS#1 Signaturen nur das DER ASN.1 Encoding definiert ist. JWT "muss" dies daher akzeptieren. |
| 2 | Konnektor kann keine VPN-Verbindung in die TI mehr aufbauen. | In folgenden Fällen kann es sein, dass die automatische Re-Registrierung des Konnektors mit ECC am VPN-Zugangsdienst nicht erfolgreich ist:
|
| zu Schritt 1.b (Option 1): Bei Secunet Konnektoren ist die Funktionalität zur automatischen Re-Registrierung mit ECC am VPNZugD defaultmäßig deaktiviert. Diese kann wie folgt aktiviert werden: Konnektor → Netzwerk → VPN → VPN-Zugangsdienst → Erweiterte Einstellungen für die Freischaltung: Das rot Markierte bitte aktivieren
2. "ECC" setzen, dann "Tick" klicken, dann SMC-B PIN am KT eingeben
Ergebnis: Bei SMC-K Zertifikatstyp steht jetzt "RSA, ECC" und nicht mehr nur "RSA"
zu Schritt 2: Im Management-UI des Secunet Konnektors: Konnektor → Netzwerk → VPN → VPN-Zugangsdienst: Ganz nach unten scrollen und den Bereich SMC-K Zertifikatstyp prüfen. Steht dort "ECC, RSA" bzw. nur "ECC" (und NICHT nur "RSA"), dann ist die Registrierung mit ECC am VPN-ZugD ordnungsgemäß erfolgt und der Konnektor wird bei der nächsten RSA-Abschaltung in der RU online in der TI bleiben. Negativbeispiel #1: Hier ein Beispiel-Screenshot eines Konnektors, der nur mit RSA am VPN-ZugD registriert ist und daher noch Re-Registriert werden muss:
Negativbeispiel #2: Bei einigen Konnektoren kann es sein, dass das Feld "SMC-K Zertifikatstyp" nicht sichtbar ist:
Gehen Sie in diesem Fall wie folgt vor:
Danach sollte das Feld "SMC-K Zertifikatstyp" sichtbar sein und der Registrierungsstatus daraus abzulesen sein. Positivbeispiel #1: Hier ein Beispiel-Screenshot eines Konnektors, der nur mit mit ECC am VPN-ZugD registriert ist. Die Re-Registrierung mit ECC ist daher für dieses Gerät erfolgreich abgeschlossen:
Positivbeispiel #2: Hier ein Beispiel-Screenshot eines Konnektors, der sowohl mit ECC als auch RSA am VPN-ZugD registriert ist (Mehrfachregistrierung). Die Re-Registrierung mit ECC ist daher für dieses Gerät erfolgreich abgeschlossen:
|
| 3 | Konnektor hat das Pairing zu KT(s) verloren. | In folgenden Fällen kann es sein, dass das KT-Pairing fehlerhaft ist:
| Paire die betroffenen KTs manuell von Grund auf neu mit dem Konnektor, indem für das Pairing ECC basierte Zertifikate genutzt werden. Falls eine gSMC-KT mit G2.0 verbaut ist, ersetze die Karte gegen eine G2.1 Karte. Dann paire das KT mit der neuen Karte. | Hinweis: Ab der Verbreitung der zugelassenen PTV6 im Feld (erwartet frühestens ca. ab Mitte 2025) Werden bestehende RSA-Basierte Pairings automatisch auf ECC basierte Pairings überführt, sodass ab diesem Zeitpunkt manuelle neue Pairings nicht mehr notwendig werden. |
| 4 | Fehlermeldung CA-Zertifikat nicht in TSL gefunden. | Hier wird versucht mit RSA-Zertifikaten zu arbeiten und darum schlägt der Anwendungsfall fehl. | Hier muss man vermutlich die eigene Software anpassen und dafür sorgen, dass mit ECC-Zertifikaten gearbeitet wird. |
|
| 5 | Update der TSL schlägt fehl. | TSL kann nicht heruntergeladen werden, Downlaod nicht erfolgreich,... Verwendeter Downlaodpunkt ist: ... Es wird noch mit der RSA-TSL (also ohne ECC) gearbeitet. Dieser Downlaodpunkt ist für die Testwoche deaktiviert.
| ECC-Migration des Vertrauensraumes für den betroffenen Konnektor durchführen. | Hier ist auch kein Wechsel zurück nach Abschluss der Testwoche sinnvoll. Lieber dauerhaft auf der ECC-TSL bleiben. Und sicherstellen, dass die Downloadpunkte gemäß A_17680-01 konfiguriert sind! |
| 6 | Es werden ECC Testkarten benötigt. Hinweis: Testkarten der Generation G 2.1 enthalten bereits ECC-Zertifikate | Es liegen noch keine eGK / SMC-B / HBA Testkarten G2.1 vor. | Für eGK-/HBA-/SMC-B-Zertifikate werden bei der gematik entsprechende Testkarten der Generation G2.1 bestellt | (Kostenpflichtige) Bestellung von Testkarten: https://fachportal.gematik.de/gematik-onlineshop/testkarten |
| 7 | Es werden ECC Testzertifikate benötigt. Hinweis: Nicht relevant für PS-Hersteller, da diese keine Zertifikate aus dem PMS beziehen. | Es liegen noch keine ECC-Testzertifikate für Server / Fachdienste vor. | Für Komponenten-Zertifikate werden im PMS entsprechende Zertifikate beantragt, dafür muss vorher im ITSM eine entsprechende Berechtigung via Service Request beantragt werden. | SR im ITSM: SR0110 - Berechtigung für die Organisation (generell und für die Hinterlegung von FQDN's) |
| 8 | Für automatische Tests werden p12-Zertifikatsdateien benötigt | Für Tests ist das manuelle Stecken von Testkarten mitunter sehr aufwändig. Es ist möglich, statt des Steckens einer Karte auch die p12-Datei eines benötigten Zertifikats zu verwenden. | Für einzelne gematik Testkarten können p12-Dateien der enthaltenen Zertifikate aus der ehealthCA exportiert werden. Für entsprechende Aufträge bitte eine entsprechende email an pki@gematik.de schicken. | |
| 9 | Konnektor ist immer noch Offline, obwohl die Testwoche lange vorbei ist | In einigen Fällen kann es sein, dass der Konnektor nicht in der Lage ist, nach dem erneuten Zuschalten von RSA am Ende der Testwoche, die neue TSL herunterzuladen. Dies kann bei Konnektoren aller Hersteller passieren. |
| Bei Secunet kann so vorgegangen werden:
Bei RISE kann man so vorgehen:
|
| 10 | KoCo Konnektoren verlieren die VPN-Verbindung, obwohl die Testwoche lange vorbei ist | Die RSA-VPNK-CA's in der ECC_RSA TSL der RU verweisen alle auf den ServiceSupplyPoint http://download-testref.crl.ti-dienste.de/crl/vpnk-ecc.crl http://download-testref.crl.ti-dienste.de/crl/vpnk-ca1.crl ist in ECC_RSA TSL der RU nicht mehr referenziert. Allerdings scheinen die KoCo Boxen hart auf http://download-testref.crl.ti-dienste.de/crl/vpnk-ca1.crl zu verweisen. Dadurch kann keine aktive CRL heruntergeladen werden. Sobald die in Konnektor vorhandene CRL nicht mehr gültig ist, geht der Konnektor in den Betriebszustand FATAL und geht offline:
( http://download-testref.crl.ti-dienste.de/crl/vpnk-ca1.crl gehört zum Vertrauensraum der alten RSA TSL, welche in der RU nun bewusst abgeschalten wurde und auch nach der Testwoche abgeschalten bleibt) | Eine neue aktuelle CRL muss manuell in den Konnektor geladen werden.
|
|
Ab der Testwoche vom 24.02.2025 bleibt die RSA-TSL auch außerhalb der Testwoche dauerhaft deaktiviert.
0 Comments