Warnung 1088 taucht regelmäßig in der Ereignisanzeige auf
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.
