Info ECC Serverauthentifizierung

[lcer]

Hallo,

Ich habe scheinbar erfolgreich auf ECC umgestellt. Allerdings funktioniert die ePA nur, wenn man die Einstellung des Konnektorautentifizierungszertifikat auf C.AK.AUTH belässt und nicht auf C.AK.AUTH2 umstellt.

Mit C.AK.AUTH2 funktioniert bei mir mit Turbomed ECC Clientzertifikat:
- Versichertenstammdatenabgleich, eRP
- KIM über KV.dox

Die ePA nicht. Es kommt zu einer Fehlermeldung beim Übertragen der Konnektor-Konfiguration an die CBOX, die besagt, dass das Konnektorzertifikat nicht gelesen werden kann. Nach Rückumstellung auf C.AK.AUTH geht es, also:

C.AK.AUTH funktioniert bei mir mit Turbomed ECC Clientzertifikat:
- Versichertenstammdatenabgleich, eRP
- KIM über KV.dox
- ePA / CBOX

Das bedeutet, dass ECC Zertifikate zur Authentifizierung des Clientsystems (Turbomed = Clientauthentifizierung) funktionieren, das Clientsystem (Turbomed) den Konnektor nur über ein RSA-Zertifikat authentifiziert (Serverauthentifizierung). Zumindest bei der ePA. Ob Turbomed in den anderen Anwendungsfällen den Konnektor überhaupt identifiziert, oder ob das einfach nicht passiert, weiß ich nicht. Ich vermute jedoch letzteres. Hätte man das für die anderen Anwendungen sauber programmiert, wäre vermutlich auch bei CGM irgendjemand an die ePA gedacht. Ich nehme mal an, dass die Sicherheitsbedenken, die vor einem Jahr die Einführung der ePA verzögert hatten dazu führten, dass das Serverauthentifizierungs-Feature für die ePA aktiviert wurde, während es bei den anderen Anwendungen nie aktiviert war. Und dabei hat man ECC halt vergessen.

Da die RSA-Ära gerade verlängert wurde, hat CGM ja noch so 3-5 Updates Zeit nachzubessern.

Grüße

lcer

P.S. nach dem Umschalten des Zertifikats muss der Konnektor neu gestartet werden.

[FortiSecond]

Kann ich so bestätigen.

(Hinweis: Es geht hier NUR um die Konnektorauthentifizierung, also das, womit der Konnektor sich ausweist gegenüber dem Clientsystem. ALLES kann auf ECC aufgerüstet werden (TM mit neuem Clientzertifikat, KIM-CM usw.) mit Ausnahme dieser einen Einstellung.)


Mit C.AK.AUTH2 scheitert die CBOX "in den meisten Fällen". Ich habe genau EIN Gegenbeispiel beobachtet, wo auf Anhieb alles läuft inkl. AUTH2 (ECC) konnektorseitig.
Grundsätzlich ist es also lösbar, aber nicht mit den üblichen Hausmitteln.

Was klappt, wenn alles auf ECC umgestellt ist und der Konnektor C.AK.AUTH (RSA) nutzt:
Übermitteln der ePA-Einstellungen an die CBOX klappt. HCS.CBOX neustarten = läuft.
Anmerkung zu Deiner Vermutung: TM übermittelt das Zertifikat des Konnektors an die CBOX (wird als Trusted in der .json hinterlegt).

Was nicht klappt, wenn alles auf ECC umgestellt ist und auch der Konnektor C.AK.AUTH2 (ECC) nutzt:
Übermitteln der ePA-Einstellungen an die CBOX klappt nicht. Hier gibt es verschiedenen Fehlermeldungen, die man provozieren kann.
Manchmal kann bereits TM den Konnektor beim Start nicht finden. Aber selbst wenn (und dann gehen KIM und VSDM und so), dann gibt´s die Betonwand bei der ePA/CBOX -> WENN TM übermittelt, dann unvollständig - so hat die CBOX hinterher in der .json-Datei kein Konnektorzertifikat.
Ergänzend gibt es dann noch Problemstellungen mit dem IdP-Dienst. Ich habe so einige CBOXen zurückgesetzt, d.h. inkl. Löschung der jwtcredentials.json (oder so ähnlich) und die dann "irgendwie" wieder mit TM eingerichtet. Aber auf RSA, weil TM sonst... oh damn it.


Kurzgefasster Wink in eine Richtung (hab gerade keine Zeit, das auszuführen, aber die Idee...):
Bei betroffenen Clients kriegt man mit dem Firefox keine Seite unter https://konnektor-ip/connector.sds, weil keine Einigung über Verschlüsselung möglich. FF meckert. Und das gilt für´s gesamte System. Würde DAS funktionieren, wäre der Rest sicherlich auch OK.

Bei der Einrichtung der CBOX kennen wir die Meldung zum Microsoft-Kryptoprovider. Daher ist davon auszugehen, dass Windows nativ die NIST-Kurven nicht verarbeiten kann. An dieser Stelle wird also eine Windows-Funktion bemüht (ähnlich wie WCM damals bei KIM teils rätselhaft war und man lieber das Zertifikat im KIM-CM hinterlegt hat).
Wir reden also über Windows-Funktionen, die die Konnektorverbindung verstehen und übersetzen müssen.
Solange also die connector.sds (Dienstverzeichnis des Konnektors, nicht zu verwechseln mit dem Verzeichnisdienst LDAP) nicht per TLS abrufbar ist, hat TM mit CBOX keine Chance.

Da ich EINEN Kunden habe, bei dem es mit dem alten und diesbezüglich "eigentlich besonders problematischen" Windows Server 2016 völlig problemlos und ohne invasives Vorgehen direkt funktioniert, werde ich mir die Tage genauer ansehen, was dort falsch gelaufen ist hier so außergewöhnlich ist.
Dort ist ALLES auf ECC inkl. der o.g. Einstellung und läuft.
Vorhanden sind CGM KIM, CGM TM, lokale Kocoloco-Box, ORGA-Terminals - also das Idealbild.

[lcer]

Hallo,

Der kv.dox KIM-Clientkonnector nutzt die Windows Kryptographiefunktionen. Da er auf dem selben Server ECC verarbeiten kann würde ich erwarten, dass es mit der CBOX auch geht.

Grüße

lcer