Hallo:-)
hab grad gesehen, dass ich vom 9.12. einen Logeintrag habe, dass die Kocobox über die Schlüssellänge des Clientzertifikats meckert - im Moment das ganze nur als status "Info" und läuft alles- kann ich das dauerhaft ignorieren oder gibt es ggf. irgendwann einen mir nur noch nicht bekannten Tag X, ab dem dann von jetzt auf gleich gar nichts mehr läuft, weil die Kocoxbüchse das dann ggf. gar nicht mehr akzeptiert?
Hatte mir eigentlich geschworen, nachdem das Client-Zertifikat jetzt ja auch endlich 5 Jahre und nicht mehr nur 1 Jahr gilt, das auch voll auszukosten und war froh, hier keine schnell wiederkehrende Baustelle zu haben;-)



Allen ein schönes Wochenende und schönen 3. Advent:-)

Hi,

Den selbigen Eintrag sehe ich auch regelmäßig bei uns in d Kocobox.

Derzeit ignoriere ich ihn, aber vielleicht hat jemand mehr Infos darüber.

Gruß
Marcus

Laut gemSpec_Kon (Konnektor-Spezifikation der Gematik) bedeutet EC_TLS_Client_Certificate_Security:
"Das für die Authentifizierung gegenüber dem Clientsystem konfigurierte Zertifikat hat ein Sicherheitsniveau von weniger als 120bit. Zu verwenden ist ein RSA -Zertifikat mit mindestens 3000 bit Schlüssellänge oder ein ECC Zertifikat."
Das RSA-Zertifikat ist nur 2048 Bits lang. Mit 3072 Bits würde die Fehlermeldung nicht mehr kommen, oder eben wenn man ein ECC-Zertifikat einsetzt.
Im Moment ist die Meldung nur eine Info, die man zumindest die nächsten Monate ignorieren kann. Ansonsten ist nicht so wirklich klar, ob die RSA 2048-Zertifikate für die Client-Authentifikation bis Ende 2025 abgeschafft werden. Sicher ist, dass die Zertifikate in der TI-Infrastruktur ab 2026 nur noch ECC-basiert sind (Vereinbarung der Gesellschafter).
Sicherheitshalber würde ich mal davon ausgehen, dass wir ab 2026 auch für die Client-Authentifikation besser auf ECC umsteigen. Es ist zwar noch nicht gesagt, dass die Gematik uns das vorschreibt, aber da sind ja noch die Konnektor-Hersteller, die ja nicht unbedingt bei den vorgeschriebenen Mindestanforderungen bleiben müssen sondern auch für sich höhere Standards festlegen können, was die Kommunikation zwischen Primärsystem und Konnektor angeht.

Ich würde daher:
1. die RSA-2048-Zertifikate erst einmal bis auf Weiteres benutzen
2. bei einem Wechsel gleich auf ECC gehen und keine neuen RSA-wielangauchimmer bauen

Doch noch was gefunden: die aktuelle gemSpec_Kon 5.24 https://gemspec.gematik.de/downloads/gem...on_V5.24.0.html schreibt vor, dass ein Konnektor Zertifikate mit RSA-2048 nicht mehr erstellen oder Importieren darf, macht aber eine Ausnahme beim Einspielen des Backups oder bei einem Upgrade der Firmware, wenn das Zertifkat schon vorhanden ist (darf dann weiter genutzt werden).

-> Abschnitt A_21811-04 - Vorgaben für generierte und importierte Schlüssel und Zertifikate in der gemSpec_Kon

Es ist also sehr wahrscheinlich, dass mit dem nächsten Firmware-Update keine RSA-2048-Zertifikate mehr importiert werden können. Die Weiternutzung ist aber in der gemSpec_Kon noch erlaubt. RSA-3072 muss in der jetzigen gemSpec_Kon unterstützt werden.

Ich habe eine Bestätigung der Entwicklung bekommen, dass es sich genauso verhält, wie swobspace angibt.
Die JSON Schnittstelle ist dann nicht mehr für das Hochladen oder Erstellen dieser Zertifikate geeignet.

Ich habe grad nochmal mit dem Support dazu telefoniert:

also die sagen grad wieder, es ist auch NICHT sicher, dass Bestands-RSA über Ende 2025 hinaus laufen =) heißt:
wer noch RSA beim Clientzertifikat hat, darf diesmal nicht wegen Laufzeit sondern jetzt wegen Umstellung ECC zu 2026 das Clientzertiifkat mal wieder erneut vorzeitig tauschen- zu früh gefreut dass 5 Jahre bis nächstes Ende laufzeit Konnektor Ruhe ist ;-) und besondere Freude für uns Charly User, wo man ja wegen dieser Aktion dann alle Aufrufkontexte nochmal neu machen kann um an die Stelle ranzukomen , wo der Zertifikatspfad vermapped wird- vielleicht geht es, es 1:1 gleich zu benennen und dann den Pfad so zu lassen- ich weiß aber nicht ob Charly wirklich nur die Datei nach Zertifikatsname anschaut und solange es im Pfad am Ende der Fahnenstange liegt , immer nehmen wird ...einen Versuch ist es wert;-)

! CGM hat nochmal drauf hingewiesen, unbedingt vorher klären, bevor man auf ECC wechselt, ob das Primärsystem schon ECC kann- lt. Mail vom 1.8. von Solutio kann Charly ab der 9.34.1. ECC
hier ein Link zu weiteren Informationen von Solutio dazu: https://www.solutio.de/2025/07/31/ecc-ko...der-ti-pflicht/

Hab m ich auch schonmal erkundigt vorsorglich, wie das wäre mit Zertifikatstausch hier:
also man soll einfach HIER neues Zertifikat generieren:


Dann poppt das hier auf und das genau so lassen, wo es default steht, nur Namen vergeben:
hierbei !! wenn ich das eben richtig verstanden habe: wenn man bis hierhin vorsorglich noch das alte Zertifikat drin lässt, taucht das 2. daneben auf und kann zu Konflikten führen wenn es wie s.o. von mir angedacht gleich heißt- also doch entweder umbenennen oder vorher (hab ich nicht durch Hotline absegnen lassen, ob das auch geht) viell. das alte Zertifikat vorher löschen - meine aber dass das geht, weil wir das früher auch beim jahrestausch so gemacht haben...nur eben was weg ist, ist dann weg;-)


Dies mit Zertifikat weiter unten Authentisierung Konnektor, da müssen wir wohl nichts machen, das springt , wenn das Client Zert. ECC ist, auch automatisch wohl auf ECC um, wird man sehen:

Welcher Konnektor war das nochmal bei Ihnen? Nicht kobobox, oder?
Bei der Kocobox kann man "Authentisierung verpflichtend" abwählen, dann ignoriert die Kocosbüchse das auch = erste Hilfe, wenn das Zertifikat nicht mehr ok - vielleicht kann man das auch bei Ihrem Konnektor deaktivieren oder es ist default deaktiv und deshalb läuft es im Moment trotzdem

Frage wäre ? - wenn es aber so eingestellt ist auf dieser Ebene Konnektor, dann könnte das ja durchaus auch bedeuten, dass es auch 2026 ohne neues Zertfizikat weiterläuft :-) mit Fehlermeldungen aber eben läuft;-) bin gespannt, was Sie berichten werden...

Update
laut 2nd Level CGM heute wurde mir gesagt, es stehe jetzt fest, dass doch RSABestandsclientzertifikate Konnektor weiterlaufen werden - somit ist die Variante die @swobspace HIER in #4 berichtet hat, nun wohl doch die richtige- Aussage CGM Stand von heute 12.9.2025:-)