Icon Makefg

Fehler:

Obwohl unter “Kryptografische Schlüsselanbieter” die Konfiguration für SwissSign korrekt erfolgt ist und alle Gatewayrollen via TCP 443 (https) auf ra.swisssign.net Zugriff haben, erscheint beim Abrufen von Zertifikaten folgende Fehlermeldung im Eventlog:
ID: 026f7e58-9be2-4434-b562-11016c181bfd
Created: 12.06.2015 12:15:56
Mail address: Test.Benutzer@nospamproxy.de
Request type: CertificateRequest
Request status: Failed
Failure status: TrustCenterError
Error text: Unexpected error: Message:
An error occurred while sending the request.
Error type:
System.Net.Http.HttpRequestException

Error code: 2148734208
Program location:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<EnrollAsync>d__e.MoveNext()

The request was aborted: Could not create SSL/TLS secure channel.

Message:
The request was aborted: Could not create SSL/TLS secure channel.
Error type:
System.Net.WebException

Error code: 2148734217
Program location:
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

Subject name:E=test.benutzer@nospamproxy.de, CN=Secure Mail: Gateway Certificate

Ursache:

Sowohl im Zertifikatsspeicher des Computerkontos einer oder aller Gatewayrollen sowie im Zertifikatsspeicher des NoSpamProxy Encryption Gateways befindet sich das Pseudo-AutoRAO-Dienstzertifikat zur Authentifizierung beim Dienstanbieter SwissSign.

Lösung:

Unter “Kryptografische Schlüsselanbieter” öffnen Sie die Konfiguration für den Anbieter SwissSign. Hier finden Sie das hinterlegte Pseudo-AutoRAO-Zertifikat. Mit einem Klick auf dieses werden die Zertifikatsdetails angezeigt, die beim Identifizieren des korrekten Zertifikats im Zertifikatsspeicher des Computerkontos hilfreich sind:

SwissSign Provider Configuration

Öffnen Sie nun als Administrator “mmc.exe” auf der Gatewayrolle.

Zertifikatsverwaltung öffnen

Klicken Sie auf “Datei” und “Snap-In hinzufügen/entfernen” (1). Wählen Sie anschließend “Zertifikate” (2) und klicken Sie auf “Hinzufügen” (3). Es erscheint ein neues Fenster, in dem Sie das “Computerkonto” (4) auswählen und mit “Weiter” (5) bestätigen. Wählen Sie den “Lokalen Computer” (6) und klicken Sie auf “Fertigstellen” (7). Sie kehren Zurück zur Snap-In-Auswahl und bestätigen diese mit “OK” (8).

SwissSign Certificate at MS Store

Navigieren Sie nun zu den “Eigene Zertifikate” (1) und finden Sie das Pseudo-AutoRAO-Dienstzertifikat. Wählen Sie dieses aus (2) und löschen Sie es (3). Anschließend starten Sie bitte das betroffene Windows System der Gatewayrolle neu, damit die Änderungen wirksam werden.

Wiederholen Sie diese Schritte ggf. für alle weiteren Gatewayrollen.

Icon Makefg

Verhalten:

In der Ereignisanzeige sehen Sie immer wieder diese Meldung:
---------------
Gateway Role 1088:
Could not secure an inbound connection with the host 192.168.0.100:53627.
Die angegebenen Daten konnten nicht entschlüsselt werden
Error type:
System.ComponentModel.Win32Exception
Error number:2147500037
Program location:
---------------

In der Folge finden Sie auch zum gleichen Zeitpunkt einen SChannel-Fehler im Windows-Anwendungs-Eventlog wie diesen:
---------------
SChannel 36887:
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 51.
---------------

Beachten Sie bitte, dass die ID und der Code sich geringfügig unterscheiden können.

Erklärung:

Windows 2008 R2 und neuer unterstützt von Haus aus bzw. nach einem Windows-Update ältere, schwache Ciphersuites, die als gebrochen gelten, nicht mehr. Daher kommt keine TLS-Verbindung zustande, wenn der einliefernde Server nur diese beherrscht. Als Folge dessen werden die oben genannten Warnungen bzw. Fehler geloggt. Der einliefernde Server muss dann einen Fallback auf Klartext durchführen. Hierzu ist es notwendig, dass der einliefernde Server eine neue Verbindung aufbaut, da die alte Verbindung, bei der keine TLS-Verbindung hergestellt werden konnte, geschlossen werden muss.

Die Unterstützung lediglich veralteter Ciphersuits ist definitiv ein Problem des absendenden Servers, wenn dieser kein Fallback auf Klartext macht, sobald keine TLS-Verbindung erfolgreich zustande kommt. Die Warnungen im Log weisen entsprechend nur darauf hin, dass die Verbindungen nicht zustande kamen, weil der TLS-Handshake nicht funktionierte; sprich sich auf keine Ciphersuite geeinigt werden konnte, da keine gemeinsame gefunden wurde. Manche Server verwenden dann einfach stumpf eine Ciphersuite ihrer Wahl, was dann zu weiteren Meldungen führen kann.

Sollte aufgrund dieses Verhaltens Ihre Kommunikation gestört sein, wenden Sie sich bitte an den Betreiber des einliefernden Servers und weisen ihn auf den hier geschilderten Umstand hin. Es obliegt dann dem Betreiber TLS zu deaktivieren oder seine Lösung dem aktuellen Stand der technischen Entwicklung anzupassen.

Icon Makefg

Fehler:

Bei manchen Benutzern kann der Antwortlink des NoSpamProxy Large Files nicht in die Mail eingefügt werden.

Lösung:

Prüfen Sie bitte, ob per GPO die folgende Sicherheitseinstellung greift:

GPO Einstellung für Antwortlink

Falls ja, setzen Sie bitte die aktivierte Sicherheitseinstellung auf “Disabled”.

Icon Makefg

Wichtig: ​Seit NoSpamProxy das Framework 4.6.2 voraussetzt, funktioniert der unten beschriebene Workaround nicht mehr, da Exchange 2010 nicht kompatibel zum Framework 4.6.2 ist (https://technet.microsoft.com/library/ff728623(v=exchg.150).aspx).

Wenn das Net at Work Mail Gateway ab Version 7.7 und Exchange 2010 auf demselben Server installiert sind, funktioniert die Exchange-Management Konsole nicht mehr ordnungsgemäß. Der Grund hierfür ist das .NET Framework 4.0. Die Exchange-Management-Konsole benötigt als Standardhandler das Framework in der Version 2.0, die NoSpamProxy Management-Konsole hingegen arbeitet ausschließlich mit der Version 4.0. Damit standardmäßig die richtige .NET Framework Version verwendet wird, legt das Net at Work Mail Gateway Setup 7.7 eine Umgebungsvariable mit dem Namen “COMPLUS_ApplicationMigrationRuntimeActivationConfigPath” an. Diese Variable verweist auf einen Pfad in dem eine Config-Datei mit den entsprechenden Einstellungen gespeichert ist. Beim Aufruf jeglicher MMCs wird die entsprechende Variable, und somit die Konfigurationsdatei, verwendet. Beim Öffnen der Exchange MMC verursacht dies die bekannten Probleme. Um die Exchange MMC wieder benutzen zu können, gibt es nur den folgenden Workaround: Die Umgebungsvariable wird dauerhaft gelöscht und die NoSpamProxy MMC muss über eine Batchdatei aufgerufen werden, in der die entsprechende Umgebungsvariable vorher definiert wird. Der Vorteil ist, dass die Umgebungsvariable in diesem Fall nur für Programme angewendet wird, die aus dem Kontext der Batchdatei aufgerufen werden.
Gehen Sie zur Umgehung des Problems wie folgt vor:
Öffnen Sie zunächst den Windows Explorer.

Klicken Sie mit der rechten Maustaste auf “Computer” und wählen Sie dort „Eigenschaften“ aus.

Klicken Sie in diesem Fenster auf “Erweiterte Systemeinstellungen”. Folgendes Fenster öffnet sich:

Klicken Sie hier auf “Umgebungsvariablen”.

Managment Konsole Umgebungsvariablen setzen

Wählen Sie im Fenster „Umgebungsvariablen“ im Abschnitt „Systemvariablen“ auf “COMPLUS_ApplicationMigrationRuntimeActivationConfigPath” aus und klicken anschließend auf “Bearbeiten”. Kopieren Sie sich den Pfad, der im Feld „Wert“ steht, in die Zwischenablage. Anschließend löschen Sie den kompletten Eintrag. Klicken Sie auf OK, Übernehmen und wieder auf OK.

Öffnen Sie nun Notepad. Fügen Sie den gerade kopierten Pfad aus der Zwischenablage in Notepad ein. Zusätzlich fügen Sie bitte folgende Zeilen dazu:
set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=
mmc.exe "C:\Program Files\Net at Work Mail Gateway\NoSpamProxy Management Console\Net at Work Mail Gateway Configuration Console.msc"

Kopieren Sie den Pfad aus der Zwischenablage hinter die erste Zeile ein. Die Notepad-Datei sollte dann sinngemäß wie folgt aufgebaut sein:
set COMPLUS_ApplicationMigrationRuntimeActivationConfigPath=C:\ProgramData\ComPlus Activation Configurations\
mmc.exe "C:\Program Files\Net at Work Mail Gateway\NoSpamProxy Management Console\Net at Work Mail Gateway Configuration Console.msc"

Achtung! Die Dateinamen der Konsole können sich je nach eingesetzter Version unterscheiden. Halten Sie bitte im Zielverzeichnis Ausschau nach der .msc-Datei!

Bitte beachten Sie, dass die Darstellung der Batch-Datei in diesem Artikel durch automatische Zeilenumbrüche verfälscht werden könnte.

Passen Sie zum Schluss ggfs. den Pfad zur Net at Work Mail Gateway Configuration Console.msc an und speichern Sie anschließend den Notepadinhalt als NoSpamProxy-MMC.bat. Wenn Sie die BATCH-Datei aufrufen, sollte sich die NoSpamProxy MMC erfolgreich öffnen lassen. Ab Windows 2008 mit aktiviertem UAC müssen Sie die Batchdatei jedoch stets als Administrator ausführen. Die Exchange MMC sollte sich nun ebenfalls fehlerfrei öffnen lassen.

Icon Makefg

Fehler:

Wenn Smartcard-Lesegeräte zum Einsatz kommen, die über einen Netzwerk-USB-Anschluss angesteuert werden, wird entweder die Smartcard oder das Token auf der Smartcard selber nicht angezeigt.

Status:

Dieser Fehler taucht immer dann auf, wenn die Verbindung in einer RDP Sitzung hergestellt wird.

Lösung:

Die Smartcard-Anbindung über eine netzwerkbasierte USB-Verbindung sollte über den Hyper-V Manager oder den VMWare Manager in einer direkten Verbindung zur VM hergestellt werden.

Icon Makefg

Fehler:

Die NoSpamProxy Management Konsole lässt sich starten, jedoch stürzt diese ab, sobald ein Untermenü aufgerufen wird. Dieses Problem tritt bei einem anderen bzw. neuen Benutzer nicht auf.

Status:

Die NoSpamProxy Management Konsole legt beim Aufruf temporäre Dateien im temporären Ordner des Benutzerverzeichnisses an. In diesem befinden sich jedoch mehr als 65.535 Dateien, was zu Problemen im NTFS-Dateisystem führt.

Lösung:

Der betroffene Benutzer führt folgenden Befehl über Start -> Ausführen aus:
rmdir /s /q %temp%

Nach Abschluss des Befehls funktioniert die Konsole wieder ordnungsgemäß.

Icon Makefg

Fehler:

Ohne erkennbaren Grund, starten auf einmal die Dienste des NoSpamProxy nicht mehr. Re-Installation funktioniert nicht. In der Ereignisanzeige wird folgender Fehler angezeigt:
Protokollname: System
Quelle: Microsoft-Windows-HttpEvent
Datum: 14.03.2012 14:42:55
Ereignis-ID: 15005
Aufgabenkategorie: Keine
Ebene: Fehler
Schlüsselwörter: Klassisch
Benutzer: Nicht zutreffend

Beschreibung: Der zugrunde liegende Transport für [::]:6060 kann nicht gebunden werden. Möglicherweise enthält die Liste nur zum Abhören von IP einen Verweis auf eine Schnittstelle, die gegebenenfalls auf diesem Computer nicht vorhanden ist. Das Datenfeld enthält die Fehlernummer.

Status:

Dieses Problem tritt in Verbindung mit IPv6 auf. Der “Net TCP Portfreigabe”-Dienst bekommt dann keine Verbindung mehr. Die genaue Ursache ist bislang ungeklärt.

Lösung 1:

Geben Sie auf der Kommandozeile folgenden Befehl ein:
netsh http add iplisten ipaddress=0.0.0.0

Anschließend starten die Dienste des Net at Work Mail Gateways wieder.

Lösung 2:

Geben Sie auf der Kommandozeile folgenden Befehl ein:
netstat -ano >netstat.txt

Kontrollieren Sie in der netstat.txt ob evtl. ein Prozess den Port 6060 belegt. Wenn dem so sein sollte, wird die entsprechende PID (Prozess-ID) angezeigt. Mittels Taskmanager können Sie dann herausfinden, zu welchem Prozess die PID gehört. Anschließend gilt es zu klären, ob der Prozess entsprechend angepasst werden kann, oder nicht.

Icon Makefg

Fehler:

Bei der Erstellung der Verbindung zwischen der Intranetrolle und der Gatewayrolle kommt die Fehlermeldung “The security protocol cannot verify the incoming message”. Der Dialog terminiert in einer Fehlermeldung und das Verbindungsobjekt wird anschließend auch nicht erstellt.

Status:

Dieses Problem tritt auf, wenn die beiden Rollen auf unterschiedlichen Servern installiert wurden und die Uhrzeiten um mehr als 5 Minuten differieren.

Lösung:

Passen Sie die Uhrzeiten auf beiden Systemen an.