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. Einige (alle?) IDPs verlangen jedoch bei der ECC Signatur einer JWT Challenge, dass diese im "concatenated" format zurückgegeben werden. | 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.: Bei Secunet Konnektoren ist die Verwendung von ECC zur Clientauthentisierung 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"
|
| 3 | Konnektor hat das Pairing zu KT(s) verloren. | In folgenden Fällen kann es sein, dass das KT-Pairing fehlerhaft ist:
| Paire die KTs manuell neu mit dem Konnektor. 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. | |
| 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 während der Testwoche 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. |
| 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:
|
| 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.
|
