Fehler beim TLS-Handshake

[Markus Stamm]

Liebe Forengemeinde, ich habe am Wochenende NSP im schnellen Kanal innerhalb der Version 15.7.0 aktualisiert (installierte Version wurde angezeigt als 15.7.0, nach Update jetzt folgende Versionen:

NoSpamProxy 15.7.0.3377
Management services 15.7.0.691
Identity Service 1.2.74
Gateway Role 15.7.0.691
Message Tracking Service 2.0.28
Intranet Role 15.7.0.691
WebApp Hosting Service 1.3.19
WebApp 1.2.3963.0
PowerShell 15.7.0.691
NoSpamProxy Command Center 15.7.0.691
Message Tracking Transport service 1.0.11
External Process Manager 1.0.712

Ich habe seit diesem Update bei sonst unveränderter Konfiguration erhebliche Probleme mit TLS-Verbindungen. Bei abgehenden Verbindungen meines internen Mailservers zu NSP wird nach der Meldung 220 Ready to start TLS durch (angeblich) NSP die Socketverbindung getrennt. Von außen eingehende Verbindungen von posteo.de sind nicht möglich. Die Meldung, die die Absender erhalten, lautet

Reporting-MTA: dns; mout02.posteo.de
X-Postfix-Queue-ID: 07AD81A00EA
X-Postfix-Sender: rfc822; XXXXXXX@posteo.de
Arrival-Date: Mon, 23 Mar 2026 20:58:14 +0100 (CET)

Final-Recipient: rfc822; xxxxx@xxxxx.xx
Original-Recipient: rfc822;xxxxx@xxxxx.xx
Action: failed
Status: 5.7.5
Diagnostic-Code: X-Postfix; Cannot start TLS: handshake failure

Andere E-Mail-Nachrichten gehen durchaus ein, aber ich weiß nicht, ob das Problem nicht auch andere Absender betrifft. In der Ereignisanzeige finde ich nichts zielführendes.

CheckTLS meldet
SSL_connect:SSLv3/TLS write client hello
read from 0x1064c30 [0x1094b43] (5 bytes => 0 (0x0))
SSL_connect:error in SSLv3/TLS write client hello
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 182 bytes and written 395 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
read from 0x1064c30 [0xf4a000] (8192 bytes => 0 (0x0))
process ended prematurely at /var/www/perl/TestReceiver.pl line 6494.

Als Hotfix würde ich gern auf die Vorversion zurückgehen, da bei ihr das Problem nicht aufgetreten ist. Wäre das eine Möglichkeit, und wie müsste ich verfahren?

Gibt es Hinweise, woran das liegen kann? Außer der Aktualisierung von NSP hat sich an der Konfiguration nichts geändert. Welche Informationen könnte ich noch liefern?

Danke und Grüße,
Markus

 

[Markus Stamm]

Nachtrag - beim Versuch, die Datenbankberechtigung für die Gateway-Rolle zu korrigieren, tritt folgender Fehler auf:

Fehlermeldung: NoContent

Status: 204
Response:

Ort im Programm: Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeEndService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at Netatwork.NoSpamProxy.Wcf.Services.ITroubleshootingControllerAsync.EndFixPermissions(IAsyncResult ar)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Netatwork.NoSpamProxy.Wcf.Client.Channel.<UseServiceAsync>d__57`2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.Wcf.Client.Channel.<ExecuteAsync>d__42`3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.ManagementConsole.Connection.MailGatewayServiceRoleConnector.<FixPermissionsAsync>d__37.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Netatwork.NoSpamProxy.UI.ViewModels.MailGatewayViewModelBase.<ExecuteOperationAsync>d__59.MoveNext()
Zusätzliche Daten:
Detail: NoContent

Status: 204
Response:

Action: http://tempuri.org/ITroubleshootingController/FixPermissionsWebServiceInvocationFaultFault
Code: Name: Sender
Reason: The creator of this fault did not specify a Reason.

Kann das möglicherweise eine Erklärung sein? Ansonsten scheinen die Datenbankfunktionen richtig zu funktionieren. Es erscheint keine Fehlermeldung, und ich kann z.B. die Nachrichtenverfolgung normal durchführen.

 

[869288141]

Hallo Markus,

CheckTLS meldet
SSL_connect:SSLv3/TLS write client hello
read from 0x1064c30 [0x1094b43] (5 bytes =&gt; 0 (0x0))
SSL_connect:error in SSLv3/TLS write client hello
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 182 bytes and written 395 bytes
Verification: OK

Ich würde zunächst prüfen, ob auf den Konnektoren des NoSpamProxys weiterhin das korrekte Zertifikat hinterlegt ist. Dabei sollte auch sichergestellt werden, dass die Berechtigungen auf das Zertifikat im Zertifikatsspeicher korrekt gesetzt sind und ggf. angepasst werden. Wenn du das nicht manuell händisch tun möchtest, kannst du gerne auch auf ein Skript (Link) zurückgreifen.

Anschließend lohnt sich ein Blick in den Event Viewer der Windows-Server, auf denen die Intranet- bzw. Gateway-Rolle von NSP installiert ist, um festzustellen, ob seit dem Update Warnungen oder Fehler protokolliert wurden.

Gibt es Hinweise, woran das liegen kann? Außer der Aktualisierung von NSP hat sich an der Konfiguration nichts geändert. Welche Informationen könnte ich noch liefern?

Entsprechen die eingesetzten Windows-Server- sowie SQL-Server-Versionen und -Editionen den aktuellen Systemanforderungen? Laut Dokumentation werden für aktuelle NoSpamProxy-Versionen mindestens Windows Server 2016 sowie SQL Server ab 2016 SP1 bzw. SQL Express 2022 vorausgesetzt. Gerade bei Updates greifen hier inzwischen auch Setup-Blocker, wenn veraltete Versionen im Einsatz sind.

Die vollständigen Anforderungen findest du hier:
https://docs.nospamproxy.com/Server/15/Suite/de-de/Content/installation/system-requirements.htm

Hast du an den TLS Protkollen und Cipher Suites deiner Windows Server Änderungen vorgenommen? Dann sind diese ggf. auch nochmals zu kontrollieren und ggf. auf Standard zurück zu setzen.

F

Thema 'Anleitung TLS-Serverhärtung in Bezug auf NSP (Basis: IIS Crypto)'

9 Juli 2025

Hallo zusammen,

anbei eine Anleitung zur Windows Server Härtung (Annahme: Windows Server 2022 oder höher. Für Windows Server 2016/2019 gibt es Abweichungen) in Bezug auf die TLS-Verschlüsselung: Protokolle und Ciphers mit Bezug auf die NSP-Gatewayrollen.
Die Ableitung der Einstellungen erfolgt vom IIS Crypto, konkret die Profile "Best Practice" und "Strict" dienen als Referenz für die Einstellungen.
Unterschied: Die zwischen den beiden Templates: TLS Cipher Suites (kein CBC bei "Strict")

Zur Vermeidung von Komplikationen im Betrieb z.B. "der Partner xyz.com kann nach der Härtung keine...

• Fabian
• Antworten: 1
• Forum: Third Party Tipps

• 
• 

Gruß,
Daniel

 

[Markus Stamm]

Vielen Dank! Es sind MS WIndows Server 2022 Standard sowie MS SQL Server Express 2022. Systemsprache Englisch. Auch die anderen System Requirements sind erfüllt. An den TLS-Protokollen und Cipher Suites habe ich keine Änderungen vorgenommen. Sie sind schon seit Jahren auf IIS_Crypto Best Practices, und es gab vor dem Update keinerlei Probleme. Geändert habe ich daran nichts.

Das Zertifikat wird auch von MDaemon verwendet, den ich hinter NSP einsetze, und dabei treten die genannten Fehler nicht auf. Auch die Kommunikation mit den Gegenstellen ist ohne Probleme möglich. Ich habe zuvor schon in der Konfiguration das Zertifikat erneut ausgewählt und die Konfiguration gespeichert. Das hat aber nichts geändert.

Das PowerShell-Skript meldet

2026-03-23 22:32:49 - Info - Check if the group exists.
2026-03-23 22:32:49 - Error - The specified group was not found!

Möglicherweise kann das ein Hinweis sein. Es wäre allerdings dann eigenartig, warum das Zertifikat für MDaemon normal funktioniert.
In der Ereignisanzeige ist nur die jeweils angenommene Verbindung unter Netatwork Mail Gateway - Connections protokolliert. Unter Netatwork Mail Gateway erscheinen keine Fehler oder Warnungen. Aber unter System erscheint

Schannel, Event ID 36870
A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.
The SSPI client process is NoSpamProxy.GatewayRole (PID: 17156).

Das kann ebenfalls ein Hinweis auf ein Berechtigungsproblem sein.

Ich habe eben ausprobiert, das Zertifikat einfach aus dem Zertifikatspeicher zu löschen, neu zu installieren, und dann in NSP erneut zu konfigurieren. Dadurch ist der Fehler aber nicht beseitigt, sondern er tritt bei eingehenden Verbindungen von posteo.de weiterhin auf.

Wie wäre die richtige Vorgehensweise für die Anpassung der Berechtigungen, falls es daran liegt?

Danke und Grüße, Markus

 

[Markus Stamm]

Nachtrag: Ich habe die Lösung gefunden. Die Gateway-Rolle wird unter LOCAL SYSTEM ausgeführt, und sie hatte keine Leserechte für den privaten Schlüssel. Diese habe ich in der Zertifikatverwaltung nachgetragen, und jetzt funktioniert, soweit ersichtlich, alles wieder. Ich teste noch etwas umfangreicher. Danke für den Denkanstoß!

Nachtrag: Wobei noch die Frage bleibt, wie es zu dem Fehler gekommen ist. Denn ich habe wirklich (und ich weiß, das sagen sie alle) außer der Aktualisierung von NSP keine Änderungen vorgenommen.

Grüße, Markus

 

[Sören]

Die Gateway-Rolle wird unter LOCAL SYSTEM ausgeführt

ich habe gerade mit zwei Kollegen über deinen Fall gesprochen und wir können uns alle nicht erklären warum der Dienst schlagartig im falschen Kontext lief....daher muss ich nochmal nachfragen, du bist dir sicher das er in diesem Kontext lief und was hast du es nun geändert?

 

[Markus Stamm]

Ja, er wird unter Local System ausgeführt. An dem Sicherheitskontext, in dem er ausgeführt wird, habe ich selbst nichts geändert. Falls von der Aktualisierung auf die neueste Version noch Installationslogs vorhanden sind, stelle ich die gern zur Verfügung.

Eine andere Sache ist mir noch aufgefallen - die Gatewayrolle meldete vor einigen Jahren nach dem Tausch eines RAID-Controllers offenbar wegen einer vorher nicht sichtbaren Race Condition mit CryptSvc, nach einem Systemneustart, dass das TLS-Zertifikat nicht überprüft werden konnte. Das war dadurch zu beheben, dass ich CryptSvc als Abhängigkeit für die Gatewayrolle eingetragen habe, danach ist der Fehler nie mehr aufgetreten. Diese Abhängigkeit war aus der Konfiguration des Windows-Dienstes für die Gatewayrolle nach dem Update auch verschwunden. Ich habe sie wieder eingetragen.

Für jetzt habe ich dem Local System Leserechte für den privaten Schlüssel des Zertifikats gegeben. An der Dienstkonfiguration der Gatewayrolle wollte ich nichts ändern. Ich kann das aber gern tun, wenn es zweckdienlich ist.

Nachtrag: Es war ein Update von 15.7.0 auf 15.7.0 (die genaue Versionsnummer der ersetzten Version habe ich vorher leider nicht notiert).

 

[Markus Stamm]

Nachtrag: Unter welchem Kontext muss die Gatewayrolle bei richtiger Konfiguration ausgeführt werden, und gibt es allenfalls eine automatisierte Möglichkeit, dies zu korrigieren?

 

[Sören]

Unter welchem Kontext muss die Gatewayrolle bei richtiger Konfiguration ausgeführt werden

local service

noch Installationslogs

jau, die hätte ich gerne.. zippe die mal bitte und sende mir das als PM

 

[Markus Stamm]

Ich schaue heute Abend nach, ob sie noch da sind. Dabei ändere ich auch gleich den Sicherheitskontext.

 

[869288141]

2026-03-23 22:32:49 - Info - Check if the group exists.
2026-03-23 22:32:49 - Error - The specified group was not found!

Kann es sein, dass du das Skript nicht in Kontext "Als Administrator ausführen" gestartet hast?

Wobei noch die Frage bleibt, wie es zu dem Fehler gekommen ist. Denn ich habe wirklich (und ich weiß, das sagen sie alle) außer der Aktualisierung von NSP keine Änderungen vorgenommen.

Von welcher exakten Version hast du auf 15.7.0.3377 aktualisiert?

Ja, er wird unter Local System ausgeführt. An dem Sicherheitskontext, in dem er ausgeführt wird, habe ich selbst nichts geändert. Falls von der Aktualisierung auf die neueste Version noch Installationslogs vorhanden sind, stelle ich die gern zur Verfügung.

Wenn du für deine Sicherungen Veeam Backup & Replication einsetzt, könntest du die betroffenen VMs aus einem Restore Point wiederherstellen, der vor dem NSP-Update erstellt wurde. Es empfiehlt sich, diese in einer isolierten Umgebung zu starten, um den Zustand vor dem Update gezielt zu analysieren.

Auf diese Weise lassen sich beispielsweise Screenshots der Windows-Dienste erstellen und bereitstellen. Quasi "schwarz auf weiß" als Nachweis für den ursprünglichen Zustand.

Eine andere Sache ist mir noch aufgefallen - die Gatewayrolle meldete vor einigen Jahren nach dem Tausch eines RAID-Controllers offenbar wegen einer vorher nicht sichtbaren Race Condition mit CryptSvc, nach einem Systemneustart, dass das TLS-Zertifikat nicht überprüft werden konnte. Das war dadurch zu beheben, dass ich CryptSvc als Abhängigkeit für die Gatewayrolle eingetragen habe, danach ist der Fehler nie mehr aufgetreten.

Der Zusammenhang zwischen einem Hardware-RAID-Controller und dem Windows-Dienst "CryptSvc" erschließt sich mir aktuell nicht. Nach meinem Verständnis handelt es sich hierbei um zwei voneinander unabhängige Komponenten. Einmal auf Hardware- bzw. Storage-Ebene und einmal auf Betriebssystemebene im Bereich kryptografischer Dienste. Könnte hier bitte jemand näher erläutern, wo genau die Verbindung gesehen wird?

Diese Abhängigkeit war aus der Konfiguration des Windows-Dienstes für die Gatewayrolle nach dem Update auch verschwunden. Ich habe sie wieder eingetragen.

Das ist für mich logisch nachvollziehbar. Vermutlich wurde der Windows-Dienst im Zuge des NSP-Updates entfernt und anschließend neu angelegt. Dabei gehen natürlich auch manuelle Anpassungen verloren – beispielsweise die von dir erwähnte konfigurierte Abhängigkeit. Das würde das beobachtete Verhalten aus meiner Sicht schlüssig erklären.

 

[Markus Stamm]

Ich habe das Skript als Administrator ausgrführt. Aus den Logs konnte ich sehen, dass die Vorversion 15.7.0.2881 war. Zu der möglichen Race Condition hatte ich hier einmal etwas geschrieben. Ich bin damals davon ausgegangen, dass es mit der Geschwindigkeitssteigerung zu tun hatte, aber das war unsicher. Inzwischen habe ich den Sicherheitskontext des Dienstes geändert. Die Logs habe ich an Sören gegeben, mal sehen was sich aus der Analyse ergibt.