Keine Verbindung zu Konnektor

[ebitdd]

Hallo,

ich habe eine Praxis auf einen anderen Konnektor umziehen müssen (Art Praxisgemeinschaft).

Infomodell alles eingetragen, Clientzertifikat erstellt (alle Möglichkeiten) und im TurboMed eine neue Konnektor Einstellung angelegt.

Egal was ich mache ich bekomme die Meldung 'Die Verbindung zum Konnektor (KoCoBox) kann nicht hergestellt werden.'.

Obwohl alles konform eingerichtet ist.

Die Fehlermeldung die ich TurboMed entnehmen kann ist:

1 16508 22104 ERROR 2026.04.09 11:28:02.061 Connector.cpp 1077 0 Error: 9830 = SOAP-Fehler Nummer 30 beim HTTP-Senden (https://XX.XX.XX.1:443/connector.sds).
1 16508 22104 ERROR 2026.04.09 11:28:02.061 Connector.cpp 1077 0 Error: 9830 = SOAP-Fehler Nummer 30 beim HTTP-Senden (https://XX.XX.XX.1:443/connector.sds).
SSL_ERROR_SSL
error:0A000086:SSL routines::certificate verify failed
unable to get local issuer certificate

Jemand eine Ahnung?

[lcer]

Hallo,

zunächst: kannst Du den Konnektor vom Turbomed-Server aus per https auf das Webinterface erreichen?

wenn ja: Ist auf dem Konnektor Authentifizierungsmodus-SOAP auf Zertifikat eingestellt?

Ist das der alte Server, von es schon mal geklappt hat?

Grüße

lcer

[ebitdd]

Managementoberfläche ist erreichbar. SOAP ist auch auf Zertifikat gestellt und ja der PC ist der selbe von dem es schon mal funktioniert hatte. Hab auch schon alle Zertifikate (brainpool, secp,rsa3072) durch probiert. Vom KIM CM komme ich auch an den Konnektor ran mit der Konfig...

Einstellungen unter Verwaltung > Clientsysteme

Zugriff auf Dienstverzeichnisdienst
auch via HTTP ermöglichen: aus
Verbindung nur via TLS: ein
Authentisierung Clientsystem
Authentisierung verpflichtend: ein
Authentisierungsmodus-LDAP: ein
Authentisierungsmodus-SOAP: Zertifikat

clientzertifikate:

2xTurboMed (einmal die eine Praxis und dann die zweite Praxis TurboMed2 quasi)

Konnektorzert ist auf ECC

[FortiSecond]

Bitte auch im WCM (sowohl Benutzer als auch Computer) den alten Konnektor entfernen.
Und unter Turbomed/Daten/Var/Konnektor ggf. "aufräumen".
Im Konnektorlog nachsehen (System), ob da was Hilfreiches zu finden ist.
Gleiches Netzwerk? Sonst ggf. Intranetrouten relevant für Konnektor.

Aber die Fehlermeldung deutet darauf hin, dass das Clientzertifikat nicht gelesen werden kann, potenziell weil privater Schlüssel nicht korrekt ist.
Es gibt Situationen, in denen der Konnektor "leere" Zertifikate rausgibt, dann hat der Download nur unter 1.000 Bytes. Das kann auch in die Irre führen.
Was die Kocobox nicht mag oder kann, sind mehrere Zertifikate (Typen) für EIN Clientsystem (gleicher Name, z.B. TURBOMED).

Ach, und vorsorglich die Box neustarten natürlich...

[ebitdd]

Danke erstmal fuer die ausfuehrliche Antwort.

Anmeldeinformationsverwaltung ist leer. Befinden sich im gleichen Netzwerk.

Unter Daten/Var/Konnektor hab ich jetzt den Konfiguration und Zertifikate-Ordner geleert. Kann/soll ich die anderen auch leer machen.

Als CS hab ich einmal TurboMed und als zweites Mueller_TM angelegt, weil ich mir schon gedacht hab das die Kocobox zwei TMs mit gleichem Namen nicht moegen wird. Ausgegebene Zertifikate alle 2KB, bei den PW bin ich mir immer noch unsicher: muss ich da immer noch auf die Zeichen achten (mit bestimmten Sonderzeichen wie *&=+\ gab es ja Probleme frueher) und den Trick mit Import & Export des Zertifikats. Hab ich aber auch immer provisorisch gemacht.

Der Systemlog zeigt nach Neustart eigt nur uebliche erste Verbindungsprobleme (mit KT,VPN) die aber nach paar Minuten alle da sind und sonst nichts.

Ich hatte bei einer anderen Praxis bei uns das gleiche Problem und da hat gereicht die Konnektor-Konfiguration im TM zu loeschen und neu zu erstellen.

Kann es wirklich die CS-ID sein? Aber wenn ich die in TM anpassen kann sollte das doch gehen oder

[FortiSecond]

Kann es wirklich die CS-ID sein? Aber wenn ich die in TM anpassen kann sollte das doch gehen oder

Zwingend - 2 x TURBOMED klappt nicht. Im Infomodell wären die beiden TM nicht unterscheidbar, d.h. der Konnektor kann nicht zuordnen, was zum wem gehört.
Zu EINEM Clientsystem gehört EIN Clientzertifikat.
Das wäre sonst wie zwei namensgleiche Personen mit gleichem Geburtsdatum...

[ebitdd]

Ich versteh TurboSch**** nicht mehr... wenn ich das Konnektorzertifikat auf RSA2048 umstelle kein Verbindungsproblem mehr.

Zuvor lief der Server bzw. das Setup auch auf RSA2048 (Konnektor) bis zum Wechsel, aber das kann doch nicht sein das er das ECC jetzt nicht annimmt und auf eingeschnappt macht?!

Solang Clientzert auf ECC sollte es erstmal keine Einschraenkungen geben oder?

[FortiSecond]

Korrekt. Es sollte so auch erstmal mit der ePA kein Problem geben.

[nmndoc]

Kann es wirklich die CS-ID sein? Aber wenn ich die in TM anpassen kann sollte das doch gehen oder

Zwingend - 2 x TURBOMED klappt nicht. Im Infomodell wären die beiden TM nicht unterscheidbar, d.h. der Konnektor kann nicht zuordnen, was zum wem gehört.
Zu EINEM Clientsystem gehört EIN Clientzertifikat.
Das wäre sonst wie zwei namensgleiche Personen mit gleichem Geburtsdatum...

evtl missverständlich ausgedrückt ode ich verstehe es nur nicht richtig? Was genau soll mit 2x TM nicht funkrionieren? Folgendes sollte beides funktionieren:

1) Eine Praxis mit einer gemeinsamen TM Installation (unterschiedliche BSNRs) teilt sich einen Konnektor
2) Eine Praxis hat zwei gtrennte TM Installationen und teilt sich einen Konnektir

Sehe ich in beiden kein Problem, solange die Clients eindeutige/unterschiedliche Namen haben

Für 1) benötigen alle das selbe Clientzertifikat
Für 2) könnte man sicher auch unterschiedliche verwenden - aber hat m.E. keinen Vorteil. Also könnte man da auch das selbe verwenden.

Für das Infomodell ist das übrigens kein Problem wenn beide TurboMed haben. Das regelt ja die Zuordnung "Mandant".

[FortiSecond]

Öhm ja... stimmt. Da hatte ich einen Gedankenknoten.
Der Mandant ist es.

Jetzt wird es spannend, wobei ich den Fall noch nicht hatte:
Weil es zwei Praxen sind, müsste es zwei Telematik-IDs geben.
Kocobox... da war doch was... ach ja:
https://koco-shop.de/p/koco-erweiterungspaket

Und hier im Forum eine Aussage, die vielleicht in die richtige Richtung lenkt, falls sie noch aktuell ist:
viewtopic.php?p=44974#p44974

[ebitdd]

Hallo zusammen,

ich habe im letzten Telefonat mit der CGM einige interessante Informationen erhalten.

Mir ist nämlich ein anderer Konnektor abgeschmiert mit der schwerwiegenden Meldung, dass keine Verbindung zum VPN aufgebaut werden könne und das Zertifikat der gSMC-K nicht verifiziert werden könne. Dies ist wohl ein bekanntes Problem, das einen kompletten Austausch zur Folge hat. Wie es dazu kommen konnte, wurde mir allerdings nicht gesagt.

Bei der Prüfung des Konnektors wurde mir im Termin Folgendes gesagt: „Wieso sind Sie denn schon auf ECC (beim Konnektorzertifikat)? Das sollen Sie doch noch gar nicht umstellen, da TM damit Probleme hat. Dafür kommt in den nächsten Monaten noch eine Information mit begleitender Umstellung.“

Das war das erste Mal, dass ich diese Information erhalten habe.

[FortiSecond]

Bei der Prüfung des Konnektors wurde mir im Termin Folgendes gesagt: „Wieso sind Sie denn schon auf ECC (beim Konnektorzertifikat)? Das sollen Sie doch noch gar nicht umstellen, da TM damit Probleme hat. Dafür kommt in den nächsten Monaten noch eine Information mit begleitender Umstellung.“
Das war das erste Mal, dass ich diese Information erhalten habe.

Wieder so ein WTF-Moment...

Die wiedergegebene Aussage scheint zu passen.

Interessant finde ich, zumindest so beobachtet, dass
- TM mit aktiviertem ECC-Zertifikat (Konnektor, nicht bzw. auch Clientsystem) wunderbar funktioniert
- mit Ausnahme der ePA

- andere PVS, die ich an einer Kocobox sehe, KEIN Problem damit haben, wenn Konnektorzertifikat auf ECC umgestellt. Konkret ist hier beispielsweise EVIDENT (Dental) zu nennen.

Interessanterweise soll es auch ALBISse geben, die vollständig ECC machen inkl. der ePA, die dort ja auch über die HCS.CBOX läuft. Habe ich aber selbst noch nicht gesehen.

Naja, die Frist war ja 31.12.2025, nicht wahr? Die Nachfrist Mitte 2026 gilt m.W. nur für SMC-B, eHBA und (bis Jahresende) auch für gSMC-KT.


Nachtrag: Sehe gerade ein Medical Office an Managed TI (CGM Remote-Konnektor) mit konnektorseitig aktiviertem ECC... läuft übrigens einwandfrei.

[FortiSecond]

Mir ist nämlich ein anderer Konnektor abgeschmiert mit der schwerwiegenden Meldung, dass keine Verbindung zum VPN aufgebaut werden könne und das Zertifikat der gSMC-K nicht verifiziert werden könne. Dies ist wohl ein bekanntes Problem, das einen kompletten Austausch zur Folge hat. Wie es dazu kommen konnte, wurde mir allerdings nicht gesagt.

Aaalso... gemeint ist sicher SMC-K, also das Zertifikat des Konnektors selbst.

Es fällt mir schwer, eine Situation zu konstruieren, in der der Konnektor keine Verbindung zum VPN bekommt aufgrund des Zertifikats.

Ideen
- Konnektorzertifikat abgelaufen oder gesperrt/widerrufen. Eine versehentliche Sperrung wäre verwunderlich, wobei man ja schon... naja.
Hier könnte man nun schauen, was der Konnektor für ein Zertifikat anbietet, wenn man die /connector.sds aufruft. Hier kann es je nach Konfiguration sein, dass man dem Browser erst das Clientzertifikat beibringen muss, damit er vom Konnektor eine vernünftige Antwort erhält.
- Konnektor baut VPN-Verbindung auf, bekommt aber keine Verbindung zur TI -> Konnektor-Registrierung muss erneuert werden

Wurde eine Laufzeitverlängerung angestoßen? Dann kann es, wenn man nicht gerade eine DVO-Schulung hatte, durchaus ein Trial- and Error wert sein. Also Neustarts, Zertifikat wechseln, ggf. Rollback machen usw.
Es ist auch denkbar, dass das Zertifikat aus der Laufzeitverlängerung nicht anerkannt wird - wobei das eigentlich ja im Trust Center erzeugt und konnektorspezifisch per KSR bereitgestellt wird.


Ansonsten, wenn der DVO die Box innerhalb weniger Tage tauscht und keine Kosten entstehen (im Rahmen Managed TI oder im Rahmen der Garantie bei Anschaffung vor nicht allzu langer Zeit), dann... puh, man hat ja sonst nix um die Ohren. Hoffentlich drängt niemand zum Umzug auf Remote-Konnektor. Da kann sooooooooo viel Mist dranhängen (zweite IP-Range, die unter Windows echt stresst; bei Ausfall von Konnektor, Internet, oder VPN nicht einmal Karten einlesen; Neustarts ohne Vorankündigung während der Praxiszeiten...).

[ebitdd]

Ich muss mich präzisieren: beim Versuch mithilfe der SMC-B den Konnektor zu reregistrieren ist der Fehler aufgetreten. Hab ihn nochmal rausgesucht:

Code: Alles auswählen

Die De-/Registrierung am VPN-Zugangsdienst ist fehlgeschlagen.
RegSrv gab Fehler zurück:
[
Registration Server Error, ErrorCode: 7021,
 ErrorText: Pruefung des SMC-K-Zertifikats des Ausstellers C=DE/O=gematik GmbH/OU=Komponenten-CA der Telematikinfrastruktur/CN=GEM.KOMP-CA7 mit der Seriennummer 2E0A58 nicht erfolgreich,
Severity: Error, ErrorType: Security,
EventID: any-soap-instance@2026-04-20T14:11:46.246+02:00,
Instance: any-soap-instance, LogReference: reg-ti-01.z2.pu.mgmt.fra.telemed:f307d8fc-6103-46a8-b9b9-80d9af4cb1a3,
CompType: VPN-Zugangsdienst
].

Die Laufzeitverlängerung mit der CGM ist schon vor einer Weile erfolgt und der Konnektor lief problemlos bis vorgestern. Glücklicherweise gibt es an dem Standort eine weitere Praxis mit Konnektor im gleichen Netz, auf die ich ausweichen konnte.

Der Termin zum Wechsel ist jetzt am Donnerstag. Das sollte im Rahmen unseres Servicevertrags (wir haben CGM Managed enthalten) eigentlich kostenfrei passieren. Ich bin gespannt, ob der Servicetechniker mir sagen kann, was das Problem ausgelöst hat.

[FortiSecond]

Fehler 7021:
Prüfung des SMC-K-Zertifikats des Ausstellers <Aussteller> mit der Seriennummer <Seriennummer> nicht erfolgreich.

Also ein Zertifikat des Ausstellers (gematik) wird im Konnektorzertifikat referenziert. Und die Prüfung des Zertifikats der gematik scheitert. Soso...

In diesem Fall geht es um
"GEM.KOMP-CA7"

Mal schauen auf https://download.tsl.ti-dienste.de/SUB-CA/
und dort dann https://download.tsl.ti-dienste.de/SUB- ... A7.der.txt
notBefore=Dec 2 08:35:25 2021 GMT
notAfter=Nov 30 08:35:24 2029 GMT

8 Jahre Laufzeit, und wir sind mittendrin.

Nun schaue ich gerade auf das Dateidatum des dazugehörigen Zertifikats:
2026-04-21 03:00
Es wurde also irgendwie aktualisiert oder einfach nur neu auf den Server gelegt.
Ich kann nicht prüfen, ob es vor dem 21.04.26 dort fehlte oder ein defektes oder falsches Zertifikat für Tage/Wochen hinterlegt war. Im Screenshot sieht man die diversen Änderungsdaten. Die Zertifikate der gematik sind da überwiegend "frisch" - obwohl sie seit einigen Jahren gültig sind.
Irgendwas ist da seltsam, auch weil andere Zertifikate dort schon deutlich länger unverändert liegen.

Vorschlag:
Registrierung heute erneut probieren. Vielleicht klappt es nun (wieder) mit der Registrierung?
Oder ist der Fehler bei diesem Konnektor erst gestern erstmals aufgetreten? Wäre ein Hinweis.

Eigentlich... wenn ich mir das recht überlege... wenn CGM ein neues (gültiges) Zertifikat vom Typ "Laufzeitverlängerung" als ZIP bereitstellen würde, könnte man es ohne TI-Verbindung aufspielen. Zumindest, wenn es nicht von einem gültigen aktiven Konnektorzertifikat abhängt. Ich weiß nicht, wie da authentifiziert wird. Eigentlich sollte die Seriennummer ja reichen.
-> Ersatzzertifikat, das gültig ist -> Aufspielen -> Fertig. Konnektortausch gespart.


Denn warum sollte das nicht möglich sein? Es ist ja ein nur mit diesem Gerät funktionierendes Zertifikat, und der Schlüssel liegt im Konnektor. Kann man im Normalfall nix Böses mit machen.

Spannend, spannend...

[ebitdd]

Mal schauen auf https://download.tsl.ti-dienste.de/SUB-CA/
und dort dann https://download.tsl.ti-dienste.de/SUB- ... A7.der.txt
notBefore=Dec 2 08:35:25 2021 GMT
notAfter=Nov 30 08:35:24 2029 GMT

8 Jahre Laufzeit, und wir sind mittendrin.

Nun schaue ich gerade auf das Dateidatum des dazugehörigen Zertifikats:
2026-04-21 03:00
Es wurde also irgendwie aktualisiert oder einfach nur neu auf den Server gelegt.
Ich kann nicht prüfen, ob es vor dem 21.04.26 dort fehlte oder ein defektes oder falsches Zertifikat für Tage/Wochen hinterlegt war. Im Screenshot sieht man die diversen Änderungsdaten. Die Zertifikate der gematik sind da überwiegend "frisch" - obwohl sie seit einigen Jahren gültig sind.
Irgendwas ist da seltsam, auch weil andere Zertifikate dort schon deutlich länger unverändert liegen.

Ich habe im Webarchiv nachgeschaut: Der letzte Eintrag stammt vom 17. Februar. Das Uploaddatum war der 13. Februar 2026 um 3 Uhr. Der letzte Snapshot der Datei selbst war jedoch vom 15. August 2025, der Inhalt ist aber derselbe wie oben. Auch in älteren Snapshots ist der Inhalt der gleiche.

Vorschlag:
Registrierung heute erneut probieren. Vielleicht klappt es nun (wieder) mit der Registrierung?
Oder ist der Fehler bei diesem Konnektor erst gestern erstmals aufgetreten? Wäre ein Hinweis.

Dem Systemlog nach zu urteilen stieg die Verbindung am 18.04. um 07:36 das Erste mal aus und hängt seitdem im (erfolglosem) Verbindungsaufbau.
Registrierung habe ich gerade nochmal probiert (Zertifikatslisten nochmal aktualisiert), aber unverändert.

Eigentlich... wenn ich mir das recht überlege... wenn CGM ein neues (gültiges) Zertifikat vom Typ "Laufzeitverlängerung" als ZIP bereitstellen würde, könnte man es ohne TI-Verbindung aufspielen. Zumindest, wenn es nicht von einem gültigen aktiven Konnektorzertifikat abhängt. Ich weiß nicht, wie da authentifiziert wird. Eigentlich sollte die Seriennummer ja reichen.
-> Ersatzzertifikat, das gültig ist -> Aufspielen -> Fertig. Konnektortausch gespart.


Denn warum sollte das nicht möglich sein? Es ist ja ein nur mit diesem Gerät funktionierendes Zertifikat, und der Schlüssel liegt im Konnektor. Kann man im Normalfall nix Böses mit machen.

Spannend, spannend...

In der Tat, aber CGM tauscht doch lieber aus. Macht der Gewohnheit.