Diese Seite richtet sich speziell an DVOs und bietet eine ergänzende Hilfestellung, um den Umstieg auf ECC erfolgreich zu gestalten.

Der Fokus liegt hier auf der TLS-Absicherung der Schnittstelle zwischen Konnektor und dem Clientsystem. Unter Clientsystem wird PS, KIM, Authenticator, etc. verstanden.

Alle hier bereitgestellten Inhalte basieren auf den offiziellen Spezifikationen, Implementierungsleitfäden und Dokumentationen der gematik. Diese Seite dient als zusätzliche Orientierungshilfe: Sie stellt konkrete Umstellungen dar, zeigt technische Zusammenhänge auf, bündelt relevante Informationen und erleichtert so die Implementierung im Primärsystem.

Relevante Anwendungsfälle mit Hinweisen zur Umstellung sind zusätzlich hier zu finden: "Test Scope zum Nachweis der ECC-Fähigkeit"

Inhalt:

Clientanbindung

Zusammenfassung & Empfehlung

Die Anbindung der Clientsysteme an den Konnektor bezüglich der verwendeten Zertifikate muss weder nach der RSA-Abschaltung für nonQES noch nach dem Update das Konnektors auf PTV6 angepasst werden, auch wenn sie bis jetzt über RSA 2048 abgesichert ist.

Es gibt keine technischen Mechanismen, die eine Verwendung von RSA 2048 bei beidseitiger Authentisierung, bei einseitiger Authentisierung und bei sonstiger Absicherung der Clientanbindung in Zukunft verhindern, auch über den 01.07.2026 hinaus.

Eine manuelle Umstellung auf ein sicheres Verfahren wie ECC oder RSA 3072 wird von der gematik empfohlen und ist zeitnah notwendig. Dabei garantiert der folgende Weg die größte Interoperabilität:

• Die Kommunikation zwischen Clientsystem und Konnektor wird auf mTLS (beidseitige, zertifikatsbasierte Authentisierung) umgestellt.
• Ein ECC 256 NIST Server-Zertifikat wird im Konnektor generiert und aus dem Konnektor exportiert.
  • Das gerade generierte Server-Zertifikat wird dem Clientsystem bekanntgemacht.
• Ein ECC 256 NIST Client-Zertifikat wird im Konnektor generiert und exportiert.
  • Das gerade generierte Client-Zertifikat wird ins Clientsystem importiert

Die Erläuterungen für diese Zusammenfassung finden Sie in den folgenden Abschnitten dieser Seite.

Dringlichkeit der Umstellung auf ECC

Ausgangslage

Clientzertifikate (Zertifikate zur Authentisierung des Clientsystems ggü. dem Konnektor):

Es gibt mehrere Möglichkeiten die Clientzertifikate (wie auch die privaten Schlüssel) zu bekommen:

• Sie können vom Konnektor erzeugt und exportiert werden. Sie müssen dann anschließend im Clientsystem hinterlegt werden.
• Sie können von einer externen PKI erzeugt und in den Konnektor importiert werden.
• Sie können von einem anderen externen System erzeugt und in den Konnektor importiert werden. Sie müssen dann anschließend im Clientsystem hinterlegt werden.

Aktuell wird die überwiegende Mehrzahl der für die Absicherung der Clientanbindung verwendeten Clientzertifikate vom Typ RSA2048 sein.

Konnektorzertifikate (Zertifikate zur Authentisierung des Konnektors ggü. dem Clientsystem):

Es gibt mehrere Möglichkeiten die Konnektorzertifikate zu bekommen:

• Sie können vom Konnektor erzeugt und exportiert werden (Software-Zertifikat). Sie müssen dann anschließend im Clientsystem bekannt gemacht werden.
• Sie können von einer externen PKI erzeugt (inklusive privaten Schlüssels, Software-Zertifikat) und in den Konnektor importiert werden.
• Sie können von einem anderen externen System erzeugt (Software-Zertifikat) und in den Konnektor importiert werden. Sie müssen dann anschließend im Clientsystem bekannt gemacht werden.
• Der Konnektor kann direkt das Zertifikat der gSMC-K verwenden. Dieses muss dann exportiert und im Clientsystem bekannt gemacht werden.

Aktuell wird die überwiegende Mehrzahl der für die Absicherung der Clientanbindung verwendeten Clientzertifikate vom Typ RSA2048 sein. Es sind sowohl Software-Zertifikate, als auch kartenbasierte Zertifikate (von der gSMC-K) in Verwendung. Falls ein Konnektor ein kartenbasiertes ECC-Zertifikat verwendet, ist es zwangsläufig ein Zertifikat mit der brainpool-Kurve, weil auf der gSMC-K sich kein anderes befindet.

Hintergrund

Ab dem 01.01.2026 verliert RSA 2048 nach SOG-IS seine Eignung. In Folge dessen soll RSA 2048 nicht mehr verwendet werden.

Im QES-Bereich wird das durch die BNetzA beaufsichtigt und eine zeitlich versetzte Durchsetzung ab 1.7.2026 ist zu erwarten. Für die Client- und Konnektorzertifikate für der Clientanbindung, die ja im nonQES-Bereich stattfindet, werden jedoch noch bis Mitte 2026 RSA 2048-Zertifikate toleriert. Es sind keine technischen Maßnahmen vorgesehen, die diese Nutzung blockieren oder verhindern.

Nichtsdestotrotz weist die gematik darauf hin, dass auch auf dieser Strecke so schnell wie möglich due Nutzung von RSA2048 einzustellen ist. Alternativ können die ECC- oder RSA3072-Zertifikate genutzt werden.

Technische Voraussetzungen im Feld

Sollte erkannt werden, dass die an einem Konnektor eingerichtete Clientsystemauthentisierung RSA2048 basiert ist, sollte diese zwar gegen eine andere ersetzt werden, jedoch gibt es im Rahmen der geplanten RSA-Abschaltungen der gematik keine Durchsetzungsmechanismen und daher auch keine Konsequenzen, wenn dies in einer LEI nicht umgesetzt wird. D.h. bestehende RSA2048 Verbindungen werden sowohl mit PTV5 als auch mit PTV6 weiterhin nutzbar sein.

Nichtsdestotrotz weist die gematik hier noch einmal darauf hin, dass gem. SOG-IS solche Verbindungen ab 2026 nicht mehr zulässig sind und manuell so zeitnah wie nur möglich angepasst werden müssen.

Die PTV6-Konnektoren erlauben für neue Konfigurationen (neue Konnektoren oder neue Verbindungen) der Clientanbindung bzw. für neu hinzugekommene Clientsysteme ausschließlich folgende Zertifikate:

• NIST-basiertes ECC-Software-Zertifikate,
• RSA 3072-Software-Zertifikate oder
• brainpool-basiertes ECC-Software-Zertifikat der gSMC-K.

Handlungsbedarf für DVOs

Die DVOs sind nicht technisch gezwungen, alle Zertifikate an der Clientsystemschnittstelle vor dem 01.07.2026 auf ECC oder RSA 3072 umzustellen.

Die gematik empfiehlt dennoch diese Zertifikate so zeitnah wie möglich entsprechend umzustellen.

Die gematik weist darauf hin, dass der Aufwand der Umstellung weg von RSA 2048 basierter Authentisierung der Clientsysteme abhängig von der Situation der jeweiligen LEI ist und die Umfänge stark variieren können (Anzahl Clientsysteme, Anzahl der Arbeitsplätze, Vorhandene Konfiguration gem. Kapitel "Ausgangslage", technische Fähigkeiten der Clientsysteme). Es wird empfohlen, dass ein DVO diese Arbeiten im Vorfeld plant, indem er sich die vorliegende Konfiguration der LEI anschaut und daraufhin erforderliche Aufwände ableitet. Damit können eventuelle Ausfälle in der LEI wegen unterschätztem Aufwand etc. vermieden werden.

Wir freuen uns jederzeit über Hinweise und Feedback, um diesen Leitfaden aktuell und so zielführend wie möglich zu halten! 

Anfragen zur RSA/ECC-Migration

Allgemeines Anfrageportal - Serviceprojekt