Hallo miteinander,

wir mussten wegen bald ablaufendem Zertifikat eine neue SMC-B verwenden.
Wir haben einen Secunet-Konnektor von der Telekom hinter einer Sonicwall-Hardwarefirewall und einem Zyxel-Speedport-Router. Bislang hat das TI meistens einwandfrei funktioniert. Mit dem Tausch gegen die neue SMC-B allerdings nicht mehr.

Die neue SMC-B ist freigeschalten auf dem Antragsportal, wurde beim Mandant eingetragen und im PVS mit der neuen PIN versehen. Die alte SMC-B haben wir ausgetragen. Leider schlägt jetzt der Aufbau der VPN-Verbindung dauernd fehl:

21:16:45 ERROR VPN Client: Verbindungsaufbau des TI VPN Kanals wurde abgebrochen.
21:16:44 INFO VPN Client: Aufbau eines neuen TI VPN Kanals zu vpnk2-ti.prod.eqxffm.gem-vpn-zugd-tsi.de hat begonnen.
21:16:42 INFO VPN Client: TI VPN Konzentrator Adressen wurden ermittelt.

Wenn wir versuchen den Konnektor neu freizuschalten mit der neuen SMC-B, erhalten wir dauernd die Fehlermeldung "Fehler bei Registrierung des Konnektors im Konnektor. (Code 43014)".

Mit der alten SMC-B schlagen alle Verbindungsversuche (wieder mit Eintrag beim Mandant usw., Zertifikat noch gültig) und Registrierungsvorgänge ebenfalls fehl:

Registrierungsstatus abfragen: Fehler bei Statusabfrage beim Registrierungsserver im Konnektor. (Code 43018)
Erneutes Freischalten: Fehler bei Registrierung des Konnektors im Konnektor. (Code 43014)
Freischaltung zurücknehmen: Fehler bei Deregistrierung des Konnektors im Konnektor. (Code 43016)

Wir werden aus den Meldungen nicht schlau. Mehrere Neustarts mit und ohne den Karten haben nicht weitergeholfen. Weiß hier vielleicht jemand weiter und kann uns helfen? Danke.

Eine halbe Stunde später hat der Konnektor nun eine TI-Verbindung aufbauen können und die neue Freischaltung mit der neuen SMC-B lief auf Anhieb durch. Wir hatten nichts mehr geändert, er lief einfach eine halbe Stunde unberührt mit der neuen SMC-B und hat unzählige Male versucht sich zu verbinden. Irgendwann ging es einfach. Die SIS-Verbindung schlägt noch fehl.

Guten Morgen,

nein, seit gestern morgen nicht mehr. Ohne weitere Änderungen hat es irgendwann einfach funktioniert. Bislang auch ohne Probleme. Leider arbeitet seit heute das KIM-Postfach nicht mehr korrekt. Ich musste den Telekom-KIM-Client neu installieren, um mich wieder mit dem Konnektor verbinden zu können. Das Modul kann aber trotz korrekter Zugangsdaten, Verbindung zum Konnektor und installiertem Clientzertifikat eingehende Nachrichten nicht entschlüsseln ("Der fuer die Entschluesselung der Nachrichtig benoetigte Schluessel wurde nicht gefunden." als Meldung.) Hier bin ich auf der nächsten Fehlersuche.

Hallo,

wird die SMC-B getauscht geht damit auch ein Wechsel des Zertifikatsmaterials einher.
KIM-Nachrichten werden vom Versender-KIM-Clientmodul mit den öffentlichen Zertifikatsdaten (Schlüssel) aus dem Verzeichnisdienst verschlüsselt (asymmetrische Verschlüsselung), bevor die KIM-Nachricht an den Empfänger versendet wird.
Zum Entschlüsseln wird der private Zertifikats-/Schlüsselteil benötigt, welcher auf der physischen SMC-B verbleibt.
Dies bildet insgesamt die Ende-zu-Ende-Verschlüsselung ab und bedeutet, dass KIM-Nachrichten nur im Kontext genau eines Schlüsselpares und damit in einem dedizierten Zertifikatskontext entschlüsselt werden können.

Durch den Wechsel/Erneuerung der SMC-B bedeudet dies, dass ein neues Zertifikat und damit Schlüsselpaar existiert, mit dem "alte" Nachrichten, die noch mit dem alten öffentlichen Schlüsselmaterial (alte SMC-B) verschlüsselt wurden, nicht mehr entschlüsselt werden können.

Beim Nachrichtenabruf sucht ein KIM-Clientmodul die passende Karte/SMC-B zum Entschlüsseln, ist diese nicht mehr vorhanden/nicht gesteckt/ungültig kann die Nachricht nicht entschlüsselt werden -> siehe Ihre Fehlermeldung.

Es bleibt leidglich die Möglichkeit, sofern die alte SMC-B noch nutzbar ist, diese zu stecken + zu konfigurieren und den Abruf zu wiederholen.

Viele Grüße

Hallo,

Danke. Meine Vermutung war schon, dass die KIM-Adresse als Praxisadresse an die alte SMC-B gekoppelt ist. Die alte SMC-B ist noch verwendbar, nur nicht mehr verbaut.
Mein Workflow wäre also:
- Alte SMC-B einsetzen (geht das mit einem zweiten Terminal?)
- neuen temporären Kontext im Konnektor einrichten (um die neue SMC-B-Konfiguration nicht mehr anzurühren) auf die alte SMC-B
- KIM-Clientmodul auf den neuen temporären Workflow konfigurieren
- Mails abrufen
- KIM-Mail deregistrieren
- KIM-Clientmodul auf den normalen Workflow konfigurieren
- KIM-Mail registrieren
- temporären Kontext wieder löschen
- alte SMC-B wieder entfernen

Irre ich mich?

Wir haben die neue gegen die alte SMC-B ausgetauscht und bei unserem bestehenden Mandant die alte hinzugefügt. So konnten wir ohne weitere Änderungen über KIM ausstehende Mails aus dem Postfach entschlüsseln.
Anschließend haben wir wieder die neue verbaut. Nun kann das T-KIM-Clientmodul nicht mehr auf die VZD-Dienste zugreifen. Neuinstallation usw. versucht, erfolglos. Es scheitert immer an der Verbindung zu den VZD-Diensten. Einträge in der HOSTS-Datei stimmen. Route nach Vorgabe im Konnektor (ROUTE ADD 100.102.0.0 MASK 255.254.0.0 <ipadresse_des_konnektors>) ist auch angelegt.
Im Diagnosetest ist der VZD erreichbar. Ebenso wenn man die Adresse des VZD über die Erreichbarkeitsfunktion unter "Netzwerk" testet.

Die Mailserver-Dienste sind erreichbar (lb-mail.qexffm ...). Clientzertifikat wurde installiert. Die Adminoberfläche kann die Kontexte usw. beim Konnektor abrufen.
Der Selbsttest des KIM-Admin-Clients zeigt "Die VZD Dienste sind nicht verfügbar, die Ursache ist: java.lang.NullPointerException". Wahrscheinlich hängt es jetzt wieder an irgendeinem Zertifikat...?

Hoffentlich läuft es bald wieder. Danke für die Hilfe bislang.

Wenn VZD über Thunderbird funktioniert, müsste ich über das LDAP auf Adressen zugreifen können, oder? Funktioniert leider nicht. Die clientmodule.log hat folgende Einträge:

2023-05-31 23:42:43.122 [{}] [JavaFX Application Thread] ERROR com.tsystems.gematik.komle.clientmodule.ui.admin.components.TabSupport$12.handle - Catching java.lang.NullPointerException: null
at com.tsystems.gematik.komle.clientmodule.ui.admin.services.CheckVzdService$CheckVzdTask.call(CheckVzdService.java:32) ~[ClientModule-2.0.7-2-SNAPSHOT.jar:2.0.7-2-SNAPSHOT-19820]
at com.tsystems.gematik.komle.clientmodule.ui.admin.services.CheckVzdService$CheckVzdTask.call(CheckVzdService.java:26) ~[ClientModule-2.0.7-2-SNAPSHOT.jar:2.0.7-2-SNAPSHOT-19820]
at javafx.concurrent.Task$TaskCallable.call(Task.java:1425) ~[javafx.graphics:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at javafx.concurrent.Service.lambda$executeTask$6(Service.java:725) ~[javafx.graphics:?]
at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
at javafx.concurrent.Service.lambda$executeTask$7(Service.java:724) ~[javafx.graphics:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:831) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]

2023-05-31 23:42:41.469 [{id=4e87ebfb-ed3e-49a3-9da2-5eb04511f5e9}] [CM-POP3-Server-Worker-0] ERROR com.tsystems.gematik.komle.clientmodule.pop3.server.Pop3ProxyServerChannelInitializer.lambda$addSSLServerHandler$0 - SSL handshake unsuccessful. Cause: {} java.nio.channels.ClosedChannelException: null
at io.netty.handler.ssl.SslHandler.channelInactive(SslHandler.java:1066) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:241) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelInactive(DefaultChannelPipeline.java:1405) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:262) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:248) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.DefaultChannelPipeline.fireChannelInactive(DefaultChannelPipeline.java:901) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.AbstractChannel$AbstractUnsafe$8.run(AbstractChannel.java:831) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:469) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:497) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-all-4.1.66.Final.jar:4.1.66.Final]
at java.lang.Thread.run(Thread.java:834) [?:?]

Vielleicht stimmt auch die TLS-Einstellung nicht mehr oder mit der neuen SMC-B sieht das bisherige Zertifikat anders auch. Das versuche ich morgen herauszufinden.

Wir sind wieder online. Tatsächlich hing es am KIM-Eintrag im VZD, Die Telekom hat den Maileintrag zurückgesetzt. Jetzt können wir wieder problemlos verbinden. Weitere Änderungen waren nicht notwendig. Die alte Mail war noch mit dem alten SMC-B-Zertifikat verbunden und das gab einen Konflikt, den man als User selber nicht beheben kann.
Schwer war es nur bei der Telekom über die Mails und Hotlines jemanden zu finden, der Ahnung hat und das tut.

Und etwas für die Allgemeinheit und andere Fehlersucher die letzte Hürde heute (und für mich wenn ich in fünf Jahren wieder Fehlersuche mache): wenn das KIM-Client-Modul über das Netzwerk erreichbar sein soll, beispielsweise um von PVS und Mail-Clients auf anderen PCs auf eine zentrale KIM-Clientinstallation auf dem Server zuzugreifen, muss man die Einträge SmtpHostname und Pop3Hostname in der clientmodule.xml von "localhost" auf "0.0.0.0" oder die Interface-IP ändern. Portbinds auf localhost und 127.0.0.1 sind nur auf der eigenen Maschine erreichbar.

Danke für alle Rückmeldungen und Hilfestellungen.

Hallo, wir haben exakt das gleiche Problem, haben Sie zufällig direkt eine kompetente Anlaufstelle ansonsten wusel ich mich auch mal durch die Hotlines :(