none
Exchange 2010 - Schannel Fehler - Event ID 36874 / 36888 - TLS Problem RRS feed

  • Frage

  • Hi!

    Ich habe seit einigen Tagen auf unserem Exchange Server 2010 einige Probleme. Begonnen hatten diese mit dem "Update rollup 12 für Exchange Server 2010 Service Pack 3 (KB3096066)" . Dieses wurde heute wieder deinstalliert. Die Fehler blieben bestehen.

    Aufgrund der Fehler bleiben Mails oft in der Warteschlange hängen. Benutzer erhalten dan die Nachricht der verzögerung oder nach 1 Tag die unzustellbar Nachricht. Wenn Mails in der Warteschlange hängen, kann ich diese mit "wiederholen" rausschicken, geht aber auch nicht immer beim Ersten mal.

    Der Fehler tritt nicht bei allen Mailservern an die wir Mails schicken ein, aber doch bei vielen.

    Fehlerbeschreibung:
    Es tauchen seit mehreren Tagen immer die selben Fehler in der Ereignisanzeige auf:

    Schannel - Event ID 36888
    Es wurde eine schwerwiegende Warnung generiert: 10. Der interne Fehlerstatus lautet: 10.

    Schannel - Event ID 36874
    Eine SSL 2.0-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.


    In den SMTP Sendlogs habe ich gleichzeitig seit diesem Problem diese einträge bei jedem Mail das rausgeht gefunden:

    TLS negotiation failed with error SocketError

    oder

    TLS negotiation failed with error AlgorithmMismatch

    oder

    TLS negotiation failed with error InvalidToken

    Je nachdem an welchen Email Server gesendet wird.


    SMTP LOG an GMAIL:

    192.168.0.35:35588,173.194.72.27:25,<,220 mx.google.com ESMTP y19si27132759pfa.62 - gsmtp,
    192.168.0.35:35588,173.194.72.27:25,>,EHLO webmail.evolaris.net,
    192.168.0.35:35588,173.194.72.27:25,<,"250-mx.google.com at your service, [212.186.217.227]",
    192.168.0.35:35588,173.194.72.27:25,<,250-SIZE 157286400,
    192.168.0.35:35588,173.194.72.27:25,<,250-8BITMIME,
    192.168.0.35:35588,173.194.72.27:25,<,250-STARTTLS,
    192.168.0.35:35588,173.194.72.27:25,<,250-ENHANCEDSTATUSCODES,
    192.168.0.35:35588,173.194.72.27:25,<,250-PIPELINING,
    192.168.0.35:35588,173.194.72.27:25,<,250-CHUNKING,
    192.168.0.35:35588,173.194.72.27:25,<,250 SMTPUTF8,
    192.168.0.35:35588,173.194.72.27:25,>,STARTTLS,
    192.168.0.35:35588,173.194.72.27:25,<,220 2.0.0 Ready to start TLS,
    192.168.0.35:35588,173.194.72.27:25,*,,Sending certificate
    192.168.0.35:35588,173.194.72.27:25,*,"CN=webmail.evolaris.net, OU=COMODO SSL Unified Communications, OU=Domain Control Validated",Certificate subject
    192.168.0.35:35588,173.194.72.27:25,*,"CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB",Certificate issuer name
    192.168.0.35:35588,173.194.72.27:25,*,009A5742EE94E2A8********,Certificate serial number
    192.168.0.35:35588,173.194.72.27:25,*,35E312D9CFC138A2ABBB*********,Certificate thumbprint
    192.168.0.35:35588,173.194.72.27:25,*,webmail.evolaris.net;autodiscover.Evolaris.evolaris.net;autodiscover.evolaris.net;evoexchange.evolaris.evolaris.net,Certificate alternate names
    192.168.0.35:35588,173.194.72.27:25,*,,TLS negotiation failed with error SocketError


    Komme nun seit mehreren Tagen nicht weiter und bin für jeden Tipp und unterstützung sehr Dankbar.

    Liebe Grüße

    Markus






    Mittwoch, 30. März 2016 20:49

Antworten

  • Moin Markus,

    zwei der Fehlermeldungen sind Protokollfehler. Du verwendest eine Verschlüsselung, die Dein Gegenüber nach Drown, Poodle, etc. nicht unterstützt. Ich lese zwar oben
    TLS negotiation failed with error AlgorithmMismatch
    TLS negotiation failed with error InvalidToken
    mit dem Wort "TLS", aber nach http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx kann das wohl auch bei SSLx auftreten.

    Mach doch mal zunächst SSL2 und SSL3 aus, falls Du kein günstigeres Verfahren hast, verwende z.B.  

    https://gallery.technet.microsoft.com/Configuring-the-settings-a1c79f2d

    Ob das auch schon den TLS negotiation failed with error SocketError beseitigt, kann ich zurzeit nicht abschätzen. Allerdings empfehle ich Dir mal den Test Deines Webservers (ich weiss, dass es hier um SMTP geht) mit ssllabs.com ; Du hast da einige Findings, die zu beheben wären. Dann sollte es auch mit TLS wieder funktionieren.

    Lass mich wissen, ob es bzgl. der beiden Meldungen geholfen hat.

    Viele Grüße,
    Martin

    Donnerstag, 31. März 2016 07:07

Alle Antworten

  • Moin,

    der Schannel Code 10 ist leider sehr unspezifisch und sagt, dass in der SSL/TLS Kommunikation irgendeine protokolltechnisch unerwartete Info enthalten war.

    Kann es sein, dass ihr an den SSL/TLS-Einstellungen und Chipher-Suites rumgedreht habt und dort zu viel deaktiviert habt? Exchange braucht zwingend TLS1.0+1.1+1.2. SSL kann man deaktivieren.

    Oder hängt da im SMTP-Kanal eventuell ein anderes Geräte (Proxy, Firewall) drin, dass irgendwas an der Kommunikation schraubt.

    Microsoft hat zwar einen Bug in TLS im RU12 behoben, der führt aber zum Absturz des Transportdienstes.

    Du könntest es aber auch noch mal mit RU13 probieren, dass vor gut 14 Tagen erschienen ist.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Donnerstag, 31. März 2016 06:50
  • Moin Markus,

    zwei der Fehlermeldungen sind Protokollfehler. Du verwendest eine Verschlüsselung, die Dein Gegenüber nach Drown, Poodle, etc. nicht unterstützt. Ich lese zwar oben
    TLS negotiation failed with error AlgorithmMismatch
    TLS negotiation failed with error InvalidToken
    mit dem Wort "TLS", aber nach http://blogs.technet.com/b/exchange/archive/2015/07/27/exchange-tls-amp-ssl-best-practices.aspx kann das wohl auch bei SSLx auftreten.

    Mach doch mal zunächst SSL2 und SSL3 aus, falls Du kein günstigeres Verfahren hast, verwende z.B.  

    https://gallery.technet.microsoft.com/Configuring-the-settings-a1c79f2d

    Ob das auch schon den TLS negotiation failed with error SocketError beseitigt, kann ich zurzeit nicht abschätzen. Allerdings empfehle ich Dir mal den Test Deines Webservers (ich weiss, dass es hier um SMTP geht) mit ssllabs.com ; Du hast da einige Findings, die zu beheben wären. Dann sollte es auch mit TLS wieder funktionieren.

    Lass mich wissen, ob es bzgl. der beiden Meldungen geholfen hat.

    Viele Grüße,
    Martin

    Donnerstag, 31. März 2016 07:07
  • Schönen guten Morgen!

    Ich habe tatsächlich wegen Drown vor dem RU12 dieses hier durchgeführt:

    http://www.itprocentral.com/drown-attack-and-exchange-server/

    Ich werde mal mittels den Meldungen aus ssllabs.com mich durcharbeiten. Und das RU12 und RU13 einspielen.

    Danke für die ersten Tipps.

    Liebe Grüße

    Markus

    Donnerstag, 31. März 2016 07:46
  • Moin,

    Tipp: Nicht selbst an der Registry rumspielen! Da sind manchmal Keys auf den ersten Blick doppelt, und erst auf den zweiten sieht man, dass das einmal Server und einmal Client ist.

    Offensichtlich hast Du da was abgeschaltet, was Du nicht hättest abschalten sollen.

    Nimm dafür den hier:

    https://www.nartac.com/Products/IISCrypto

    Runterladen, ausführen, "Best Practise" + "Apply" und Reboot.

    Der setzt alle Keys automatisch und schaltet die nach heutiger Sicht unsicheren Dinge ab, die man abschalten kann.

    Schneller geht nicht. ;)


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Als Antwort vorgeschlagen Gudel, Martin Donnerstag, 31. März 2016 14:25
    Donnerstag, 31. März 2016 08:10
  • Am 31.03.2016 schrieb Markus Schüssler:
    Moins,

    Ich habe tatsächlich wegen Drown vor dem RU12 dieses hier durchgeführt:

    http://www.itprocentral.com/drown-attack-and-exchange-server/

    Einfacher wärs, du nimmst:
    https://www.nartac.com/Products/IISCrypto/

    Und klickst auf den "Best Practise" Button. ;)

    Bye
    Norbert

    Donnerstag, 31. März 2016 08:11
  • Hallo!

    ich habe nun ein Overall Rating von F auf A geschafft auf www.ssllabs.com

    Habe jetzt einmal das RU12 und RU13 eingespielt und von https://www.nartac.com/Products/IISCrypto "Best Practise" ausgeführt und neugestartet.

    Zusätzlich zum Exchange 2010 läuft auf dem selben Rechner der GFI MailEssentials und der Server steht hinter einer Cisco ASA Firewall.

    Akuell tretten immer noch diese Fehler im Ereignislog auf:

    Schannel 36874
    Eine SSL 2.0-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Schannel 36874
    Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Schannel 36888
    Es wurde eine schwerwiegende Warnung generiert: 40. Der interne Fehlerstatus lautet: 1205.

    Schannel 36888
    Es wurde eine schwerwiegende Warnung generiert: 20. Der interne Fehlerstatus lautet: 960.

    Donnerstag, 31. März 2016 09:46
  • Hallo!

    ich habe nun ein Overall Rating von F auf A geschafft auf www.ssllabs.com

    Habe jetzt einmal das RU12 und RU13 eingespielt und von https://www.nartac.com/Products/IISCrypto "Best Practise" ausgeführt und neugestartet.

    Zusätzlich zum Exchange 2010 läuft auf dem selben Rechner der GFI MailEssentials und der Server steht hinter einer Cisco ASA Firewall.

    Akuell tretten immer noch diese Fehler im Ereignislog auf:

    Schannel 36874
    Eine SSL 2.0-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Schannel 36874
    Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Schannel 36888
    Es wurde eine schwerwiegende Warnung generiert: 40. Der interne Fehlerstatus lautet: 1205.

    Schannel 36888
    Es wurde eine schwerwiegende Warnung generiert: 20. Der interne Fehlerstatus lautet: 960.

    Donnerstag, 31. März 2016 09:47
  • Am 31.03.2016 schrieb Markus Schüssler:
    Hi,

    ich habe nun ein Overall Rating von F auf A geschafft auf www.ssllabs.com

    Habe jetzt einmal das RU12 und RU13 eingespielt und von https://www.nartac.com/Products/IISCrypto "Best Practise" ausgeführt und neugestartet.

    Na das klingt doch gut.

    Zusätzlich zum Exchange 2010 läuft auf dem selben Rechner der GFI MailEssentials und der Server steht hinter einer Cisco ASA Firewall.

    Fummelt die ASA am SSL (SMTP und/oder https) rum? Da gabs immer sowas wie SMTP Fixup:
    https://support.microsoft.com/en-us/kb/320027

    Akuell tretten immer noch diese Fehler im Ereignislog auf:

    Schannel 36874
    Eine SSL 2.0-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Logisch, hast du ja abgeschaltet. ;)

    Schannel 36874
    Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

    Auch logisch. Steht ja da, dass keine gemeinsame Verschlüsselung gefunden wurde.
     Wenn du keine Probleme hast, würd ich das erstmal so belassen und beobachten. Ist für mich nicht total ungewöhnlich, dass natürlich nicht jeder mit einem modernen Verfahren klar kommt. Dann passiert notfalls ein Fallback auf Klartext oder eben gar keine Kommunikation.

    Bye
    Norbert

    Donnerstag, 31. März 2016 10:13
  • Einige Mails hängen nun immer noch in der Warteschlange. Wenn ich selbst auf "wiederholen" klicke gehen sie Raus, davor gibt es im SMTP Log aber lauter Fehler Wie

    "Failed to connect. Error Code: 10051, Error Message: Ein Socketvorgang bezog sich auf ein nicht verfügbares Netzwerk 2404:6800:4008:c01::1a:25"

    attempting to connect
    "Failed to connect. Error Code: 10051, Error Message: Ein Socketvorgang bezog sich auf ein nicht verfügbares Netzwerk 2404:6800:4003:c00::1a:25"
    attempting to connect
    "Failed to connect. Error Code: 10051, Error Message: Ein Socketvorgang bezog sich auf ein nicht verfügbares Netzwerk 2404:6800:4008:c06::1b:25"
    ,attempting to connect

    Warteschlange:

    "Nächste Hopdomäne"    Zustellungstyp    Status    Nachrichtenanzahl    "Nächster Wiederholungszeitpunkt"    "Letzter Fehler"

    styrian-leading.eu    DnsConnectorDelivery    Wiederholen    1    "Donnerstag, 31. März 2016 13:09:56"    "451 4.4.0 Primary target IP address responded with: ""421 4.4.2 Connection dropped due to ConnectionReset."" Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts."

    gmail.com    DnsConnectorDelivery    Wiederholen    1    "Donnerstag, 31. März 2016 13:06:10"    "451 4.4.0 Primary target IP address responded with: ""421 4.4.2 Connection dropped due to SocketError."" Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts."


    192.168.0.35:38816,64.233.188.26:25,<,220 mx.google.com ESMTP m16si24740383igt.54 - gsmtp,
    192.168.0.35:38816,64.233.188.26:25,>,EHLO webmail.evolaris.net,
    192.168.0.35:38816,64.233.188.26:25,<,"250-mx.google.com at your service, [212.186.217.227]",
    192.168.0.35:38816,64.233.188.26:25,<,250-SIZE 157286400,
    192.168.0.35:38816,64.233.188.26:25,<,250-8BITMIME,
    192.168.0.35:38816,64.233.188.26:25,<,250-STARTTLS,
    192.168.0.35:38816,64.233.188.26:25,<,250-ENHANCEDSTATUSCODES,
    192.168.0.35:38816,64.233.188.26:25,<,250-PIPELINING,
    192.168.0.35:38816,64.233.188.26:25,<,250-CHUNKING,
    192.168.0.35:38816,64.233.188.26:25,<,250 SMTPUTF8,
    192.168.0.35:38816,64.233.188.26:25,>,STARTTLS,
    192.168.0.35:38816,64.233.188.26:25,<,220 2.0.0 Ready to start TLS,
    192.168.0.35:38816,64.233.188.26:25,*,,Sending certificate
    192.168.0.35:38816,64.233.188.26:25,*,"CN=webmail.evolaris.net, OU=COMODO SSL Unified Communications, OU=Domain Control Validated",Certificate subject
    192.168.0.35:38816,64.233.188.26:25,*,"CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB",Certificate issuer name
    192.168.0.35:38816,64.233.188.26:25,*,009A5742EE94E2A83E151797CC072EC5FF,Certificate serial number
    ,192.168.0.35:38816,64.233.188.26:25,*,35E312D9CFC138A2ABBB426FF8859CCEB45D7D7D,Certificate thumbprint
    192.168.0.35:38816,64.233.188.26:25,*,webmail.evolaris.net;autodiscover.Evolaris.evolaris.net;autodiscover.evolaris.net;evoexchange.evolaris.evolaris.net,Certificate alternate names
    192.168.0.35:38816,64.233.188.26:25,*,,TLS negotiation failed with error SocketError
    192.168.0.35:38816,64.233.188.26:25,-,,Remote

    2404:6800:4008:c01::1a:25,*,,attempting to connect
    2404:6800:4008:c01::1a:25,*,,"Failed to connect. Error Code: 10051, Error Message: Ein Socketvorgang bezog sich auf ein nicht verfügbares Netzwerk 2404:6800:4008:c01::1a:25"

    173.194.72.26:25,*,,attempting to connect
    192.168.0.35:38824,173.194.72.26:25,+,,
    192.168.0.35:38824,173.194.72.26:25,<,220 mx.google.com ESMTP kn6si13509989pab.36 - gsmtp,
    192.168.0.35:38824,173.194.72.26:25,>,EHLO webmail.evolaris.net,
    192.168.0.35:38824,173.194.72.26:25,<,"250-mx.google.com at your service, [212.186.217.227]",
    192.168.0.35:38824,173.194.72.26:25,<,250-SIZE 157286400,
    192.168.0.35:38824,173.194.72.26:25,<,250-8BITMIME,
    192.168.0.35:38824,173.194.72.26:25,<,250-STARTTLS,
    192.168.0.35:38824,173.194.72.26:25,<,250-ENHANCEDSTATUSCODES,
    192.168.0.35:38824,173.194.72.26:25,<,250-PIPELINING,
    192.168.0.35:38824,173.194.72.26:25,<,250-CHUNKING,
    192.168.0.35:38824,173.194.72.26:25,<,250 SMTPUTF8,
    192.168.0.35:38824,173.194.72.26:25,>,STARTTLS,
    192.168.0.35:38824,173.194.72.26:25,<,220 2.0.0 Ready to start TLS,
    192.168.0.35:38824,173.194.72.26:25,*,,Sending certificate
    192.168.0.35:38824,173.194.72.26:25,*,"CN=webmail.evolaris.net, OU=COMODO SSL Unified Communications, OU=Domain Control Validated",Certificate subject
    192.168.0.35:38824,173.194.72.26:25,*,"CN=COMODO RSA Domain Validation Secure Server CA, O=COMODO CA Limited, L=Salford, S=Greater Manchester, C=GB",Certificate issuer name
    192.168.0.35:38824,173.194.72.26:25,*,009A5742EE94E2A83E151797CC072EC5FF,Certificate serial number
    192.168.0.35:38824,173.194.72.26:25,*,35E312D9CFC138A2ABBB426FF8859CCEB45D7D7D,Certificate thumbprint
    192.168.0.35:38824,173.194.72.26:25,*,webmail.evolaris.net;autodiscover.Evolaris.evolaris.net;autodiscover.evolaris.net;evoexchange.evolaris.evolaris.net,Certificate alternate names
    192.168.0.35:38824,173.194.72.26:25,*,,TLS negotiation failed with error SocketError
    192.168.0.35:38824,173.194.72.26:25,-,,Remote
    66.102.1.26:25,*,,attempting to connect

    DNS Problem kann es nicht sein oder?

    Liebe Grüße Markus

    Donnerstag, 31. März 2016 11:14
  • Auf der ASA ist bei den Service Policy Rules ESMTP deaktiviert - somit sollte die nichts an der komunikation ändern.


    Donnerstag, 31. März 2016 11:40
  • Am 31.03.2016 schrieb Markus Schüssler:

    Einige Mails hängen nun immer noch in der Warteschlange. Wenn ich selbst auf "wiederholen" klicke gehen sie Raus

    Na dann warte doch einfach ab. :)

    Immer die Ungeduld.

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you with experience.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 31. März 2016 11:42
  • Moin Markus,

    um auf "DNS Problem kann es nicht sein" einzugehen.


    Moin Markus,

    die beiden Meldungen zu DnsConnectorDelivery  besagen, dass hier anhand von MX zuzustellen versucht wurde. In beiden Fällen konnte aufgelöst und eine Verbindung hergestellt werden. Der Fehlertext besagt, dass nach erfolgter Verbindung zu einem SMTP Port ein Problem eingetreten ist.

    Damit ist DNS als Fehlerquelle erstmal raus. Dein manueller Retry war erforderlich, weil nach der Änderung der Einstellungen die Queue erst nach Erreichen des Retry Timeout neu angestartet wird. Du hast das jetzt manuell gemacht, und somit sind Ergebnisse sofort sichtbar.  

    Beobachte dennoch Dein Eventlog, der Schannel 36874 Event dürfte durch Client zu SMTP Server bei Dir verursacht sein. Falls das so ist, wird das wieder auftreten. Dann musst Du den Client finden und anpassen.
    Die bisherigen Änderungen dürften diese Meldung nicht beseitigen, falls der Client anhand der neuen Ciphersuites sich nicht etwas passendes aussuchen kann.

    Viele Grüße,
    Martin

    Donnerstag, 31. März 2016 11:55
  • Hallo Martin!

    Das der SMTP schuld ist, dachte ich bisher, da in den SMTP Logs der TLS Fehler gleichzeitig mit den SCHANNEL Ereigniseinträgen aufgetaucht ist. Die Android/iOS Smartphonegeräte könnten das ja dann nur mehr sein? Die Outlook 2010/2013/2016 Clients halte ich per Updates aktuell.

    Wie könnte ich herausfinden welcher Client die SCHANNEL Fehlermeldung auslöst? Gibt es hierfür Logs? Ich Vermute mal IIS?

    Liebe Grüße
    Markus

    Donnerstag, 31. März 2016 12:05
  • Am 31.03.2016 schrieb Markus Schüssler:
    Hi,

    Das der SMTP schuld ist, dachte ich bisher, da in den SMTP Logs der TLS Fehler gleichzeitig mit den SCHANNEL Ereigniseinträgen aufgetaucht ist. Die Android/iOS Smartphonegeräte könnten das ja dann nur mehr sein? Die Outlook 2010/2013/2016 Clients halte ich per Updates aktuell.

    Wie könnte ich herausfinden welcher Client die SCHANNEL Fehlermeldung auslöst? Gibt es hierfür Logs? Ich Vermute mal IIS?

    Ich frag mal: Gibts denn eigentlich Probleme? Du wirst meiner Meinung nach immer wieder solche Fehler bekommen. und wenn jetzt deine Androids (gerade ältere Geräte) das Problem verursachen, dann wirst du das am ehesten mit den IIS Logs rausfinden. Alternativ würde ich das einfach ignorieren. Wird sich schon jemand melden, dem du dann mitteilen kannst, dass er sein Android 2.x nicht mehr synchen kann.

    Bye
    Norbert

    Donnerstag, 31. März 2016 12:09
  • Hallo Norbert!

    Daweil sieht es gut aus, bis auf die ganzen SCHANNEL Fehler in den Ereignislogs und das immernoch im SMTP diese TLS Fehler stehen bei jeder ausgehenden Verbindung. Den Mailversand werde ich bis morgen beobachten. Inzwischen versuche ich die Schannel sache in den ISS Logs aufzuspüren. Die Fehler Stören mich schon und sie einfach per Regedit deaktivieren möchte ich nicht.


    Donnerstag, 31. März 2016 12:19
  • Am 31.03.2016 schrieb Markus Schüssler:
    Hi Markus,

    Die Fehler Stören mich schon ...

    Wer sonst nix zu tun hat. ;) Sag Bescheid, was du rausgefunden hast.

    Bye
    Norbert


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 31. März 2016 12:22
  • Moin Markus,

    Moin zusammen,

    im Moment erschließt sich mir der Zusammenhang von SMTP Meldungen zu SSL und den Androids nicht. (Auch die älteren Androids sind ja hoffentlich per ActiveSync angebunden (= Web Services), was SMTP Kommunikation ausschließt.).
    Das passt also nicht als Begründung: auch der Client-Mailflow via ActiveSync läuft dann ja über den Web Service, sodass es keine SMTP Meldungen gibt. Daher ist die Aussage "wenn jetzt deine Androids (gerade ältere Geräte) das Problem verursachen, dann wirst du das am ehesten mit den IIS Logs rausfinden." mit SMTP Meldungen dieser Art zu überdenken.

    Der Verweis auf  IISLogs in diesem Kontext ist  begrenzt sinnvoll, denn Vorraussetzung für den Abruf eines URLs ist ein Kommunikationskanal. schannel Meldungen besagen aber, dass genau dieser nicht zustande gekommen ist. Wo kein  URL abgerufen wird, gibt es auch keinen Eintrag (darum ja der schannel-Eintrag). 
    Bei SMTP ist das aber anders, denn mit Exchange machst Du opportunistic TLS, fällst also ggf. auf Plain SMTP zurück (falls Dein Konnektor SSL nicht erzwingt mit requiressl --> true). Du siehst dann einen Dialog bis zum STARTTLS, danach erstmal einen Timeout, und dann einen neuen SMTP Request ohne STARTTLS (der ist 3-5 Minuten versetzt).

    Aus meiner Sicht wäre daher auch die Aussage von Norbert "Du wirst meiner Meinung nach immer wieder solche Fehler bekommen" lediglich dann akzeptabel, wenn Du sicherstellen kannst, dass das kein "interner" Client ist, also der Fehler außerhalb der Steuerungsgewalt der IT liegt. Das gilt aber nicht für ActiveSync, denn das passt nicht zum Fehlerbild.

    Aus meiner Sicht solltest Du hin und wieder (in den nächsten Tagen tageweise) prüfen, dass bei den TLS xxx ...-Meldungen von oben die IP-Adresse "nicht intern" ist. Bei internen SMTP Clients, wie Ticket-Systemen und anderen System Mailern (Backup, Hypervisor, o.ä.) solltest Du prüfen, ob man dort ebenfalls eine Anpassung vornehmen lassen kann.

    Viele Grüße,
    Martin

    Donnerstag, 31. März 2016 12:31
  • Am 31.03.2016 schrieb Gudel:

    Auch der Client-Mailflow via ActiveSync läuft dann ja über den Web Service, sodass es keine SMTP Meldungen gibt. Daher ist die Aussage "wenn jetzt deine Androids (gerade ältere Geräte) das Problem verursachen, dann wirst du das am ehesten mit den IIS Logs rausfinden." mit SMTP Meldungen dieser Art zu überdenken.

    Ich denke es geht um die SSL Fehlermeldungen im Eventlog? Und da tauchen afair auch die Fehler auf, die durch fehlerhafte https Sessions verursacht werden.

    Bye
    Norbert

    Donnerstag, 31. März 2016 13:26
  • Danke für die ausführliche Antwort.

    Ich habe zum Beispiel eine Mail in der Warteschlange hängen an die tuwien.ac.at - laut MX Einträge gibt es dort 4 Server:

    http://mxtoolbox.com/SuperTool.aspx?action=mx%3atuwien.ac.at&run=toolpage#

    1     mri0.tuwien.ac.at     128.130.2.100     
    25     mri1.tuwien.ac.at     128.130.2.56     
    30     mri2.tuwien.ac.at     128.130.2.57     
    900     mri9.tuwien.ac.at     128.130.2.119    

    Laut SMTP Send Logs versucht unser Server aber nur über 2 der angegebenen SMTP Server zu senden: mri1.tuwien.ac.at  und mri2.tuwien.ac.at

    Bei manuellen Telnetverbindungen auf Port 25 dorthin bekomm ich Timeouts. Kann man irgenwo die Timeout einstellung hochdrehen für ausgehende Mails?

    Donnerstag, 31. März 2016 13:33
  • Am 31.03.2016 schrieb Markus Schüssler:
    Hi,

    Bei manuellen Telnetverbindungen auf Port 25 dorthin bekomm ich Timeouts. Kann man irgenwo die Timeout einstellung hochdrehen für ausgehende Mails?

    Und du bist dir sicher, dass das Problem auf deiner Seite liegt? ;)


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Donnerstag, 31. März 2016 13:35
  • Hi!

    Laut den MX Tools wird dort eine hohe Verbindungswartedauer angegeben mit 6-8 Sekunden aber der Test ist dort erfolgreich. Ich alerdings komm garnicht zum Server. Da bis vor ein paar tagen es nie Probleme Gab gehe ich jedem Ast am Boden nach wo der abgebrochen sein könnte  bevor ein ganzer Baum umstürzt und ich darunter liege :)

    Donnerstag, 31. März 2016 13:38
  • Moin Markus,

    im Falle dieser 4 Server würde ich ebenfalls empfehlen, der Lösungsmethode "abwarten und Tee trinken" zu folgen. Seitens Send Connector kannst Du zwar z.B. Inaktivitätstimeouts, aber m.W. keine Verbindungstimeouts steuern (dafür gibt es in set-sendconnector keine Parametrisierung, und die Windows tcp Settings sind nicht sachbezogen).

    Das kann ich hier für diese 4 Server mit telnet nachvollziehen.

    Das Antwortverhalten der genannten 4 Server schwankt je nach Zeitpunkt. Das geht mutmaßlich nicht von Dir aus. Auch die Beobachtung "2 der Hosts von 4 MX Einträgen" dürfte daher stammen: kommt einmal eine TCP Verbindung zustande, wird dort ein Versandversuch registriert. Das führt zu dem Timeout-Fehler, den Du unter "Last Error" im Queue-Status siehst. 

    Sowas wirst Du immer mal wieder haben. Für Dein Originalproblem solltest Du aber den SSL-Fokus nicht verlieren (ich bleibe beim Wort SSL für die sichere Verbindung, auch wenn es hier um TLS Ciphers ging).

    Viele Grüße,
    Martin


    Donnerstag, 31. März 2016 14:12
  • Danke - habe die TU Wien mal angeschrieben. Ich behalte dann auch den Fokus auf die Verschlüsselte Verbindung.

    Liebe Grüße und danke für die Heutige unterstützung von allen.
    Markus

    Donnerstag, 31. März 2016 14:19
  • Hallo,

    habe gestern eine Antwort von der TU Wien erhalten.


    -------------------------------------

    Das eigentliche Problem scheint jedenfalls die Cipher-Aushandlung in der TLS-Verbindung zu sein.

    Speziell im SMTP-Bereich würde ich die Latte mit den akzeptierten Ciphers nicht zu hoch legen. Es ist zwar kryptografisch en vogue mittlerweile veraltete und schwache Ciphers, Digest-Algorithmen etc. zu vermeiden, jedoch ist das bei SMTP nicht selten problematisch, speziell dann, wenn ich automatisch ein Fallback auf Plain-Text von Sender-Seite passiert.

    SMTP schreibt an sich kein Veschlüsselung vor. Wenn hier von der Ziel-Seite zu viel abverlangt wird und gleichzeitig auf Verschlüsselung insistiert wird, bleibt die Nachricht "stecken" ...

    Ich kann nur empfehlen, auch auf Ihrer Seite die strenge der Cipherauswahl zumindest für SMTP-Verbindungen zu überdenken. Besser eine schlechte Verschlüsselung als gar keine (gilt eben nur für SMTP, freilich nicht für andere Protokolle, wie IMAP oder POP3).
    -------------------------------------

    Nun wie kann man beim Exchange 2010 nur für den SMTP ausgehend/eingehend die TLS/Chiper einstellungen setzen?

    Liebe Grüße
    Markus

    Montag, 4. April 2016 08:29
  • Das SSL/TLS Hardening ist eine Serverweite Konfiguration und kann nicht pro Protokoll unterschiedlich konfiguriert werden (ausgenommen z.B. Kerberos auf einem DC).

    Welche Cipher Suites werden jetzt bei dir unterstützt?
    Welche Rollen hast du auf dem Exchange 2010er Server installiert? Falls nur Hub, könnte man ev. ältere Ciphers noch zulassen (DES/3DES/RC4).


    Georg


    • Bearbeitet fgeo-ch Montag, 4. April 2016 12:12
    Montag, 4. April 2016 08:53
  • Am 04.04.2016 schrieb Markus Schüssler:
    Hi,

    /Ich kann nur empfehlen, auch auf Ihrer Seite die strenge der Cipherauswahl zumindest für SMTP-Verbindungen zu überdenken. Besser eine schlechte Verschlüsselung als gar keine (gilt eben nur für SMTP, freilich nicht für andere Protokolle, wie IMAP oder POP3).
    ------------------------------------- /

    Nun wie kann man beim Exchange 2010 nur für den SMTP ausgehend/eingehend die TLS/Chiper einstellungen setzen?

    Gar nicht soweit ich weiß. Abgesehen davon bin ich der Meinung, das wäre jetzt Augen zu machen und hoffen, dass ne schlechte Verschlüsselung ja "besser" wäre. ICh bilde mir also ein, eine Verschlüsselung schützt, weil sie eben da ist. ;)

    Bye
    Norbert

    Montag, 4. April 2016 09:22
  • Hi!

    Leider bleiben Nachrichten immer noch in der Warteschleife hängen. Die Benutzer bekommen die Nachricht der verzögerten zustellung und nach 2 Tagen, das sie nicht zugestellt werden konnte.

    Wenn ich die Nachrichten alle Markiere und auf "wiederholen" klicke, gehen sie aber raus? Warum nur wenn ich manuel den Knopf drücke.

    Montag, 18. April 2016 19:06
  • Am 18.04.2016 schrieb Markus Schüssler:
    Hi,

    Leider bleiben Nachrichten immer noch in der Warteschleife hängen. Die Benutzer bekommen die Nachricht der verzögerten zustellung und nach 2 Tagen, das sie nicht zugestellt werden konnte.

    Welche? Alle? An bestimmte Domains?

    Wenn ich die Nachrichten alle Markiere und auf "wiederholen" klicke, gehen sie aber raus? Warum nur wenn ich manuel den Knopf drücke.

    Arbeitsbeschaffungsmaßnahme. ;) Sicher, dass das Problem nicht vorgelagert an Firewall oder Zieldomain liegt?

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Montag, 18. April 2016 20:24
  • Hallo!

    Nicht alle Nachrichten, aber immer wieder die selben Domains. Die meisten Nachrichten gehen normal raus. Die TU Wien hat für unseren Mailserver das START-TLS rausgenommen, seit dem haben wir dorthin kein Problem mehr.

    Das grenzt zumindestens das Problem ein und hat wie vermutet was mit der Verschlüsselung zu tun.

    Lg

    Dienstag, 19. April 2016 06:04