Auf dieser Seite sind Probleme/Issues/Fragen/zu beachtende Punkte aufgelistet, welche im Zusammenhang mit der RSA-Abschaltung bzw. mit dem Umstieg auf ECC-Kryptographie auftreten können.
Durch die enthalten Informationen unterstützt sie alle RU-Nutzer.
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.
| Thema | Titel | Detailbeschreibung | Ursache | Fix/Workaround/Antwort | Kommentare | |
|---|---|---|---|---|---|---|
| 1 | Signaturprüfung | RSA-Signaturen können in der Woche nicht validiert werden, obwohl diese bei der Migration in der PU weiterhin validierbar bleiben. | RSA-signierte Bestandsdokumente sind nach der RSA-Abschaltung nicht mehr durch den Konnektor prüfbar. | Die vom Konnektor durchgeführte Dokumentenprüfung erhält REVOKED oder INCONCLUSIVE in der OCSP-Prüfung. | Keiner verfügbar | Nach der Testwoche werden solche Dokumente wieder prüfbar sein. |
| 2 | Konnektor | Singlepersonalisierte Konnektoren sind nicht nutzbar. | Singlepersonalisierte Konnektoren können nach der RSA-Abschaltung keinen VPN-Tunnel in die TI mehr aufbauen. | Konnektoren mit verbauter G2.0 gSMC-K haben nur RSA Material (kein ECC Material vorhanden). | Keiner verfügbar | Bei Secunet kann in diesem Menü geprüft werden, ob der Konnektor Single- oder Dualpersonalisiert ist (Praxis → Karten):
|
| 3 | KT | Singlepersonalisierte Kartenterminals sind nicht nutzbar. | Singlepersonalisierte Kartenterminals können nach der RSA-Abschaltung keinen TLS-Verbindung zum Konnektor mehr aufbauen. | Kartenterminals mit verbauter G2.0 gSMC-KT haben nur RSA Material (kein ECC Material vorhanden). | Die G2.0 gSMC-KT gegen eine G2.1 gSMC-KT austauschen und daraufhin das KT neu mit dem Konnektor pairen. |  Neue gSMC-KT Karten müssen direkt bei den jeweiligen Kartenterminalherstellern bestellt werden. Die Hersteller Cherry, Worldline und GT sind hierfür die Kartenherausgeber. |
| 4 | Karte | G2.0 HBA/SMC-B sind nicht nutzbar. | TI Use Cases, welche HBA/SMC-B benötigen können mit G2.0 Karten nicht durchgeführt werden. | G2.0 Karten haben nur RSA Material (kein ECC Material vorhanden). | Falls möglich G2.1 Karten oder simulierte Karten nutzen. | |
| 5 | Client | Bestimmte KIM-Clientmodule sind nicht für KIM nutzbar. | Clientsysteme, welche die folgenden KOMLE-CM nutzen/integrieren können nach der RSA-Abschaltung keine KIM Mails versenden/empfangen:
| KOMLE-CM mit PTV1.0 kennen den "Crypt"-Parameter des Konnektors nicht. Es wird daher versucht mit RSA zu ent- und verschlüsseln, was fehlschlägt. KOMLE-CM mit PTV1.5.2 von TSI und CGM können keine ECC-verschlüsselten KIM-Mails entschlüsseln. | KOMLE-CM mit PTV1.0:
KOMLE-CM mit PTV1.5.2 von TSI und CGM:
| |
| 6 | Authenticator | Authenticator ist ECC fähig, bis auf die TLS-Verbindung zum Konnektor. | TLS-Authentisierung deaktivieren. | |||
| 7 | Konnektor | RISE Konnektor kann keine VPN-Verbindung in die TI mehr aufbauen. | RISE Konnektoren können während der RU-Testwoche keine VPN-Verbindung in die TI aufbauen. | RISE Konnektoren unterstützen nach derzeitigem Stand offiziell kein ECC auf TLS/IPSEC. | Fix: Update auf die Vorversion RISE FW 6.0.8, wie in Checkliste Implementierung und Testvorbereitung Q2/25 → Eintrag RISE beschrieben. | Nach dem Rückschalten von RSA am Ende der Testwoche sollten die RISE Konnektoren wieder einsatzfähig sein. Ggf. muss die TSL noch manuell neu eingespielt werden. Infos zum Ablauf finden Sie in Zeile 30. |
| 8 | Konnektor | Eine VPN-Verbindung in die TI ist für Konnektoren, welche bis zum Start der Testwoche noch nicht mit ECC am VPN-ZugD Re-Registriert sind nicht möglich. | Eine Re-Registrierung mit ECC gem. Troubleshooting-Guide, Zeile 1 ist nicht möglich, sobald die RSA-Abschaltung erfolgt ist. | Der Konnektor versucht sich zwar beim Re-Registrieren am VPN-ZugD mit dem ECC-Zertifikat der gSMC-K, jedoch ungewollterweise mit dem RSA-Zertifikat der SMC-B anzumelden. Das lehnt der Registrierungsdienst dann ab, da das RSA-Zertifikat der SMC-B nicht validiert werden kann. | Keiner verfügbar Ein zugelassener Fix wird erst mit PTV6 aller Hersteller zur Verfügung stehen. Vorabversionen könnten ggf. zu gegebener Zeit schon einen fix bereitstellen, der Registrierungen mit ECC anstatt RSA signiert. Das ist mit den Herstellern zu vereinbaren. | Eine VPN-Verbindung in die TI ist für Konnektoren, welche noch nicht mit ECC am VPN-ZugD Re-Registriert sind für die Dauer der Testwoche leider nicht möglich. Ihre betreffenden Konnektoren sollten aber spätestens zum Zeitpunkt der vollständig erfolgten Rückscdhaltung nach der Testwoche wieder einsatzfähig sein. (u.U. muss dann manuell ein TSL-Update ausgeführt werden) Für die Testwoche Q1 2025 betrifft diese Problematik besonders Konnektoren von:
|
| 9 | Konnektor | KoCo Konnektoren -Fehler beim CRL-Download bei einigen Boxen |
| Ursache ist ein Bug in der KoCo Firmware. | Fall A - Fehler "EC_CRL_Out_Of_Date" bereits aktiv und Konnektor ist offline:
Fall B -Fehler "EC_CRL_Out_Of_Date" noch nicht aktiv und Konnektor ist online. ("EC_CRL_Expiring" als WARNING aktiv oder "Signaturprüfung der CRL fehlgeschlagen: Fehlercode 4130" nach TUC_KON_040):
| |
| 10 | Client | Kein KIM möglich mit Arvato KIM-CM | Der KIM FD von Arvato ist nicht ECC-fähig |
| ||
| 11 | Konnektor | Secunet Konnektoren am TSI VPN-ZugD haben keine Verbindung zur TI (bzw. auch keine Verbindung zum SIS) | Beim IPSEC-Verbindungsaufbau (AKA herstellen der VPN-Verbindung in die TI bzw. zum SIS) gegen Konzentratoren vom T-Systems (TSI) VPN-ZugD scheitert der Konnektor wiederholt daran, eine Verbindung aufzubauen. | Secunet Konnektoren arbeiten die vom DNS des VPN-ZugD bereitgestellte priorisierte Liste von FQDNs aller verfügbaren VPN-Konzentratoren nicht wie spezifikatorisch gefordert ab, sondern versuchen sich wiederholt immer nur an einem Konzentrator-FQDN mit der TI zu verbinden, welcher jedoch nicht für ECC basierte IPSEC Verbindungen geeignet ist. | derzeit keiner verfügbar | Warum das Secunet Verhalten nur beim TSI VPN-ZugD auftritt, ist derzeit noch in Klärung. Die gematik vermutet bis dato, dass das problem mit Secunet auch gegen andere VPN-ZugD vorhanden ist, jedoch deren Konzentratoren jeweils dualmode-fähig sind und sowohl RSA als auch ECC basierte IPSEC Verbindungen aufgebaut werden können, sodass das Fehlverhalten kein Scheitern der TI-Verbindung zur Folge hat. |
| 12 | VPNZugD | Registrierung/TI-Tunnel Aufbau mit TSI VPN-ZD nicht möglich | Der TSI VPN-ZD hat eine restriktive Implementierung bei der Registrierung. TSI erlaubt nur eine Kombination mit deiner gSMC-K, SMC-B und Contract ID. Wenn man versucht eine bereits registrierte SMC-B, gSMC-K oder Contract ID nochmal in einer teilweise anderen Kombination (z.B. anderer Konnektor) zu verwenden, dann lässt der VPN-ZD das nicht zu. | Restriktive Implementierung im TSI VPN-ZD bezüglich Registrierung | Um einen neuen Aufbau zu initiieren, muss zunächst die bereits zur Registrierung verwendete Kombination aus SMC-B, gSMC-K und Contract ID deregistriert werden. Wenn die zuvor genutzte Registrierung unbekannt ist, muss Herr Kromminga (karsten.kromminga@t-systems.com) von T-SI angeschrieben werden, damit er den entsprechenden Eintrag in der Datenbank des Reg Servers löschen kann. |
|
| 13 | ECC-Testwoche | Nutzung von "RU-Dev" für die ECC-Testwoche | Warum nutzt man für die RU-Testwoche nicht alternativ die "RU-Dev"? | Die RU und die RU-Dev haben die gleiche TSL und damit den gleichen Vertrauensraum. Beide Umgebungen sind daher von der RSA-Abschaltung betroffen. | ||
| 14 | ECC-Testwoche | Andere Verwendung von RU | Die RU dient vielen Herstellern unter anderem für Test und Support. Die Abschaltung stellt diesbezüglich ein Risiko für sie dar. | gematik versteht, dass die RU zusätzlich zu dem offiziell von der gematik vorgesehenen Zweck als Testmittel auch anderweitig eingesetzt wird. Allerdings gibt es den gesetzlichen Auftrag, die Verwendung von RSA in der TI zu unterbinden, welchem nachgekommen werden muss. gematik hat Risiken und Beeinträchtigungen Dritter diskutiert und abgewogen und bittet um Verständnis. gematik versucht die Einschränkungen möglichst kurz zu halten. Das Format der ECC-Testwoche wird in den kommenden Monaten regelmäßig wiederholt. | ||
| 15 | Allgemein | Zugriff auf Service Portal | Was tun, wenn man keinen Zugriff auf das Service Portal zur RSA / ECC Migration hat? | Bitte melden Sie uns über das gematik Kontaktformular im Fachportal, dass Sie Zugriff auf dieses Anfrageportal benötigen oder melden Sie sich im Teams-Chat. | ||
| 16 | ECC-Testwoche | Teams-Chat | Gibt es einen Teams-Chat in dem sich Teilnehmer untereinander austauschen können? | Teams-Chat: ECC Testwoche | Herstellerkanal - RSA Abschaltung RU24 | Microsoft Teams Bitte senden Sie uns eine Anfrage an das Serviceportal mit den Email-Adressen, welche Zugriff auf den Teams-Chat benötigen. | ||
| 17 | ECC-Testwoche | Informationskanäle | Wie werde ich über Updates während der Testwoche informiert? | Wir werden nützliche Informationen während der Testwoche auf den Confluence Seiten veröffentlichen. Wir empfehlen Ihnen diese Seite zu "beobachten", um bei Aktualisierungen informiert zu werden. | ||
| 18 | ECC-Testwoche Client | Clientsystemauthentisierung | Müssen wir auch die Strecke PS→Konnektor bzw. Konnektor→PS in Vorbereitung zur Testwoche anpassen? (Clientsystemauthentisierung mit dem Konnektor und vice versa) | Nein, die bestehenden Zertifikate zur Authentisierung auf dieser Strecke bleiben weiterhin funktionsfähig, auch wenn diese RSA-basiert sind. | ||
| 19 | JWT | ECDSA bei JWT Authentisierung | Wie erzeuge ich eine ECC-Signatur (ECDSA) für die JWT Authentisierung? | Zur Erzeugung einer ECC-Signatur (ECDSA-Signatur) am Konnektor mittels Operation ExternalAuthenticate gehen Sie bitte beim SOAP-Aufruf wie folgt vor:
Im Rückgabeparameter
| ||
| 20 | Signaturprüfung | OCSP-Prüfung | Wie wird bei Signaturprüfung einer Email, die nach der „RSA-Abschaltung“ sich noch auf dem Server des Fachdienstes befindet und RSA-Signatur enthält, eine OCSP-Prüfung durchgeführt? |
| ||
| 21 | Entschlüsselung | Zertifikatsprüfung | Führt der Konnektor beim Entschlüsseln einer Email, die nach der „RSA-Abschaltung“ sich noch auf dem Server des Fachdienstes befindet und mit Hilfe von RSA verschlüsselt ist, eine Zertifikatsprüfung durch? | Die Entschlüsselung im Konnektor erfolgt mit Hilfe eines privaten Schlüssels. Hier ist keine Zertifikatsprüfung vorgesehen. | ||
| 22 | JWT | 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. | |
| 23 | Konnektor | Keine VPN-Verbindung in die TI | 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:
|
| 24 | Konnektor KT | Pairing | 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. |
| 25 | Konnektor | CA-Zertifikat nicht in TSL | 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. |
|
| 26 | Konnektor | 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! |
| 27 | Karte | 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: | |
| 28 | Zertifikat | 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) | |
| 29 | Zertifikat | p12-Zertifikatsdateien | 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.
| |
| 30 | Konnektor | Offline nach der ECC-Testwoche | 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:
|
| 31 | Konnektor | Keine VPN-Verbindung nach der ECC-Testwoche | 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.
|
|
| 32 |
|
Add Comment