eAU

[Randolf]

Hallo
Vielen Dank für die aktuellen sehr hilfreichen Informationen.
@Torsten2: Was wären denn "solche nicht so kompatiblen Karten- Kombinationen " für den Konnektor, die er "nicht so leiden kann ", oder welche Konfiguration wäre da ratsam ?? Wir sammeln noch weitere Informationen aus der Praxis um mögliche Fehlerquellen bei der geplanten Einrichtung zu vermeiden. Danke vorab Randolf

[torsten2]

Ich habe ein KT am Arztarbeitsplatz. Von da hatte ich per Remote-PIN KT die SMC-B von der Anmeldung verbunden. Da hat es Probleme gegeben, obwohl der HBA gesteckt war. Durch die dauernden Abstürze hab ich, nach der Empfehlung im Forum, die SMC-B sowieso an meinen Arbeitsplatz umgesteckt. Jetzt sind der HBA und die SMC-B physisch in einem Gerät. Das geht super. Manchmal kommt, wenn die Komfort-Session abgelaufen ist, ein "interner Fehler bei der Signierung" weil "die Vorlage dies .xml Modells nicht verfügbar ist" oder so ähnlich. Man soll dann den Konnektor neu starten, das hilft dann auch. Ist mit Sicherheit noch ein ärgerlicher Bug. Ich habe noch ein KT bei mir zuhause stehen und mit dem vom Arztarbeitsplatz als Remote-PIN KT verbunden (alle Steckplätze, SMC-B, eHBA). Ich konnte grade die zum Praxisschluß bockende eAU von hier signieren und versenden. Das funktioniert auch, sicher eine gute Nachricht für Kollegen, die eine Filiale so angebunden haben.
@rfdoc: So wie ich das rauslese, hängt es nicht an der Komfortsignatur, sonder am eHBA selber. Die Signatur geht ja scheinbar einzeln auch nicht. Da die Signierung mit der SMC-B nur als Notfall-Fallback gedacht ist, wird da Komfort von Haus aus nicht gehen. Deswegen bearbeitet TM es nicht fertig, sondern stellt es einfach ins eMusterCenter. Ist er nicht entsperrt oder beim Arzt in TM nicht hinterlegt? Wie alt ist der denn, erinner mich, dass die erste Version das nicht konnte... Meiner läuft 12/2025 aus und ist Version 4.3.0_4.3.1 (Kartenterminaldienst) - was immer das heißt.

[rfbdoc]

Ist er nicht entsperrt oder beim Arzt in TM nicht hinterlegt

Da bin ich mir auch nicht ganz sicher. Unter TM->Sonstiges->Gematik->Verwaltung der Komortsignatur kann ich allerdings den Ausweis für die in der KocoBox eingestellte Anzahl von Unterschriften aktivieren und werde von dort auch zur Eingabe der eHBA Pin aufgefordert. Somit müsste er in TM auch hinterlegt sein.
Meine Vermutung ist folgende: Das KTM an der Anmeldung ist im Infomodell mit allen Rechnern der Praxis verknüpft. Damit kann ich auf allen Rechnern Covid Impfzertifikate erstellen und theoretisch von allen Arbeitsplätzen aus die eGK einlesen (im Alltag erfolgt dies allerdings nur von den 3 Arbeitsplätzen an der Anmeldung)

[torsten2]

Klingt gut. Der Port im KT wird dann auch grün und die PIN wird verlangt? Das würde bedeuten, dass der Konnektor sehr wohl weiß, wo er den HBA findet. Dann klemmt es noch woanders. Wo steckt der denn, haben sie ein eigenes KT im Sprechzimmer? Ich hab das prinzipiell auch so. Mach die Wartungsarbeiten meistens abends und will ja nicht nach einem Neustart des Konnektors 20min in die Praxis fahren nur um da die PIN eingeben zu müssen. Das geht dann auch elegant von zuhause. Die Signatur ging heute von hier (KT lokal, rdp Session auf dem Server), das ist theoretisch die gleiche Konstruktion.
Ich drucke immer alle 3 Durchschläge auf A5 Sicherheitspapier, der Patn. wartet solange. Wenn ich Stapelsignatur mache und dann geht was nicht, ist der Arzt verantwortlich, dass es zur Kasse kommt. Dann schick ich es am Ende noch auf meine Kosten an die Kasse. So sind die Spielregeln Wenn was nicht klappt, muß der Patn. halt seinen Durchschlag selber zur Kasse tragen, mir dann egal. Daher mach ich keine Stapelsignatur.
Übrigens:
Für die Covid-Zertifikate brauch ich doch nur die Verbindung in die Telematik zu dem Fachdienst an sich. Die werden doch nicht durch die SMC-B einzeln signiert?! Also ich mach das nicht im TM sondern über die Webseite meiner KV, die mich dann ins IBM-Netzwerk weiterleitet, wo die Seite gehostet ist. Hatte, als es mal nicht ging, ein Gespräch mit dem Support dort. Laut RKI ist es so, dass die Authorisierung über das Login bei der KV erfolgt, die sind verantwortlich - wenn es gültig ist, wird man weitergeleitet. Dadurch ist der Arzt mit dem generiertem Zertifikat verbunden, nicht durch die SMB-C der Telematik... TM hängt sich doch auch nur mit einer API da dran. So gesehen, wär das dann nicht unbedingt notwendig, die SMC-B weiter zu verbinden.
So, morgen ist auch noch ein Tag, viele Grüße @rfbdoc

[rfbdoc]

Für die Covid-Zertifikate brauch ich doch nur die Verbindung in die Telematik zu dem Fachdienst an sich.

Um Zugriff auf die SMCB zu haben muss das KTM verknüpft sein.
Bei mir steht das KTM an der Anmeldung mit SMC-B und eHBA. Theoretisch gebe ich einmal die eHBA-Pin ein, und kann dann per Stapelsignatur signieren je nach Einstellung bis 100 oder 250 Unterschriften. Tatsächlich hat da aber noch nie eine Signatur stattgefunden. KTM für die Sprechzimmer schaffe ich erst an wenn dort auch etwas signiert werden muss.
Warum die Signatur nicht über den freigeschalteten eHBA läuft erklärt sich mir noch nicht. Das mag auch noch ein Fehler in TM sein, von daher warte ich ab.
Heute kam es bei der eAU mal wieder zum Einfrieren in TM sodass wieder erst mal wieder blanko gedruckt wird. In der Kartei stand nur die erste Zeile des AU Eintrags, die Diagnosentexte fehlen. Ursache unbekannt...

[Roland_Colberg]

Nachdem es so aussieht, dass es zum 1.7. mit der eAU "ernst" wird, versuche ich diese Funktion derzeit zum Laufen zu bringen.

Die ersten Versuche waren zunächst erfolgreich, die eAUs wurden im eMuster-Center abgelegt und konnten von dort signiert und versendet werden.

Dann habe ich zur Nutzung der Komfort-Signatur die TLS-Verschlüsselung am Konnektor und in Turbomed eingeschaltet, bin dabei nach der "Anleitung Aktivierung TLS-Schlüssel" von Turbomed vorgegangen. Das hat auch funktioniert, nachdem ich in den Turbomed Konnektor-Einstellungen zusätzlich den Eventport von 45000 auf 45123 geändert und noch das Tool unter "TurboMed - Sonstiges - Wartung - CGM KIM - TLS Verschlüsselung" habe laufen lassen. EGKs lassen sich weiterhin einlesen.

Allerdings findet das Programm seitdem die "Empfangsadresse der zuständigen Krankenkasse" nicht mehr und druckt stattdessen die 2. Kopie für den Kostenträger aus, anstatt die eAU im eMuster-Center anzuzeigen:

Fehlende Empfangsadresse.png

Außerdem konnte im eCockpit Verbindungstest unter CGM KIM keine LDAP Verbindung mehr hergestellt werden (POP3 und SMTP haben funktioniert).

Nach einigem Suchen habe ich unter "Sonstiges - Praxisdaten - Arzt - Zusatzdaten - KIM - Konfigurationsparameter ändern" von den Verzeichnisdienst von LDAP auf LDAPS umgestellt, seitdem funktioniert KIM wieder, das Problem bei der eAU besteht aber weiter.

Nachdem die eAU hier offenbar bei mehreren Praxen auch mit Komfortsignatur/TLS funktioniert: ist dort LDAP oder LDAPS eingestellt, bzw. hat das überhaupt eine Auswirkung auf die eAU?

Hat jemand ähnliche Probleme (gelöst)?

[nappi218]

Hallo,

funktioniert die eAU am Server?

Wir hatten das Problem auch - gelöst wurde es durch den Service-Partner - ich hab mir folgendes notiert:

Problem: Kim Suche Geht nicht am Arbeitsplatz.

Unter dem Server-Verzeichnis im TM-Ordner ?:\TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin in der config.xml muss ggf. der serverpfad zum Zertifikat eingerichtet werden (nach Installation einer neuen Kim Adresse)
Sofern <ldapsCertificatePath>?:\TurboMed\Daten\Var\Konnektor\Zertifikate\......\client.p12</ldapsCertificatePath>
ändern in
<ldapsCertificatePath>\\XXX.XXX.XXX.XXX\TurboMed\Daten\Var\Konnektor\Zertifikate\.....\client.p12</ldapsCertificatePath>

Vielleicht hilft es ja.

Beste Grüße
Nappi

[nappi218]

Nachtrag:
\\XXX.XXX.XXX.XXX\ = Serveradresse

Gruss Nappi

[rfbdoc]

@Roland Colberg
Nach Umstellung auf TLS muss Kim einmal deregistriert und wieder neu registriert werden.
Dann müsste auch unter TLS der eAU Versand wieder laufen.
Zum Thema Drucken:
Wenn eine zum Versand markierte eAU nicht versandt werden kann erfolgt automatisch der Ausdruck des Durchschlags für die Krankenkasse. Eigentlich ja nicht dumm. Der Ausdruck muss dann von der Praxis an die Kasse geschickt werden, dafür gibt es auch eine Portoziffer 86cent im EBM.
Bei mir war es meist so, dass bei einem späteren neuen Sendeversuch der Versand dann doch glatt durchlief.

Bei mir klappt allerdings die Signierung nur über die SMCB und nicht über den eHBA, warum auch immer. Vermutlich ein Fehler in meinem Infomodell

[hw]

Ja, wir haben seit der nachträglichen Umstellung auf TLS genau die von Roland_Colberg beschriebenen Probleme, dass die Adresse der Krankenkasse nicht mehr gefunden wird. Das hat vor der Umstellung noch funktioniert.
KIM scheint noch zu funktionieren, wir können jedenfalls Adressen suchen und uns selbst auch Briefe usw. schicken. ABer eAU-Versand geht nicht, da die Adresse der Krankenkasse nicht gefunden wird.
Hat jemand das Tageskennwort für 21.5.22, dann würde ich mal KIM deregistrieren und neu registrieren.

[Roland_Colberg]

Hallo,

funktioniert die eAU am Server?

Nein, auch am Server besteht dieses Problem.

Unter dem Server-Verzeichnis im TM-Ordner ?:\TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin in der config.xml muss ggf. der serverpfad zum Zertifikat eingerichtet werden (nach Installation einer neuen Kim Adresse)
Sofern <ldapsCertificatePath>?:\TurboMed\Daten\Var\Konnektor\Zertifikate\......\client.p12</ldapsCertificatePath>
ändern in
<ldapsCertificatePath>\\XXX.XXX.XXX.XXX\TurboMed\Daten\Var\Konnektor\Zertifikate\.....\client.p12</ldapsCertificatePath>

Das ist interessant. Bei mir sieht diese Datei (auf dem Server) so aus:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
    <pop3Port>8995</pop3Port>
    <smtpPort>8465</smtpPort>
    <komLeClientAdresse>TS1</komLeClientAdresse>
    <Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
    <ldapUrl>ldap://192.168.xxx.xxx:389</ldapUrl>
    <ldapStartTls>false</ldapStartTls>
    <FachdienstPortSMTP>465</FachdienstPortSMTP>
    <FachdienstPortPOP3>995</FachdienstPortPOP3>
    <ldapsUsage>false</ldapsUsage>
</GeneralConfiguration>

TS1 ist der Turbomed-Server, 192.168.xxx.xxx der Konnektor
Somit scheint dieses Plugin bei mir weiter LDAP statt LDAPS zu verwenden, was die erfolglose Adresssuche erklären könnte.

Vermutlich muss ich hier nicht nur den Zertifikatspfad, sondern auch das Passwort irgendwo eintragen. Können Sie mir mal Ihre ganze config.xml (ohne Passwort ) schicken?

Das Tageskennwort für heute habe ich leider auch nicht, daher kann ich KIM gerade nicht neu registrieren.

Vielen Dank!

[hw]

Bei uns genau der gleiche Dateiinhalt und auch keine eAU auf keinem Arbeitsplatz, auch nicht auf Server.

[hw]

Wir haben jetzt KIM deregistriert, Konto gelöscht und neu registriert. Danach geht tatsächlich die eAU wieder, so wie es jetzt aussieht. Zumindest am Server, mehr habe ich noch nicht ausprobieren können.
Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Das Tageskennwort für 30.4.2022 lautet: 923796 (wenn das jemand verwenden will, muss der Rechner auf dieses Datum eingestellt werden, danach nicht vergessen, wieder das aktuelle Datum zu verwenden!)

Also: rfbdoc hat Recht, KIM neu Registrieren hilft auch hier!

[Roland_Colberg]

Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Könnten Sie mir die funktionierende config.xml mal zukommen lassen (gerne auch per pn, und ohne Passwort)? Das mit der Datumsumstellung würde ich gern vermeiden.

Vielen Dank!

[Thomas]

Das ist meine config.xml:

Code: Alles auswählen

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<GeneralConfiguration>
    <pop3Port>8995</pop3Port>
    <smtpPort>8465</smtpPort>
    <komLeClientAdresse>TS</komLeClientAdresse>
    <Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
    <ldapUrl>ldaps://ip_des_konnektors:636</ldapUrl>
    <ldapStartTls>false</ldapStartTls>
    <FachdienstPortSMTP>465</FachdienstPortSMTP>
    <FachdienstPortPOP3>995</FachdienstPortPOP3>
    <ldapsUsage>true</ldapsUsage>
    <ldapsCertificatePath>C:\TurboMed\Daten\Var\Konnektor\Zertifikate\4BABDF6F-1382-41b2-9FCB-9C190F97791A\client.p12</ldapsCertificatePath>
    <ldapsCertificatePassword>my0+tQoCzbXszjM9npRLHAL1hBf+S6cnknrwjK3Ux4w=</ldapsCertificatePassword>
</GeneralConfiguration>

Das mit dem Tageskennwort und der Datumsrückstellung tut gar nicht so weh: Ich gehe immer bis zur Abfrage des Tageskennworts, gebe das ein, stelle dann das Datum um, klicke auf ok, um das Kennwort zu bestätigen, und - bevor ich dann irgendetwas anderes in TM mache - stelle ich sofort das Datum wieder korrekt ein. Dann sollten alle Datenbanken usw. keine falschen Einträge bekommen...

Viele Grüße
Thomas

[nappi218]

Auch die von nappi218 genannte Datei sieht jetzt so aus, wie dort beschrieben!

Könnten Sie mir die funktionierende config.xml mal zukommen lassen (gerne auch per pn, und ohne Passwort)? Das mit der Datumsumstellung würde ich gern vermeiden.

Vielen Dank!

Hallo,

Datei sieht so aus:

<?xml version="1.0" encoding="UTF-8" standalone="true"?>
-<GeneralConfiguration>
<pop3Port>8995</pop3Port>
<smtpPort>8465</smtpPort>
<komLeClientAdresse>server</komLeClientAdresse>
<Fachdienstadresse>mail.tm.kim.telematik.</Fachdienstadresse>
<ldapUrl>ldaps://xxx.xxx.xxx.xxx:636</ldapUrl>
<ldapStartTls>false</ldapStartTls>
<FachdienstPortSMTP>465</FachdienstPortSMTP>
<FachdienstPortPOP3>995</FachdienstPortPOP3>
<ldapsUsage>true</ldapsUsage>
<ldapsCertificatePath>\\xxx.xxx.xxx.xxx\TurboMed\Daten\Var\Konnektor\Zertifikate\xxxxxxxxxxxxxxxxxxxxxxxxxx\client.p12</ldapsCertificatePath> ' hier muss der Netzwerkpfad rein, sonst sind die clients anscheinend blind
<ldapsCertificatePassword>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=</ldapsCertificatePassword>
</GeneralConfiguration>

und hier das Vorgehen wie ich bei uns die TLS-eAU neu eingerichtet habe:

Einrichtung TI / KIM --> Vorgehen: alles deinstallieren und dann neu aufsetzen - das kurzzeitige Rückstellen des TagesPW sollte kein Problem sein soweit ich weiss.

--> TM als Administrator starten
--> Sofern eingerichtet muss zunächst die TLS-Verschlüsselung deaktiviert werden
--- sonstiges --> Praxisdaten --> eGK -->
Zertifikatsverzeichnis löschen, auf einfaches http einstellen und alles übernehmen
--- TM beenden und als admin neu starten --> Verbindung zum connector wird scheitern --> sonstiges --> Praxisdaten
--> smcb löschen und
--> Anbindung an connector deaktivieren

--- Kocobox Managementschnittstelle --> Signaturdienst aus
... Kocobox Managementschnittstelle --> Verwaltung --> Clientsysteme --> ja / Aus / nicht aktiviert / Zertifikat
... Zugangszertifikate Turbomed / CA Turbomed löschen und dann übernehmen

--> TM beenden, Server und Kocobox neu starten
--> TM als Admin starten

--> nun das ganze wieder einrichten:
... Anbindung an Connector aktivieren --> SMCB auswählen --> Pin eingeben ...... den Anweisungen folgen
--> Testen des entsprechenden Kartenlesegerätes

--> wenn alles funktioniert, TLS wieder einrichten - zunächst Errechbarkeit der Box unter https testen
(siehe hierzu auch Anleitung zur TLS-Einrichtung im Forum)

--> Kocobox Managementschnittstelle --> Verwaltung --> Clientsysteme --> nein / ein / aktiviert / Zertifikat
--> Zugangszertifikat hinzufügen --> "TurboMed" --> Speichern (am besten Desktop) --> alles übernehmen
--> Signaturdienst einschalten

--> gespeicherte zip-datei entpacken

--> --- sonstiges --> Praxisdaten --> eGK --> https mit Clientzertifikat
--- Zertifikat aus der entpackten zip einspielen, PW ist in der textdatei im selben ordner

--> alles übernehmen und als Admin neu starten.
--> Verbindung testen und eine eGK zum Test einlesen.

Nun kim neu einrichten

--> \TurboMed\NetSetup\Firewalleinstellungen --> FirewallKIM.cmd etc. als admin ausführen

--> Dann Vorgehen wie im Forum beschrieben:
... Kim-Adresse deregistrieren - und mittels Tageskennwort löschen
... Anschließend neu einrichten

--> was auffällt:
Als Praxisadresse eingerichtet --> eCockpit cgm kim --> rot
Als Arztadresse eingerichtet --> eCockpit cgm kim --> grün, verstehe das wer will

Problem: Kim Suche Geht nicht am Arbeitsplatz.

Unter dem Verzeichnis im TM-Ordner ?:\TurboMed\Daten\Var\aWinS\CGMCONNECT_CONFIGS\KOMLEPlugin in der config.xml muss ggf. der serverpfad zum Zertifikat eingerichtet werden (nach Installation einer neuen Kim Adresse)
Sofern <ldapsCertificatePath>?:\TurboMed\Daten\Var\Konnektor\Zertifikate\......\client.p12</ldapsCertificatePath>
ändern in
<ldapsCertificatePath>\\XXX.XXX.XXX.XXX\TurboMed\Daten\Var\Konnektor\Zertifikate\.....\client.p12</ldapsCertificatePath>

xxx.xxx.xxx.xxx --> ServerIP

Beste Grüße
Nappi

[Randolf]

Hallo
Vielen Dank an Nappi218 für die konkrete Handlungsanleitung, da wir zZt noch nichts aktiviert haben, ist der Weg etwas einfacher und wir planen dank der guten Hilfe duch die Kollegen hier für Juni die Sache doch mal anzugehen und zu versuchen. TM liefert solche Anleitungen eher nicht , oder habe ich sie noch nicht entdeckt ? Unklar wofür wir die hohen laufenden Kosten eigentlich bezahlen ?

[hw]

Vielen Dank @nappi,
nach der KIM-Neuregistrierung sah die Datei genau so aus. Allerdings beinhaltet sie nicht die IP-Adresse, sondern den Laufwerksbuchstabe, unter dem das Verzeichnis am SERVER vorhanden ist.
Das soll ja nach der Anleitung geändert werden.

Problem ohne Änderung:
Am Server klappt eAU und KIM, an den Clients nur KIM
Auf den Clients wird die Datei nicht gefunden. Die eAU-Erstellung läuft auf Fehler auf.

Wenn LW-Buchstabe durch IP des Servers ersetzt wird:
KIM geht überall, eAU kann nirgends mehr erstellt werden.

Irgendwo geht das was schief.
Gibt es einen Unterschied, wenn TLS vom Server aus aktiviert wurde im Gegensatz zum Client als Ausführort? Die Beschreibung von TM zur Aktivierung von TLS ist ja in diesem Punkt unklar und könnte auf einen Client hindeuten.

[nappi218]

Vielen Dank @nappi,
nach der KIM-Neuregistrierung sah die Datei genau so aus. Allerdings beinhaltet sie nicht die IP-Adresse, sondern den Laufwerksbuchstabe, unter dem das Verzeichnis am SERVER vorhanden ist.
Das soll ja nach der Anleitung geändert werden.

Problem ohne Änderung:
Am Server klappt eAU und KIM, an den Clients nur KIM
Auf den Clients wird die Datei nicht gefunden. Die eAU-Erstellung läuft auf Fehler auf.

Wenn LW-Buchstabe durch IP des Servers ersetzt wird:
KIM geht überall, eAU kann nirgends mehr erstellt werden.

Irgendwo geht das was schief.
Gibt es einen Unterschied, wenn TLS vom Server aus aktiviert wurde im Gegensatz zum Client als Ausführort? Die Beschreibung von TM zur Aktivierung von TLS ist ja in diesem Punkt unklar und könnte auf einen Client hindeuten.

Hallo,

die gesamte Anleitung wurde von mir so am Server eingerichtet. Auch laufen alle Dienste auf dem Server.

Könnte es sein, dass die entsprechende Netzwerkfreigabe so bei Ihnen nicht existiert? Unter windows ---> Netzwerk --> Server aufrugfen, hier muss der entsprechende TurboMed-Pfad ("TurboMed") erscheinen / freigeben sein. Ansonsten muss der Pfad angepasst werden.

Beste Grüße
Nappi

[Roland_Colberg]

Vielen Dank für die genauen Anleitungen, bei mir funktioniert die eAU jetzt schonmal auf dem Server, auch mit der Anpassung auf den UNC-Pfad in der config.xml.

Ich habe jetzt auch den Weg über die KIM-Neuregistrierung gewählt, da ja das Zertifikats-Passwort offenbar nicht im Klartext in die config-Datei gehört.

Dabei hatte ich (wie früher schon einmal) das Problem, dass die Deregistrierung zuerst mit einer Fehlermeldung abgebrochen ist und danach die KIM-Adressen gar nicht mehr in der CGM KIM Einrichtung angezeigt wurden. Daher habe ich dann

• die TLS-Verschlüsselung ausgeschaltet
• die KIM Konten gelöscht (die Warnung ignoriert)
• TLS wieder aktiviert (neues Zertifikat erstellt)
• die KIM-Adressen ohne Probleme wieder registriert.

Neustarts von Konnektor oder Server waren nicht notwendig, allerdings musste der CGM KIM Dienst auf dem Server neu gestartet werden.

@hw: ich denke auch, dass hier die Freigabe des Turbomed-Ordners auf dem Server korrekt angegeben werden muss. Bei mir geht auch der Servername:

\\ts1\turbomed\daten\....

Das sollte auch in einem Explorer-Fenster über die Adressleiste so aufzurufen sein (das ist ein UNC-Pfad, der beginnt mit 2 Backslashes). Wichtig ist, dass über diesen Pfad sowohl der Server wie auch die Clients auf das Zertifikat zugreifen können.

Übrigens frage ich mich, was die Krankenkassen eigentlich mit diesen ganzen Mustermann-Test-AUs anfangen