VonDoczuDoc.de

Gibt es Infos dazu, wie ein Zertifikat zur Konnektorauthentifizierung erzeugt und in den Konnektor hochgeladen werden kann? Es ist doch ein Unding, dass der Webbrower stets meckert, wenn man das Admin-Interface öffnet.

Jetzt kommt noch der Gematik Authenticator dazu. Dort wird derzeit empfohlen, den Konnektor nicht mittels Zertifikat zu identifizieren. Siehe letzte Frage/Antwort in https://wiki.gematik.de/pages/viewpage. ... =474101686.

Nicht, dass das Risiko groß wäre, dass ein fremder Konnektor im Praxisnetz auftaucht. Aber trotzdem... Den MITM darf man nicht unterschätzen.

1) Für´s Admin-Interface ist es etwas tricky mit dem Zertifikat der Kocobox ohne Fehlermeldung zu leben.
Aber wenn Sie ein von einer vertrauenswürdigen Stelle ausgestelltes Zertifikat nutzen wollen, braucht die Box dafür einen FQDN.
Ich habe aber noch nicht probiert, der Box einen CSR zu entlocken geschweige denn eine CA zu hinterlegen (falls nötig).
Somit könnte man Plan B nehmen und das Konnektorzertifikat im Browser als vertrauenswürdig hinterlegen.

2) Sie können beim Authenticator die TLS-Prüfung deaktivieren, wobei ich vermute, dass das "TLS-Zertifikatsprüfung" heißen sollte. Also TLS mit einem aktuellen Konnektorzertifikat ohne Prüfung der Zertifkatskette.

2,5) TM hat in den TLS-Einstellungen die Vorgabe, sich mit Zertifikat beim Konnektor anzumelden. Benutzername/Kennwort ist m.W. nicht möglich einzugeben. Im Prinzip ginge auch das in TM und/oder bei KIM verwendete Zertfikat samt Kennwort zu nutzen.

Wenn Sie trotzdem eine Client-Auth per User/Pw einrichten wollen, dann lässt sich das auf der Seite mit der TLS-Pflicht einrichten. Ich kenne aber an der Kocobox keinen funktionierenden Fall (ohne das ausschließen zu wollen). Mit Secunet ist das easy.

3) Fremder Konnektor im Praxisnetz, der dann auch noch angesprochen werden kann (IP-Adresse)? Hmmm....

Bei ALBIS scheint alles "intern" abzulaufen, ohne Gematik-Auth.

1) Ist schon seltsam. Kaum fragt man hier, dann merkt sich Edge auch die Sicherheitsausnahme. Zeitgleich ist der Internet-Explorer verschwunden. Früher war es mir nicht gelungen, dass Edge sich die Ausnahme merkt. Plan B ist damit erledigt.

Nebeneffekt des von M$ entsorgten IEs: Man muss nun Firefox installieren, wenn man ein TLS-Client-Zertifikat vom Konnektor erzeugen lassen und runterladen will.

2) Die Erklärung/Hilfe für "Konnektor-Zertifikat prüfen" beim Authenticator sagt: "Diese Option prüft, ob das Serverzertifikat des Konnektors valide ist und ob es im Vertrauensbereich des Truststores liegt". Die eigentliche Frage war, ob es prinzipiell auch mit aktiver Prüfung einzurichten geht (nur theoretische Neugier).

Ursprünglich im Sinn hatte ich, sicherzustellen, dass es genau "mein" Konnektor ist, aber das leistet diese Überprüfung nicht notwendigerweise - die schaut nur nach, ob der Konnektor "offiziell" ist.

2,5) entfällt. Das soll beim Zertifikat bleiben. Benutzername/Kennwort soll es nicht werden.

3) Ich kann mir schon einen MITM-"Router" vorstellen, der zwischen Konnektor und LAN (unbemerkt) eingeschleift wird (das wäre möglich, wenn man z.B. die Putzfrau erfolgreich besticht). Ob dieser allerdings eine Chance hat, ohne das TLS-Client-Zertifikat zu kennen, habe ich noch nicht zu Ende überlegt.

Der Gematik-Authenticator soll für das (verpflichtend!) kommende DEMIS-Meldeportal für Arztpraxen notwendig werden. Damit entfällt dann das Fax bzw. der berittene Bote ans Gesundheitsamt. Das hat mit dem PVS erstmal nichts zu tun.

bofh hat geschrieben: ↑Mittwoch 1. November 2023, 22:26 1) Ist schon seltsam. Kaum fragt man hier, dann merkt sich Edge auch die Sicherheitsausnahme. [...] Man muss nun Firefox installieren, wenn man ein TLS-Client-Zertifikat vom Konnektor erzeugen lassen und runterladen will.

Soo schlimm ist der Firefox auch nicht. Nachdem Chrome nunmehr auch einfach mal Werbemessung aktiviert, ohne (vollständig) zu fragen, bin ich nicht mehr wegen der "Firefox darf Studien..." beleidigt. *nicht zu ernst gemeint*

2) Die Erklärung/Hilfe für "Konnektor-Zertifikat prüfen" beim Authenticator sagt: "Diese Option prüft, ob das Serverzertifikat des Konnektors valide ist und ob es im Vertrauensbereich des Truststores liegt". Die eigentliche Frage war, ob es prinzipiell auch mit aktiver Prüfung einzurichten geht (nur theoretische Neugier).

Prinzipiell ja:
- Auf dem DNS-Server für´s LAN oder in der hosts-Datei die passenden DNS-Einträge erstellen (A-Record für konnektor.konlan auf die Konnektor-IP-Adresse, CNAME für die 8027er-Zahlenfolge)
- Aussteller-Zertifikat (z.B. GEM.KOMP-CA7) zum Authenticator legen (siehe https://download.tsl.ti-dienste.de/SUB-CA/)
- Dessen Aussteller-Zertifikat (meist GEM.RCA6) = siehe https://download.tsl.ti-dienste.de/ROOT-CA/

...und dann sollte es laufen. Allerdings habe ich es nicht getestet, auch wenn´s mich gerade wirklich juckt. Es bleibt bloß das mäßig wahrscheinliche Risiko, dass der Authenticator einen fest verdrahteten DNS-Server befragt, sobald man ihm anstelle einer IP-Adresse einen Hostnamen gibt.
Na, vielleicht kommt mal die Gelegenheit für jemanden hier, einen kleinen Testbericht zu posten.

Ursprünglich im Sinn hatte ich, sicherzustellen, dass es genau "mein" Konnektor ist, aber das leistet diese Überprüfung nicht notwendigerweise - die schaut nur nach, ob der Konnektor "offiziell" ist.

Ein anderer Konnektor würde unter normalen Umständen kein fremdes Clientzertifikat annehmen, da nicht zur Anmeldung berechtigt (ich meine das Zertifikat zum Anmelden des Clientsystems am Konnektor, das der Konnektor ausstellt).

3) Ich kann mir schon einen MITM-"Router" vorstellen, der zwischen Konnektor und LAN (unbemerkt) eingeschleift wird (das wäre möglich, wenn man z.B. die Putzfrau erfolgreich besticht). Ob dieser allerdings eine Chance hat, ohne das TLS-Client-Zertifikat zu kennen, habe ich noch nicht zu Ende überlegt.

100.102.0.0/15 geht via TI-VPN raus. Dessen Payload ist mithilfe des Zertifikats der SMC-B verpackt, dessen privater Schlüssel wiederum an der PIN-Eingabe hängt. Und diese wird ja bisher (meist) ohne TLS und (praktisch immer) ohne VPN über´s Praxisnetz geschickt.

Aber so genau habe ich mir das Schema des Authenticators noch gar nicht angesehen. Manches geht ja auch via Internet-IDP (ti-dienste.de), da aber wieder mit sauberem SSL. Ich kann mir nicht vorstellen, dass da das Konnektorzertifikat wirklich eine Rolle spielt. Laut FAQ kann der Authenticator auch noch nix mit ECC-Zertifikaten anfangen. Wobei... das kann TM meines Wissens bisher auch nicht. Hrhr...

Der Gematik-Authenticator soll für das (verpflichtend!) kommende DEMIS-Meldeportal für Arztpraxen notwendig werden. Damit entfällt dann das Fax bzw. der berittene Bote ans Gesundheitsamt. Das hat mit dem PVS erstmal nichts zu tun.

Das erinnert mich daran, dass zum Beispiel in Niedersachsen das KV-Safenet per Software-VPN lief (Citrix-VPN-Lösung) und keine VPN-Box/GUS-Box nötig war. Lief bis zuletzt einwandfrei. Mir ist jedenfalls nichts Gegenteiliges bekannt.
Und die Konnektorenfarmen sind per OpenVPN oder Wireguard angebunden.

Die TI 2.0 soll mit Softzertifikat laufen, und unter HighSpeed-Konnektor stelle ich mir aus wirtschaftlichen Gründen einen Server im staatlich bewachten Rechenzentrum vor, der mit 2 XEONs (oder was auch immer gerade passt - und bei gutem Willen noch irgendwelchen Hardware-Crypto-SoCs als Steckkarte on top) mal locker die Arbeit von einigen tausend Konnektoren im Halbschlaf erledigt. Vielleicht muss er dann mal an einem Montagmorgen ein wenig an die Lastgrenze gehen, wenn die ganzen eAU auf den Weg gehen.
Wenn ich so sehe, dass einer meiner Mailserver vor einigen Jahren täglich gut 350.000 Mails* mit einem SSL- und STARTTLS-Anteil von gut 40% durchgeschubst hat und selten die Verbindungsrate drosseln musste, verstehe ich den Unsinn mit den Konnektoren rein technisch überhaupt nicht. Der Mailserver war eine VM auf Virtuozzo-Basis mit 20 Kunden pro Box für rund 25 Euro im Monat. 2011 - 2014, also zu XEON X- und E5-Zeiten.

* = Tatsächliche Nutzlast lag bei gut 2.000 echten Mails von Mensch zu Mensch, 15.000 technischen Mails in Form von GPS-Logger-Reports alle paar Sekunden für einen Sicherheitsdienst und über 300.000 Spam-Mails, die auf Honeypot-Adressen im Rahmen eines Feldtests für einen Spamfilter reinkamen. Port 587 war Authenticated only, 465 SSL only und Port 25

Doch dass der Highspeed-Konnektor nicht SO funktioniert und allein aufgrund der Codemenge und vermutlich auf einem Java-Framework basierend auch nicht die Performance eines ausentwickelten Postfix (damals war ich noch mit qmail unterwegs, grmpf) liefern wird, steht auf einem anderen Blatt. Das, was ich von einem am HSK mitwirkenden Programmierer erfahren habe, deutet jedenfalls auf eine prinzipiell einfache Lösung hin, die aus eher politischen oder "anderen Gründen" verkompliziert wird.
Aber sowas wäre dann auch nicht weiter überraschend, nicht wahr?

Sooo, Feierabend

Die CGM MANAGED TI VPNs basieren auf StrongSwan, einer freien IPSEC Implementierung.
Hintergrund ist der, dass das sowohl die KTs direkt sprechen, als auch Windows ohne Zusatzsoftware.

Man kann auf den Konnektor ein mit OpenSSL generiertes Zertifikat hochladen, allerdings kein CA-Zertifikat. Auch wenn der Konnektor selbst immer ein CA-Zertifikat mitgeneriert.

Bei einem selbst hochgeladenen Zertifikat erstellt man ein CA-Schlüssel und Zertifikat (ECC 384 oder RSA 2048, Hash SHA256, Typ x509 im PEM Format), danach erstellt man ein Nutzerschlüssel und Nutzerzertifikat (CA signiert) und lädt am Ende aber nur das Nutzerzertifikat (.crt-File) hoch.
Das hochzuladene Zertifikat muss im .crt Format vorliegen und um es nutzen zu können, muss eine ClientsystemID im Infomodell mit gleichem Namen existieren.

Pro Client ID kann nur ein Zertifikat hochgeladen werden. Secunet beherrscht pro Client ID ein RSA UND ein ECC Zertifikat.

Aus meiner Sicht macht es wenig Sinn für Endanwender ein Zertifikat hochzuladen, anstatt es vom Konnektor generieren zu lassen, da der Konnektor ja mittlerweile Zertifikate generieren kann, die länger als 1 Jahr gültig sind.

Mein Zertifikat läuft zum 28. Februar aus Gerade hat mir die CGM eine Rechnung CGM Service plus geschickt (Ich denke dabei geht es um das Zertivkatupdate der Kocobox ?oder?)

Wie kann ich also nun ein Zertifakt mit der Kocobox erstellen?
Danke
Grüsse aus Kiel
Johnny

Hi Johnny,

das CGM Service Plus Paket ist ein zusätzlicher Servicevertrag der CGM und hat nicht mit den Zertifikaten zu tun. Der Vertrag beinhaltet und deckt die Kosten der Bereitstellung für die PTV-5+ und PTV 6-Upgrades der Kocobox. Zusätzlich werden gSMC-KTs bei zeitnahem Ablauf direkt an die Praxis gesendet.

Wegen dem ablaufendem Zertifikat , solltest du dich an deinen Service- und Vertriebspartner wenden. Diese wissen in der Regel wie man das Zertifikat erneuert.
Hintergrund ist das nur TI-Zertifizierte Techniker diese Zertifikate erneuern und erstellen dürfen.

Viele Grüße
Richard

Welches Zertifikat läuft denn aus? Das ClientSystem Zertifikat oder das Konnektor Zertifikat?

>Hintergrund ist das nur TI-Zertifizierte Techniker diese Zertifikate erneuern und erstellen dürfen.
Genau mein Humor!

Johnny hat geschrieben: ↑Montag 18. Dezember 2023, 18:18 Mein Zertifikat läuft zum 28. Februar aus
Kocobox Zertifikat4e.png

Gerade hat mir die CGM eine Rechnung CGM Service plus geschickt (Ich denke dabei geht es um das Zertivkatupdate der Kocobox ?oder?)

Wie kann ich also nun ein Zertifakt mit der Kocobox erstellen?
Danke
Grüsse aus Kiel
Johnny

Jetzt erst den Screenshot gesehen.
Das Zertifikat kannst du ja selbst neu erstellen (dort, wo du den Screenshot gemacht hast löschen und dann neu generieren).
Danach im Primärsystem hinterlegen.

@Unschlagbar

Unschlagbar schrieb:
das CGM Service Plus Paket ist ein zusätzlicher Servicevertrag der CGM und hat nicht mit den Zertifikaten zu tun. Der Vertrag beinhaltet und deckt die Kosten der Bereitstellung für die PTV-5+ und PTV 6-Upgrades der Kocobox. Zusätzlich werden gSMC-KTs bei zeitnahem Ablauf direkt an die Praxis gesendet.

Danke Unschlagbar für die Antwort.

Mein gSMC-KT für meine Cherry-Tastatur G87/1505 ist vor wenigen Tagen abgelaufen (hatte ich alles selbstgekauft und eingerichtet). Wird die nun tatsächlich von CGM-TI ersetzt? Und wie gehe ich da vor?

Danke und
beste Grüsse aus Kiel
Johnny

@CGM-FTW schrieb:

Jetzt erst den Screenshot gesehen.
Das Zertifikat kannst du ja selbst neu erstellen (dort, wo du den Screenshot gemacht hast löschen und dann neu generieren).
Danach im Primärsystem hinterlegen

Leider, leider habe ich es nicht verstenden

1) Wo unter welchem Menuepukt kann ich die Zertifikate löschen?
2) Wo kann ich die Zertifikat erzeugen.
3) Wie kann ich die Zertifikate uploaden?

Grüsse aus dem näxhtlichem Kiel
Johnny

Das wurde von anderen eigentlich schon gut beschrieben, z.B. hier: viewtopic.php?t=9363

Bei uns kam es zu Problemen mit dem Clientzertifikat im Rahmen des KIM1.0 auf 1.5 Rollouts. Wie sich im Nachhinein herausstellte, aber nicht primär wegen des Clientzertifikats.

Die Erneuerung des Zertifikates auf der KoKoBox unter Verwaltung gelang letztendlich nur mit einem aktuellen Firefox ESR (dann klappt auch der automatische Download als *.zip mit PW-Datei)!!

Zusätzlich bleibt zu vermerken, dass die Doku von CGM für die Standalone "Update.exe" von 1.0 auf 1.5 nicht fehlerfrei ist & im KIM-Clientmodul (unter localhost:8000 oder die IP:Port erreichbar) mit Admin-Anmeldung unter "Clientsystem-Zertifikat-Verwaltung" der Schieberegler deaktiviert sein muss. Dann ist auch der "SSLv3 handshake" Fehler weg & alles funzt reibungslos!

Danke für dieses Forum hier. Bitte weiter so!