Bei einem wenige Tagen altem MDaemon Email Server fielen mir etliche Fehler im Ereignisprotokoll-System von dieser Art auf:

Protokollname: System
Quelle:        Schannel
Datum:         16.11.2017 15:56:12
Ereignis-ID:   36888
Aufgabenkategorie:Keine
Ebene:         Fehler
Schlüsselwörter:
Benutzer:      SYSTEM
Computer:      srv02.domain.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet.
Dies kann dazu führen, dass die Verbindung beendet wird.
Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 20.
Der Windows-SChannel-Fehlerstatus lautet: 960.

Kurz beim Support nachgefragt, kam der Tipp zurück, zum einen den Webserver via

https://www.ssllabs.com/ssltest/

zu prüfen. Out-of-the-box liefert dies ein eher schlechtes Ergebnis, es sei denn man hat schon etwas getan oder z.B. ein Reverse Proxy, Security Gateway o.ä. vor den Webserver geschaltet. Als weiterer Hinweis kam, man solle mit folgendem Tool die Best Practice in Sachen SSL/TLS anwenden und neu starten:

IIS Crypto (Download)

Wie hängt das nun mit dem MDaemon zusammen?

Die Antwort darauf liefert alt-n in seinem Blog:

The encryption protocol and cipher used by MDaemon and SecurityGateway
depend on the operating system and can be configured via the registry.
You can use the free IIS Crypto tool to set the appropriate registry keys.
More information can be found here:
https://www.nartac.com/Products/IISCrypto

Quelle: SecurityGateway 4.5.1 – With Integrated Encryption, Tracking & E-Sign with RMail!

Bevor man nun Blindlinks IIS Crypto laufen lässt, sollte man sich darüber im Klaren sein, was alles von SSL/TLS abhängig ist. Dabei spielt eine Rolle was alles auf dem Server läuft. Lesenswert dazu ist dieser Artikel von Rob Willis:

RobWillis.info – Hardening SSL & TLS connections on Windows Server 2008 R2 & 2012 R2

Danksagung

Vielen Dank an den Support von EBERTLANG für die schnelle Antwort und die Tipps.

Update 16.11.2017 – 20:29

Bei einer Prüfung mit Qualys SSL Server Test gegenüber einem Kerio Connect-Server, der auf einem Windows Server läuft, erhält man man out-of-the-box die Note A (sofern man ein öffentliches Zertifikat nutzt). Verwendet man ein selbst-signiertes Zertifikat, erhält man ein T mit dem Hinweis, wenn man dies ignoriert, es ein A wäre.

Daraus kann man gut Erkennen, das es darauf ankommt, ob Windows-Bordmittel verwendet werden oder ob der jeweilige Webserver eigene Komponenten und Konfigurationen nutzt.

Update 07.11.2024

Dieser Tage haben wir bei einem Kunden-Server (ebenfalls in Verbindung mit dem MDaemon Email Server) vermehrt Schwierigkeiten bei der Aushandlung von SSL/TLS beim E-Mail-Versand via SMTP beobachtet. Im Log stellt sich dies wie folgt dar:

…
Wed 2024-11-06 07:01:04.206: 02: <– 220 2.0.0 Ready to start TLS
Wed 2024-11-06 07:01:04.221: 04: * SSL negotiation failed, error code 0x80090326
Wed 2024-11-06 07:01:04.221: 04: * XXX.XXX.XXX.XXX added to temporary SSL white list; will retry delivery soon
…

Kurzum: Man wird sich nicht einig und die Zustellung kommt letztlich (auch nicht später) zu Stande. Wird ein Smarthost als Backup verwendet, klappt der Versand dann mitunter dennoch (selbst beobachtet mit ALL-INKL.COM und IONOS).

Abhilfe schafft das Herunterladen und Ausführen des oben erwähnten IIS Crypto-Tools.

In diesem Fall griffen vermutlich noch veraltete Einstellungen, da der Server per Inplace Upgrade von Windows Server 2012 R2 zu Windows Server 2022 aktualisiert wurde. Denkbar ist allerdings auch das eine andere installierte Anwendung die Konfiguration verändert hat oder einer der Firmen-Admins verantwortlich ist.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.