TLS Aktivierung

[DocET]

Liebe Kollegen,

die o.g. Dokumentation "Aktivierung der TLS Verschlüsselung mit Authentisierung mittels Client-Zertifikats" fordert auf S.4 oben unter anderem, den http-Zugriff auf die Kocobox zu verwehren.

Vor diesem Schritt muss doch aber sichergestellt sein, dass (unabhängig vom Browser) bereits eine https-Verbindung zur Kocobox aufgebaut ist. Anderenfalls hat man keinen Zugriff mehr über die Kocobox-Management-Schnittstelle?!

Wie haben Sie vor diesem Schritt die Kommunikation Ihres Browsers zur Kocobox auf https umgestellt?

Danke für Ihre Unterstützung, viele Grüße von DocET.

[rfbdoc]

Es funktioniert genau nach Anleitung. Auch nach Umstellung auf TLS können Sie normal mit dem Browser auf die Box zugreifen.

Es wird nur der Datenaustausch zwischen TurboMed als Client und der KocoBox auf Https umgestellt.

So zumindest interpretiere ich das. Ich habe gestern auf TLS Kommunikation umgestellt, das Zertifikat in TM importiert.
Dazu musste man die heruntergeladen zip Datei TurboMed.zip erst entpacken und dann das Zertifikat importieren und das heruntergeladene Passwort eingeben
Den Administrativen Zugang auf die Kocobox kann ich auch danach ganz normal weiter mit Firefox ausführen.

[rfbdoc]

Nach Re-Aktivierung funktionierts wieder.

Was meinen Sie damit ??
Deregistrierung und Neuregistrierung der KIM Adresse ??

[DocET]

Es funktioniert genau nach Anleitung. Auch nach Umstellung auf TLS können Sie normal mit dem Browser auf die Box zugreifen.

Es wird nur der Datenaustausch zwischen TurboMed als Client und der KocoBox auf Https umgestellt.

So zumindest interpretiere ich das. Ich habe gestern auf TLS Kommunikation umgestellt, das Zertifikat in TM importiert.
Dazu musste man die heruntergeladen zip Datei TurboMed.zip erst entpacken und dann das Zertifikat importieren und das heruntergeladene Passwort eingeben
Den Administrativen Zugang auf die Kocobox kann ich auch danach ganz normal weiter mit Firefox ausführen.

Sehen Sie bei der Kommunikation vom Browser mit der Kocobox Management-Schnttstelle im Firefox oben das Schloss für gesicherte Verbindung?

Danke für Ihre Rückmeldung!

[lcer]

Hallo,

zu Erklärung:

der Zugang zur Web-Administrationsoberfläche der KocoBox war schon immer über https verschlüsselt, normales http (ohne s) war nie möglich. Die TLS-Aktivierung aktiviert die Verschlüsselung für nur den Zugriff auf die Telematik-Dienste. Allerdings ist die Bezeichnung TLS-Verschlüsselung nicht exakt. Eigentlich müsste man sagen TLS-Verschlüsselung mit Überprüfung des Client-Zertifikats:

TLS-Verschlüsselung ohne Überprüfung des Client-Zertifikats: Server und Client benutzen die TLS-Verschlüsselung. Die Identität des Clients wird vom Server nicht überprüft. Beliebige Clients können eine Verbindung herstellen. -> Zugriff auf die Web-Admin-Oberfläche
TLS-Verschlüsselung mit Überprüfung des Client-Zertifikats: Server und Client benutzen die TLS-Verschlüsselung. Der Server lässt sich vom Client ein Zertifikat zeigen, welches er überprüft. Nur Clients mit zulässigen Zertifikaten können eine Verbindung herstellen. -> Zugriff auf TI-Dienste

Deshalb muss bei allen TI-Diensten das Client-Zertifikat und dessen Password im Turbomed/KIM etc. konfiguriert werden. Auch für den LAPD-zugriff. Für kv.dox siehe mein Post weiter oben. Für CGM-KIM gibt es dafür eine Wartungsfunktion unter Sonstiges/Wartung/CGM KIM.

Grüße

lcer

[lcer]

Ich hatte ja bereits geschrieben, daß ich nach jeder eAU das kv.dox Clientmodul neu starten muß, sonst bekomme ich Passwortfehler.

Wenn ich was helfen kann, kann ich gerne verschiedene Einstellungen nachsehen und hier posten.

Das Neustarten hilft nicht...

Von wo rufst Du denn die KIM-Mails ab? Bei mir sieht es so aus: Auf dem Turbomed-Server habe ich das KIM-Clientmodul installiert. Das eCockpit starte ich auf einem Arbeitsplatz-PC oder auf einer Terminalserversitzung auf dem Server. Was ich noch nicht probiert habe ist das eCockpit direkt (ohne RDP) auf dem Terminalserver zu starten.

Zweite Frage. Was hast Du als Fachdienst-Server im Turbomed eingetragen? mail.akquinet.kim.telematik oder am.akquinet.kim.telematik ?

Dritte frage: ist KV Connect bei Dir korrekt installiert und lauffähig? Bei mir jedenfalls nicht.

Grüße

lcer

[Timo Beil]

Nach Re-Aktivierung funktionierts wieder.

Was meinen Sie damit ??
Deregistrierung und Neuregistrierung der KIM Adresse ??

War die falsche Formulierung. Ich meinte einfach das Rückgängigmachen der TLS-Verschlüsselung.

[Randolf]

Hallo
Vielen Dank fuer die Postings zur Problematik. Jetzt habe ich verstanden wie die Benutzung von kv.dox durch TM "erschwierigt" und das programmeigene Zusatzprodukt implementiert wird. Vielleicht kann man Dank der proffessionellen Hinweise in den Posting hier , speziell von fuer die genialen Tipps Icer, das KBV eigene Modul mit den evtl . auch besseren Eigenschaften doch einsetzen. Das wäre mal ein Lichtblick in dem ganzen Dilemma !

Tausend Dank an Alle und vorab ein schönes Wochenende Gruesse Randolf

[torsten2]

Nur kurz Zwischendurch:
eCockpit geht bei mir gar nicht mehr. Auf dem Server nur weißes Fenster ohne Inhalt, in der 5181 ist es auf den Clients aus dem Menü raus... Bei kv.dox hat mir das Lügenbarometer mit den Verbindungsanzeigen ja sowieso nicht weitergeholfen. Ich nehme nach Nachrichtenverwaltungscenter. Hier sehe ich, daß z.B. bei der eAU die Zustellbestätigungen der Krankenkassen reinkommen.

Hier die config:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
<pop3Port>995</pop3Port>
<smtpPort>465</smtpPort>
<komLeClientAdresse>127.0.0.1</komLeClientAdresse>
<Fachdienstadresse>mail.akquinet.kim.telematik</Fachdienstadresse>
<ldapUrl>ldaps://192.168.110.251:636</ldapUrl>
<ldapStartTls>true</ldapStartTls>
<FachdienstPortSMTP>465</FachdienstPortSMTP>
<FachdienstPortPOP3>995</FachdienstPortPOP3>
<ldapsUsage>true</ldapsUsage>
<ldapsCertificatePath>C:\TurboMed\Daten\Var\Konnektor\Zertifikate\TLS\TurboMed.p12</ldapsCertificatePath>
<ldapsCertificatePassword>????????????????????????????????????????=</ldapsCertificatePassword>
</GeneralConfiguration>

[torsten2]

Zweiter Teil der Antwort:
Ich habe in der Konfiguration bei der Client Adresse die 127.0.0.1 auf die LAN Server-IP geändert. Wenn sich die Clients diese Einstellung auch ziehen, funktioniert die da natürlich auch nicht. Den Pfad zum TLS Zertifikat habe ich deshalb ebenfalls in UNC Notation geändert. Vielen Dank für den Tipp mit den xml configs der Arbeitsstationen. Ich habe auch nur die config für den Server gefunden. Müssen die Dateien auf den Server oder auf die jeweiligen Arbeitsstationen? Bei mir geht es scheinbar auch ohne...
KV Connect sollte hier ja eigentlich keine Rolle spielen. Aber ja, ich habe den kvconnect service von kv.dox installiert und laufen. Der wird auf einem Client mit gerade funktionierendem eCockpit auch mit einem grünen Haken quittiert. Das wichtigere KV-Safenet wird als nicht erreichbar markiert, was glatt gelogen ist. Ich lege die Covid Zertifikate direkt auf der rki Seite an, das funktioniert hervorragend.
Ich habe grade einen Arztbrief im Word geschrieben und mir selber unter speichern als eArztbrief geschickt. Das funktioniert, ist nach etwa 5min zurückgekommen, das ist auch das Standard Pollingintervall.

[Nervenarzt]

Ich habe grade einen Arztbrief im Word geschrieben und mir selber unter speichern als eArztbrief geschickt. Das funktioniert, ist nach etwa 5min zurückgekommen, das ist auch das Standard Pollingintervall.

Ich habe mir auch gerade einen eArztbrief geschickt. Ich hatte aber den Eindruck, dass er innerhalb von TM bzw. des eCockpits ausgeliefert wird und gar nicht erst in der TI landet. WIe kann ich denn feststellen, wie bzw. auf welchem Weg der eArztbrief verschickt wurde ? Bei mir erscheint der eArztbrief auch nur in der Kategorie eArztbrief und nicht bei eNachricht...

[Nervenarzt]

...
und es erscheinen einige Einträge in der Patientenkartei. Hier mal ein Auszug:

Screenshot 2021-10-12 164641.png

[Nervenarzt]

zum dritten:

mittlerweile (nach mehr als 20 Minuten) konnte ich dann endlich über das eNachrichtenCenter auch den Brief wirklich empfangen, mit Anhang einer Signaturüberprüfung wohl als Zeichen, dass er 20 Minuten lang in der Elektronik herumgereicht wurde, um endlich wieder bei mir zu landen. Auch meine KIM-Testnachricht ist dann nach fast einer Stunde wieder bei mir angekommen.

Und das Ganze funktioniert bei konstant rotem CGM KIM im eCockpit.

[Nobbie]

Den eAB kann man doch knicken. Kaum eine Praxis hat eine KIM Adresse und die Vorlagen sind nicht praktikabel für den laufenden Betrieb. Die eAU starten wir, wenn das mal richtig funktioniert.
Gruß Nobbie

[DocET]

Heute habe ich nach Anleitung die TLS-Verschlüsselung zwischen Konnektor und TurboMed aktiviert. Die einzelnen Schritte habe ich dabei an dem PC umgesetzt, der Zugriff auf das Kartenterminal mit der SMC-B besitzt.

• Konnektor -> Verwaltung
  • Anbindung Clientsystem mit http nein, TLS ein, Authentisierung aktiviert, Modus Zertifikat
  • Zugangszertifikat hinzufügen -> Clientsystem TurboMed, Erzeugung Zertifikat und PWD
• TurboMed -> Sonstige -> Praxisdaten -> eGK -> Konnektor Einstellungen -> Konfiguration
  • IP -> war bereits automatisch eingetragen – ok
  • Umstellung auf Verbindungsart HTTPS mit Client Zertifikat
  • Zertifikat (vom Konnektor) einbinden und PWD-Eingabe

Erfreulich: VSDM läuft sofort und an allen PCs mit Kartenterminals (Wahnsinn).

Unverständlich:

• Im TurboMed sind die o.g. Konnektor-Einstellungen nur bei PCs mit Kartenterminal zu sehen. Die anderen (bei mir auch der TurboMed Server) dürften damit nicht mehr mit dem Konnektor kommunizieren dürfen, oder?
• KIM geht nicht mehr. Nicht einmal die registrierte KIM-Adresse wird angezeigt.

Kennen Sie dieses Verhalten und ggf. die Lösung?

Bin wie immer für Hinweise dankbar!

Viele Grüße von DocET.

[rfbdoc]

KIM geht nicht mehr. Nicht einmal die registrierte KIM-Adresse wird angezeigt.

Ich glaube, das ist nach TLS Aktivierung normal.
Vermutlich müssen Sie Kim einmal derigistrieren und wieder neu registrieren. Damit kann man auf jeden Fall nichts falsch machen. (TurboMed auf Server als Administrator starten)

[bofh]

Nach TLS-Aktivierung muss ein KIM-Wartungslauf durchgeführt werden.

[DocET]

Vielen Dank, den Wartungslauf (TurboMed->Sonstiges->Wartung->CGM KIM->TLS Verschlüsselung) werde ich gleich am Montag anstoßen.

Dennoch kann ich nicht nachvollziehen, warum ich am TurboMed-Server NICHT die erwarteten Konnektor-Einstellungen sehe, sondern ein quasi leeres Eingabemenü siehe Bild. Befüllt sich dieses Menü wieder nach dem Wartungslauf? An den PCs mit Kartenterminal stimmen darin die Eintragungen.

Dank und Gruß, DocET.

[bofh]

Insbesondere auch am Server sollten doch die Zertifkate eingespielt werden und die Verbindungsart umgestellt werden. Ist der Server im Infomodell des Konnektors eingetragen?
Die Annahme ist, dass der KIM-Client auf dem Server läuft.

Wir hatten die TLS-Umstellung am Server vorgenommen und dann die Zertifikate auch in die lokalen Turbomed-Verzeichnisse der Arbeitsplätze (vom Serververzeichnis) kopiert.

[DocET]

Der Server ist im Infomodell der Kocobox eingetragen, wobei das Kartenterminal mit der SMC-B als entferntes Kartenterminal zugeordnet ist. Auch ich erwarte, dass der KIM-Client auf dem Server läuft.

Ich war der CGM-Anleitung "Aktivierung der TLS Verschlüsselung mit Authentisierung mittels Client-Zertifikats" gefolgt, wo ich in der Mitte von Seite 3 fand:
"Der Arbeitsplatz, an dem die Umstellung erfolgt, muss ein lokales Kartenterminal besitzen und Zugriff auf die der Praxis zugeordneten SMC-B haben (das ist der Fall, wenn an der Station bereits zuvor eGK's eingelesen wurden)."
Das ist bei mir nicht der Server, weshalb ich die Vorgehensweise auch merkwürdig fand.

Das Zertifikat ist jetzt nach o.g. Vorgehensweise dennoch auf dem Server abgelegt, nur das Menü "Konnektor-Einstellungen" ist dort leer. Wenn ich dieses nachtragen möchte und als vorletzte Eintragung die Verbindungsart auf "HTTPS mit Client Zertifikat" stelle, fragt TurboMed nach dem Ort des Konnektor-Zertifikats und dann nach dem Passwort. Diese Prozedur auf dem Server selbst nach o.g. Schritten auszulösen, hatte ich mir erst einmal in Erwartung eines undefinierten Ergebnisses nicht getraut. Kann man das bedenkenlos tun, was ja das Zertifikatsverzeichnis auf dem Server überschreiben müsste?