VonDoczuDoc.de

Hallo in die Runde,

nach einem Konnektortausch gab es natürlich auch ein neues TLS-Zertifikat. In TurboMed ist das problemlos installiert, aber wie gebe ich das dem neuen KIM 1.5 Client mit (CGM-Version, also kein Standalone-Client)?

Viele Grüße
Thomas

Vermutlich durch Deregistrierung und Neuregistrierung als Administrator in TM auf dem Server

Das ist ein Mist... Es geht hier um einen Rechenzentrumskonnektor, dessen SMC-K abgelaufen ist (bzw. ablaufen wird). Deshalb wurden wir auf einen neuen umgezogen, der auch eine neue IP-Adresse hat. In TM alles kein Problem - läuft alles.

Wenn ich jetzt in Praxisdaten->KIM gehe, sehe ich alle grünen Sonnen. Ich kann aber weder Deregistrieren noch Registrieren, weil er jedes Mal mit dieser Fehlermeldung reagiert:

3019 - Der angegebene Konnektor kann nicht erreicht werden. Bitte stellen Sie sicher das [sic] der Konnektor angeschaltet ist und unter der angegebenen IP-Adresse erreicht werden kann.

Beim Registrieren zeigt er mir jedoch zunächst (in grau) die Konnektordaten - und da stimmt die IP.

Ich würde vermuten, dass ich in irgendeiner Konfigurationsdatei noch Verweise auf die alte IP-Adresse des Konnektors finde... weiß jemand, wo?

Viele Grüße
Thomas

Hallo Thomas,
vieleicht weist eine der Routen am Server noch auf die falsche alte Konnektor-IP. In diese Falle sind wir schon mal getappt.

Hallo Thomas,
ich stehe auch vor diesem Problem. Wie konntest du das Problem lösen?

Mir würde spontan in den Sinn kommen:

1) Dienst beenden (CGM KIM...)

2) Dann unter dem folgenden Ordner die drei u.g. Ordner wegschieben:
C:\Programme\_CGMKIM15_\ (Meist CGM KIM1.5)
-> data
-> temp
-> logs

3) Dienst wieder starten

4) TM neustarten und KIM neu einrichten.

WENN das klappt, ist es der einfachste Weg. Ansonsten gibt es einen Plan B, auf den ich aber nur per PN eingehe...

Hallo FortiSecond,
danke für den Hinweis. War leider nicht erfolgreich. Es ist jetzt zwar die obige Meldung weg, aber KIM lässt sich nicht (mehr) einrichten. KIM kann sich nicht mit dem Konnektor verbinden, Karten werden nicht gefunden.

Nur in Kürze / für´s Forenprotokoll...
Wie in PN beschrieben: KIM-CM mit dem Installer einmal neu installieren.

FortiSecond hat geschrieben: ↑Montag 1. September 2025, 09:15 Nur in Kürze / für´s Forenprotokoll...
Wie in PN beschrieben: KIM-CM mit dem Installer einmal neu installieren.

Genau hier hänge ich jetzt auch fest. Nach Deregistrierung KIM, Clientzertifikat von RSA-2048 auf ECC leuchten alle TI-Anzeigen grün.

KIM-Registrierung scheitert zuerst. weil Konnektor angeblich nicht erkannt wird.

Nach Beenden des KIM Dienstes -> Umbenennen der o.g. drei Verzeichnisse data, temp, log und starten des KIM Clients zeigt leuchtet der KIM-Client beim Registrierungsvorgang 3x rot (weder initialisiert, entsperrt, noch Zertifikat ok).

Was tue ich jetzt bloß??? Danke, hier klemmts jetzt richtig, DocET

Bei der KIM-Registrierung kommt dann der Fehler ""3002 - Die Clientmodul Datenbank ist nicht entschlüsselt".

Danke für jeden HInweis, wie ich KIM wieder zum Laufen bekomme (hätte ich bloß nicht von RSA-> ECC umgestellt s.o).

Bei mir kommt auch der Fehler 3002

Konnte das jemand lösen?

Aktueller Stand: Alles auf ECC umgestellt.
eRezept geht auch - KIM ist grün aber eArztbrief schreiben führt zu Absturz.

KIM habe ich nach Serverneustart erst aus den TM Setup Dateien mit dem Installer deinstalliert, Server neugestartet, KIM installiert, TM mit Admin-Rechten gestartet und dann dem Migrationsdialog zugestimmt. Weitere Änderungen habe ich danach bisher nicht gemacht

eAU funktioniert nicht, weil die Adressen der Krankenkassen nicht ermittelt werden können. Hat dafür jemand eine Lösung?

Also, nach dem die Deinstallation und Neuinstallation von KIM geklappt hat, ist es offensichtlich (wie auch an anderer Stelle geschrieben) so, dass LDAP bei mir noch nicht mit ECC funktioniert. Konnte das jemand lösen?

Wenn ich das Zertifikat für die Authentifizierung des Konnektors wieder auf RSA zurückstelle (und dann wieder KIM die- und neuinstalliert), geht alles.
Das Zertifikat zur Authentifizierung des Clients klappt mit ECC.

Folgende Schritte habe ich gemacht:

Auf ECC Zertifikat für Authentifizierung des Konnektors in Kocobox umgestellt:
- Unter Verwaltung - Clientsysteme im Abschnitt "Authentisierung Konnektor" ECC auswählen
- Danach unter VPN - Registrierung die Re-Registrierung am VPN-Zugangsdienst (ECC) durchführen. Einfach entsprechend im Dropdown den SMC-B auswählen
- Kocobox neustarten
- CBOX Konfiguration unter Sonstiges - Wartung - CGM ePA - CBOX Anbindung - Daten neu übermitteln (wichtig, damit ePA geht)

KocoBox neues ECC Client Zertifikat erstellt:
- in Kocobox unter Verwaltung - ClientSysteme das bestehende RSA TurboMed Zertifikat löschen und Anlegen des Zertifikates mit ECC (secp256r1)
- Download des Zip Files, Zip File auf Server laden und entpacken
-Bei Start von TurboMed ist auf Grund des nun falschen Zertifikates keine Verbindung zu Konnektor möglich
- daher unter Sonstiges - Praxisdaten - eGK das Zertifikatsverzeichnis öffnen und die oben abgelegte Datei verwenden. Passwort ist in der Passwortdatei
- es kam dennoch eine Fehlermeldung
- Server Neustarten
- Start von Turbomed - Verbindung zu Konnektor wieder möglich
- CBOX Daten erneut übermitteln, damit auch ePA wieder geht


Jetzt geht KIM nicht, daher:
- KIM Dienst beenden
- KIM Masterpasswort löschen (ist im Forum beschrieben)
- aus einer TM Download Version den KIM Installer für die Deinstallation von Kim verwenden
- Server Neustarten
- KIM mit Hilfe des Installers installieren
- TM mit Admin Rechten starten und der vorgeschlagenen KIM Migration zustimmen.
- Jetzt funktioniert der Abruf von KIM
- Senden u.a. von eArztbrifeden und eAU geht nicht, da keine Adressen mit Hilfe des LDAP Servers gefunden werden können.
- Gibt es dafür eine Lösung oder müsste etwas anders gemacht werden?
Das ist das einzige, was nicht mit ECC klappt (Alles mit TM 25.3.2.6653)


Vielen Dank für alle Ideen!

fschmidt hat geschrieben: ↑Samstag 22. November 2025, 15:37 - Senden u.a. von eArztbrifeden und eAU geht nicht, da keine Adressen mit Hilfe des LDAP Servers gefunden werden können.
- Gibt es dafür eine Lösung oder müsste etwas anders gemacht werden?
Das ist das einzige, was nicht mit ECC klappt (Alles mit TM 25.3.2.6653)


Vielen Dank für alle Ideen!

Das ist bisher auch hier immer mal wieder ein Knackpunkt gewesen bzw. ein Trial and Error.

Es gibt im Konnektor die Option (bei den Clientsystemen), LDAP auch ohne Authentifizierung zu erlauben. Ich bin mir gerade nicht ganz sicher, ob das aktiv sein soll oder nicht. Irgendwie scheint CGM CONNECT da querzuschlagen oder zumindest nicht nachvollziehbar zu handeln.

Vom Sicherheitsgedanken her müsste LDAP zwingend verschlüsselt laufen (dann Port 636 statt 389), jedoch scheint das nicht immer zu funktionieren: Während Thunderbird beides verträgt, war es bei TM beim letzten Versuch vor Monaten nur unverschlüsselt funktional. Hab´s noch nicht mit ECC probiert. Das ist erst in einigen Tagen auf dem Zettel.
Vielleicht einfach mal umstellen. Und vielleicht hat´s bisher bei mir nicht geklappt, weil ein Konnektorneustart erforderlich sein könnte. Ein Secunet sagt immer ganz deutlich, wenn er für etwas einen Neustart will. Kocobox m.W. nicht. Leider.