Gelöst Nach Update auf 15.2 - Fehlermeldungen zur mime-detection im Windows-Event-Log

[J.Koester]

Hallo,
ich habe das Update von 15.1 auf 15.2 eingespielt. Seit dem erscheint im Windows-Event-Log des Web-Portal-Servers nachfolgende Warnmeldung. Wir setzen einen Web-Proxy ein und die mir bekannten Web-Proxy-Einstellungen habe ich von 15.1 in den Konfigurationsdateien übernommen. Habe ich etwas vergessen?

Viele Grüße
Jürgen

Category: Yarp.ReverseProxy.Health.ActiveHealthCheckMonitor
EventId: 17

Probing destination `NoSpamProxy.MimeDetection0` on cluster `NoSpamProxy.MimeDetection` failed.

Exception:
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.IO.IOException: Received an unexpected EOF or 0 bytes from the transport stream.
at System.Net.Security.SslStream.<ReceiveHandshakeFrameAsync>d__151`1.MoveNext() + 0x1d9
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Security.SslStream.<ForceAuthenticationAsync>d__150`1.MoveNext() + 0x846
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Http.ConnectHelper.<EstablishSslConnectionAsync>d__2.MoveNext() + 0x160
--- End of inner exception stack trace ---
at System.Net.Http.ConnectHelper.<EstablishSslConnectionAsync>d__2.MoveNext() + 0x422
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Http.HttpConnectionPool.<ConnectAsync>d__103.MoveNext() + 0xbe2
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Http.HttpConnectionPool.<AddHttp2ConnectionAsync>d__83.MoveNext() + 0x3d5
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.<WaitWithCancellationAsync>d__1.MoveNext() + 0x162
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Threading.Tasks.ValueTask`1.get_Result() + 0x5a
at System.Net.Http.HttpConnectionPool.HttpConnectionWaiter`1.<WaitForConnectionWithTelemetryAsync>d__6.MoveNext() + 0x171
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Http.HttpConnectionPool.<SendWithVersionDetectionAndRetryAsync>d__89.MoveNext() + 0x7f8
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at System.Net.Http.Metrics.MetricsHandler.<SendAsyncWithMetrics>d__5.MoveNext() + 0x22e
--- End of stack trace from previous location ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() + 0x20
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task) + 0xb2
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task, ConfigureAwaitOptions) + 0x4b
at Yarp.ReverseProxy.Health.ActiveHealthCheckMonitor.<ProbeDestinationAsync>d__18.MoveNext() + 0x2a9

 

[J.Koester]

Hallo,
kurze Ergänzung. Die Meldung erscheint ca. alle 5 Sekunden. Welche Funktionseinschränkungen gehen ggf. damit einher?

Viele Grüße
Jürgen

 

[J.Koester]

Hallo,
ich nochmal. Habe nun mal TCPView von Sysinternals zu Hilfe genommen, um zu sehen, wohin der Process/Dienst sich den verbinden möchte. Leider ohne weitere Erkenntnis. Die Threads starten und beenden sich sekündlich. Für Tipps bin ich dankbar.

Viele Grüße
Jürgen

 

[JanJäschke]

Hallo Jürgen,

die MimeDetection arbeitet aktuell nicht korrekt.
Hast du in deiner Proxy Konfiguration den Bypass für "localhost" vergessen?

Gruß,
Jan

 

[J.Koester]

Hallo,
es ist kein "System-Proxy" konfiguriert. Die Proxy-Server-Konfigutation ist in folgenden Konfig-Datei manuell gesetzt:

C:\Program Files\NoSpamProxy\Web Portal\Web.config
-> usesystemdefault="true"
-> proxyaddress="http://[IP]:[Port]"
-> bypassonlocal="true"
C:\Program Files\NoSpamProxy\Core Antispam Engine\appsettings.json
-> "Address": "http://[IP]:[Port]"
-> "BypassOnLocal": true
C:\ProgramData\Net at Work Mail Gateway\Core Antispam Engine\bdamserver.conf
-> kein Bypass gesetzt
C:\Program Files\NoSpamProxy\Core Antispam Engine\bdnc.ini
-> kein Bypass gesetzt

Die Proxy-Server-Konfigruation ist aus der Version 15.1 übernommen. Fehlt noch etwas? Falls ja, an welcher Stelle genau?
Bereits vorab, vielen Dank!

Viele Grüße
Jürgen

 

[JanJäschke]

Sind auf dem System zufällig folgende System Variablen gesetzt:
http_proxy
https_proxy
Oder läuft ggf eine endpoint Projektion die TLS Traffic überwacht?

 

[J.Koester]

Hallo Jan,

tatsächlich, es gibt eine Umgebungsvariabel HTTPS_Proxy.

Gruß
Jürgen

 

[JanJäschke]

wenn du keinen Grund für diese hast:
Löschen dann sollte es besser werden ^^

Oder schau ob es eine „NO_PROXY“ variable gibt. Falls nicht kannst du damit den Bypass setzen.
(Die Variable erwartet eine kommaseparierte Liste)

 

[J.Koester]

Hallo Jan,

zunächst habe ich die vorhandene NO_PROXY-Variabel erweitert um localhost,127.0.0.1,[anderer Server] und den Windows-Server neugestartet. Leider ohne Besserung.
Dann habe ich die System-Variablen "HTTPS_PROXY" und "NO_PROXY" gelöscht und ebenfalls den Windows-Server neugestartet. Und leider immer noch ohne Besserung.
Hier nochmal ein Auszung vom TCP-View:


Der Konsolenbefehl "set | findstr /I PROXY" gibt keine Einträge zurück.

Hast du weitere Tipps?

Viele Grüße
Jürgen

 

[JanJäschke]

Guten Morgen Jürgen,

dann fällt mir nur noch ein, deine Proxy Konfiguration einmal hier zu hinterlegen:
"C:\Program Files\Net at Work Mail Gateway\External Process Manager\NoSpamProxy.MimeDetection\NoSpamProxy.MimeDetection.dll.config" bzw. "C:\Program Files\NoSpamProxy\External Process Manager\NoSpamProxy.MimeDetection\NoSpamProxy.MimeDetection.dll.config".
Syntax ist wie hier beschrieben: https://docs.nospamproxy.com/Server...-web-proxy-for-nospamproxy-9-2-and-higher.htm
Danach dann einmal den Service "NoSpamProxy - External Process Manager" neustarten.

Gruß
Jan

 

[J.Koester]

Hallo Jan,

es ist ein wenig frustrierend. Nach Anpassung der config-Datei konnte ich den Dienst erfolgreich neustarten - jedoch ohne Besserung.
Vielleicht hast du doch noch weitere Ideen?

Viele Grüße
Jürgen

 

[JanJäschke]

Das kann ich gut nachvollziehen. Theoretisch könntest du ggf. nun requests im Proxy log sehen welche geloggt werden.
Ich gehe aber mal nicht davon aus sondern eher, dass es etwas ist was lokal die TLS Verbindung unterbricht oder vlt fehlender Zugriff auf den Private Key beim eigenen TLS Zertifikat. Letzteres kann ich grade mal prüfen.

 

[J.Koester]

Hallo Jan,

ich habe nun noch folgendes probiert:
1) Reparatur-Installation von "external-process-manger"
2) Installation des wildcard-Zertifikats inkl. Private Key im benutzerbezogene Zertifikatsspeicher unter "eigene Zertifikate". Im Zertifikatsspeicher des Systems war es bereits installiert.

Beides leider ohne Erfolg, auch nach Neustart des gesamten Systems.

Im TCP-View sieht man, dass keine externen Anfragen des Prozesses "C:\Program Files\NoSpamProxy\External Process Manager\NoSpamProxy.MimeDetection\NoSpamProxy.MimeDetection.exe" erfolgen. Die Logs am Gateway sind auch weiterhin leer.

In der Fehlermeldung heisst es: "The SSL connection could not be established, see inner exception." Die Vermutung liegt also nahe, dass es ein SSL/TLS-Problem ist. Hast du noch Ideen? Leider gibt es keine weiteren Logs zum Verbindungsversuch, oder zumindest kenne ich diese nicht.

Viele Grüße
Jürgen

 

[J.Koester]

Hallo Jan,

ich habs gelöst!
Es war eine weitere Berechtigung für den Service "NoSpamProxyExternalProcessManager" auf den privaten Schlüssel des Server-Zertifikats erforderlich. Es war das Zertifikat welches bei der Installation von NoSpamProxy automatisch installiert und genutzt wird für die interne Kommunikation der NoSpamProxy-Dienste. Die Dienste "NoSpamProxyManagementService" und "NospamproxyPrivilegedService" waren bereits berechtigt.

Im System-Log war übrigens noch ein Hinweis:
Schwerwiegender Fehler beim Zugriff auf den privaten Schlüssel der Server-Anmeldeinformationen für TLS. Der vom kryptografischen Modul zurückgegebene Fehlercode lautet 0x8009030D. Der interne Fehlerstatus ist 10001.
Der SSPI-Clientprozess ist NoSpamProxy.MimeDetection (PID: 7828).

Das Prinzip, wie man Berchtigungen setzt, ist auch in einen YouTube-Video "NoSpamProxy | Step by step zu einem mandantenfähigen NoSpamProxy" erklärt (siehe 16:52 Berechtigungen für den TLS SMTP Key setzen).

DANKESCHÖN für deine Unterstützung!

Viele Grüße
Jürgen

 

[JanJäschke]

Hallo Jürgen,

Danke für das Feedback, genau das war der Gedanke den ich noch prüfen wollte.
Leider kam der Alltag dazwischen :S
Umso erfreulicher, dass du die Lösung Gefunden und ausführlich geteilt hast


Beste Grüße,
Jan

 

[J.Koester]

Guten Morgen Jan,

dein Tipp war Gold wert! Dankeschön nochmal!

Viele Grüße
Jürgen

 

[869288141]

Hallo @JanJäschke ,

Es war eine weitere Berechtigung für den Service "NoSpamProxyExternalProcessManager" auf den privaten Schlüssel des Server-Zertifikats erforderlich.

den Namen "NoSpamProxyExternalProcessManager" höre ich heute zum ersten Mal. Ist der neu?

 

[JanJäschke]

Hmm den müsste es eigentlich ab Version 15.0 geben
Aber Nagel mich nicht darauf fest.
CDR wurde z.B. über diesen ausgelagert um bei massiven Problemen nicht mehr das ganze Gateway lahmzulegen. In solchen Fällen wird nun einfach vom ExternalProcessManager der CDR Prozess beendet und neugestartet

 

[869288141]

Hmm den müsste es eigentlich ab Version 15.0 geben

Da ist auf jeden Fall der Dienst dazu gekommen. Mir war aber nicht klar, dass der Service bzw. Account auch Zugriff auf das SSL-Zertifikat benötigt. Weil auch in der Doku (https://docs.nospamproxy.com/Server...er.htm?Highlight=NoSpamProxyPrivilegedService) lese ich nichts dazu.

Abgesehen davon haben bereits sehr viele Kunden auf 15.x gewechselt. D.h. es müsste doch eine Flut an Rückmeldungen beim Support (und hier im Forum) geben, dass die Funktionalität beeinträchtigt ist. Es ist aber meines Wissens nach die erste Meldung ist. Habt mir beim Upgrade auf 15.x den Service Account automatisch auf das SSL-Zertifikat berechtigt?

CDR wurde z.B. über diesen ausgelagert um bei massiven Problemen nicht mehr das ganze Gateway lahmzulegen. In solchen Fällen wird nun einfach vom ExternalProcessManager der CDR Prozess beendet und neugestartet

Sehr gute Optimierung.

 

[JanJäschke]

Jap. Der Service Account sollte eigentlich die Rechte voll automatisch bei der Installation / Update bekommen.
Daher auch etwas seltsam dass die Rechte fehlen. Wir hatten aber auch immer mal wieder, dass dem GW nach dem Update die Rechte fehlen. Also ggf. etwas Windows internes. Mal schauen ob wir da mehr zu finden können