Auf dieser Seite sind die bekannten Probleme, welche im Zusammenhang der RSA-Abschaltung auftreten, zum Zweck der Information der RU-Nutzer 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.



TitelDetailbeschreibungUrsacheFix/WorkaroundKommentare
1 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ügbarNach der Testwoche werden solche Dokumente wieder prüfbar sein.
2Singlepersonalisierte 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):

3Singlepersonalisierte 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.(warning) Neue gSMC-KT Karten müssen direkt bei den jeweiligen Kartenterminalherstellern bestellt werden. Die Hersteller Cherry, Worldline und GT sind hierfür die Kartenherausgeber.
4G2.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.
5Bestimmte 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
  • KOMLE-CM mit PTV1.5.2 von TSI und CGM

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:

  • Update auf PTV 1.5.x


KOMLE-CM mit PTV1.5.2 von TSI und CGM:

  • noch kein Fix verfügbar
  • wenn möglich, anderen Hersteller nutzen

6Authenticator ist ECC fähig, bis auf die TLS-Verbindung zum Konnektor.



TLS-Authentisierung deaktivieren.


7RISE 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.6, wie in Checkliste Implementierung und Testvorbereitung → 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 Troubleshooting Maßnahmen Eintrag 9.


8Eine 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:

  • Secunet (weil diese per default noch keine automatische Re-Registrierung mit ECC durchführen und dies erst im Mgmt-UI aktiviert werden muss)
  • RISE (weil das 1. ECC fähige FW Update 6.0.6 erst am der RU zur Verfügung stand und die Funktionalität der autom. Re-Registrierung in einem so kurzen Zeitraum noch nicht in Effekt treten kann)
9KoCo Konnektoren -Fehler beim CRL-Download bei einigen Boxen
  • Bei einigen KoCo Konnektoren schlägt der CRL-Download als Teilschritt nach der TSL-Aktualisierung fehl.
  • Die Folge ist, dass ein betroffener Konnektor über kurz oder lang in den Fehlerzustand "EC_CRL_Out_Of_Date" läuft. Dieser ist FATAL und hat eine Online Trennung von der TI zur Folge.
  • Betroffen sind nur bestimmte Konnektoren, welche damals den Vertrauensraumwechsel von TSL_RSA auf TSL_RSA_ECC vor einem bestimmten Datum durchgeführt haben.

Ursache ist ein Bug in der KoCo Firmware.

Fall A - Fehler "EC_CRL_Out_Of_Date" bereits aktiv und Konnektor ist offline:

  1. CRL manuell in den Konnektor laden, um TI-Verbindung wiederherzustellen (gem. Eintrag 10 Troubleshooting Maßnahmen)
  2. Nachhaltigen Fix gem.  https://wiki.gematik.de/x/c9e5J umsetzen


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):

  1. Nachhaltigen Fix gem.  https://wiki.gematik.de/x/c9e5J umsetzen


10Kein KIM möglich mit Arvato KIM-CMDer KIM FD von Arvato ist nicht ECC-fähig


 


11

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

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.  

Empfehlung für die nächste Testwoche: 1-2 Wochen vor der Testwoche sollte die Deregistrierung und Registrierung in der gewünschten Kombination (SMC-B, gSMC-K und Contract ID) mal getestet werden, damit der TSI VPN-ZD auch erwartungsgemäß funktioniert.