eRezept Fehlermeldung

[nmndoc]

Hallo,

obwohl es schon mal funktioniert hat, erhalten wir beim Signieren des eRezeptes folgenden Fehler (siehe Bild).

Hat Jemand eine Idee? Dachte an die TLS-Verbindung/Kommunikation mit dem Konnektor ... aber wie gesagt hat es auch schon funktioniert.
Man importiert das Zertifikat doch nicht an jedem Client sondern nur einmal in den Konnektoreinstellungen in TM (Server)?

[nmndoc]

... der Versand der eAU scheint auch nicht mehr zu funktionieren ... KIM-Modul Wartungslauf hatte ich eigentlich gemacht / Zertifikat hinterlegt

[nmndoc]

ok ... noch einen Schritt weiter. Scheinbar fehlt dem Kim-Dienst das Passwort für das Zertifikat/Zertifikatsspeicher - starte ich über die Batch-Datei den dienst von Hand, fragt er danach.
ich hatte die Konfiguration via "\TurboMed\ExtPrg\KIM\Client Module\config-cm-windows(32bit).bat" angepasst - war das falsch, fehlt noch was? zB D:\TurboMed\ExtPrg\KIM\Kim Assist? Wenn ich den aufrufe ist aber alles leer...?

[bofh]

Wurde am TLS-Zertifikat rumgefummelt (ausgetauscht)? Falls ja, dann sind Sonderzeichen im Passwort eine der Fallen. Die andere ist ECC, muss RSA sein.

[scottsdalegirl]

Zitat FortiSecond:

Interface Kocobox:

"Wenn unter "Aktive Bestandsnetze" der Eintrag für gematik kein X in der zweiten Spalte hat, dann vorn einmal klicken und ÜBERNEHMEN nicht vergessen. Ich neige dazu, anschließend die TI-Verbindung ab- und wieder aufzubauen oder gleich den Konnektor neu zu starten."

[FortiSecond]

ok ... noch einen Schritt weiter. Scheinbar fehlt dem Kim-Dienst das Passwort für das Zertifikat/Zertifikatsspeicher - starte ich über die Batch-Datei den dienst von Hand, fragt er danach.
ich hatte die Konfiguration via "\TurboMed\ExtPrg\KIM\Client Module\config-cm-windows(32bit).bat" angepasst - war das falsch, fehlt noch was? zB D:\TurboMed\ExtPrg\KIM\Kim Assist? Wenn ich den aufrufe ist aber alles leer...?

Bei Nutzung vom cm-config für die TLS-Einrichtung sieht es funktional aus, aber das Zertifikatspasswort wird nicht in der config-Datei hinterlegt bzw. die neuere Variante (mit WCM) nicht angelegt. Letzteres soll der Wartungslauf in TM machen, klappt aber nicht immer.

Im Notfall bzw. um es überhaupt erst einmal wieder lauffähig zu bekommen, hilft folgende Hauruck-Methode:

X: / TurboMed / ExtPrg / KIM / Client Module / conf / cm-config.properties
KONNEKTOR_KEYFILE=X\:\\TurboMed\\ExtPrg\\KIM\\zert\\NAMEDESZERTIFIKATS.p12
USE_WCM=false
KONNEKTOR_KEYPIN=PASSWORTDESZERTIFIKATS

Robuster Umgang mit Sonderzeichen im Zertifikatspasswort gewünscht? Siehe viewtopic.php?p=62877#p62877

[nmndoc]

Bei Nutzung vom cm-config für die TLS-Einrichtung sieht es funktional aus, aber das Zertifikatspasswort wird nicht in der config-Datei hinterlegt bzw. die neuere Variante (mit WCM) nicht angelegt. Letzteres soll der Wartungslauf in TM machen, klappt aber nicht immer.

Im Notfall bzw. um es überhaupt erst einmal wieder lauffähig zu bekommen, hilft folgende Hauruck-Methode:

X: / TurboMed / ExtPrg / KIM / Client Module / conf / cm-config.properties
KONNEKTOR_KEYFILE=X\:\\TurboMed\\ExtPrg\\KIM\\zert\\NAMEDESZERTIFIKATS.p12
USE_WCM=false
KONNEKTOR_KEYPIN=PASSWORTDESZERTIFIKATS

Robuster Umgang mit Sonderzeichen im Zertifikatspasswort gewünscht? Siehe viewtopic.php?p=62877#p62877

danke - so in der Art dachte ich mir das schon. Werde dastesten. Ich hatte mir jetzt beholfen, indem ich den Dienst via Batch von Hand gestartet habe und er dann das PW abgfragt - aber dann läuft es eben als Anwendung und nicht als Dienst.
Man könnte sich natürlich fragen, wo der Sinn ist, das Zertifikat mit einem PW zu schützen wenn das dann im Klartext in der Konfiguration steht ... daher wäre mein nächster Versuch gewesen den PW-Schutz zu entfernen (import/export ohne PW) aber evtl. fehlt das dann wieder anderen ...

[FortiSecond]

Bei Nutzung vom cm-config für die TLS-Einrichtung sieht es funktional aus, aber das Zertifikatspasswort wird nicht in der config-Datei hinterlegt bzw. die neuere Variante (mit WCM) nicht angelegt. Letzteres soll der Wartungslauf in TM machen, klappt aber nicht immer.

Im Notfall bzw. um es überhaupt erst einmal wieder lauffähig zu bekommen, hilft folgende Hauruck-Methode:

X: / TurboMed / ExtPrg / KIM / Client Module / conf / cm-config.properties
KONNEKTOR_KEYFILE=X\:\\TurboMed\\ExtPrg\\KIM\\zert\\NAMEDESZERTIFIKATS.p12
USE_WCM=false
KONNEKTOR_KEYPIN=PASSWORTDESZERTIFIKATS

Robuster Umgang mit Sonderzeichen im Zertifikatspasswort gewünscht? Siehe viewtopic.php?p=62877#p62877

danke - so in der Art dachte ich mir das schon. Werde dastesten. Ich hatte mir jetzt beholfen, indem ich den Dienst via Batch von Hand gestartet habe und er dann das PW abgfragt - aber dann läuft es eben als Anwendung und nicht als Dienst.
Man könnte sich natürlich fragen, wo der Sinn ist, das Zertifikat mit einem PW zu schützen wenn das dann im Klartext in der Konfiguration steht ... daher wäre mein nächster Versuch gewesen den PW-Schutz zu entfernen (import/export ohne PW) aber evtl. fehlt das dann wieder anderen ...

PW-Schutz entfernen: Das entschützte Zertifikat ist parallel zu dem originalen Zertifikat verwendbar und sollte natürlich nur eine Übergangslösung sein.

Das Klartextpasswort war von Anfang an nicht sinnvoll und (vermutlich) der Eile geschuldet, als erster Anbieter am Markt zu sein. Warum nicht direkt ein Veto von der gematik kam, weiß ich nicht, und ich will lieber nicht öffentlich mutmaßen, wie CGM damit durchgekommen ist. Es war andererseits aber nicht so gravierend, weil damals noch nicht zwingend per TLS verbunden wurde.

CGM hat aber schnell die Nutzung des Windows-Zertfikatspeichers (WCM) eingeführt. Damit ist das Klartextpasswort überflüssig geworden. Wenn das KIM-CM im WCM-Modus funktioniert. Und da gibt es bis heute auch im Standalone-KIM-CM allerlei Merkwürdigkeiten.
Immerhin scheint es auf eine Art gut zu klappen: Per TLS-Wartungslauf, nachdem man TM umgestellt hat, während das KIM-CM noch ohne TLS lief. Dann scheint WCM genutzt zu werden.



Weshalb ich nun sukzessive in allen betreuten Praxen CGM-KIM durch ein anderes Produkt ersetze, schreibe ich die Tage an anderer Stelle.