Hallo,
inzwischen bin ich am Verzweifeln und mir fehlt der rettende Gedanken:: Exchange 2016 neueste SP´s / TLS nach Anleitung durchgeführt. HealthChecker bringt beim TSL keinen Fehler. Mails werden über den Exchange direkt verschickt: "mit der Empängerdomäne verbundener MX-Eintrag"
Trotzdem werden Mails nicht verschlüsselt versendet und der Test mit https://www.chktls.com/TestReceiver bringt: KEIN STARTTLS und TLS FAIL. Als Meldung kommt bei dem test noch: TLS is not an option on this server.
Unser Kunde hat nun massive Problem beim Versenden an bestimmte Empfänger. Hat jemand einen Lösungsansatz?
Was steht denn vor deinem Exchange. Ich kenn sowas mit Firewalls, die unbedingt irgendwas im SMTP rumpopeln wollen/müssen. Cisco ASA oder auch Watchguard fallen mir da sofort ein. :)
Hi Norbert, danke für die Frage: da steht eine Watchguard davor
Dann schalte die ganzen SMTP Proxy Funktionen ab.
Sorry, Osternstress.
Problem leider immer noch nicht gelöst. War mit einem Supportmitarbeiter von Watchguard (WG) drauf und dieser konnte keinen Fehler an der WG feststellen.
Dieser hat uns dann noch folgende Zusammenfassung geschrieben:
- We have reviewed the proposed rule and it is in place and correctly craeted
- You ran a test and it did not work
- We checked the firebox's traffic monitor and we could not see traffic for either port 25 or 465 while making the test
- In fact, from the site we could not see any other traffic at all other than port 443
- We checked with a packet capture listening to the external interface, and we cant's see traffic for either port 25 or 465
D.h. der Test https://www.chktls.com/TestReceiver kommt gar nicht an?
Noch eine Idee?
Danke für die Unterstützung
Hast du geoblocking aktiv? Unabhängig davon, schau doch einfach mal in den Header empfangener e-Mails, da sollte ja theoretisch drin stehen, ob sie per tls ankamen. Alternativ steht das auch im logfile des receive connectors.
alternativ nimm dir ein beliebiges Tool, was tls smtp kann und probier’s erstmal selbst. Ich tippe immer noch auf die Firewall.
2 Supportmitarbeiter von WG haben sich diese angesehen und verschiedene Tests gefahren bzw. SMTP-Proxy abgeschaltet. Eigentlich kann nur noch der Exchangeserver die Ursache sein
Hast du in die Header und die Logfiles geschaut? Hast du mal ein Tool genommen, was direkt an den Exchange geht? Kann ja nicht so schwer sein, das Problem zu orten. Hast du ein Zertifikat auf dem Exchange an SMTP gebunden?
Ich verstehe irgendwie die (IT)-Welt nicht mehr: ThirdPart-Zertifikat ist an SMTP gebunden. Habe nun mal eine Mail an CheckTSL.com geschickt. Nun kam zurück: Your email was sent securely using TLS.
Deshalb verstehe ich nicht warum es die ursprüngliche Meldung mit chktsl.com kam.
Habe nun mal eine Mail an CheckTSL.com geschickt. Nun kam zurück: Your email was sent securely using TLS.
Das wäre aber Versand. Ich dachte du wolltest den Empfang testen?
Nein, der Kunde wurde, nachdem IONOS seine Einstellungen geändert hatte, auf Versand direkt über die MX-Einstellungen umgestellt. Dabei hatte er große Probleme bei Versand an t-online / web.de etc. Dies konnte ich beseitigen. Die Forderung von T-Online únd anderen war, über TSL 1.2 zu verschicken. Deshalb kam ich auf den Test bei checktsl.com. Wie ich am Anfang schrieb hatte der Kunde massive Probleme beim Versenden von emails an verschiedene Empfänger.
Der Check über https://www.chktls.com/TestReceiver bringt immer noch Fehler, aber der Versand läuft mit TSL 1.2
Vielen Dank für Deine Unterstützung !!!
Dein Link funktioniert nicht. Meinst du evtl.:
https://www.checktls.com/TestReceiver
falls ja, das ist ein Test für den Empfang. Kein Wunder, dass ich von Empfang ausging. ;)
ohh sorry, ja, Dein Link ist richtig und es wird bei dem Kunden leider immer noch TSL Fail angezeigt, wie oben beschrieben.
DANKE
Ok, der Test ist aber wie schon geschrieben der für den Empfang. Also hast du sowohl für senden als auch empfangen das Problem. Üblicherweise würde ich sagen, dass vergessen wurde das Zertifikat mittels enable-exchangecertificate an den smtp Service zu binden und/oder der helo String in sende- und empfangsconnctor stimmt nicht. An deiner Stelle würde ich erstmal klären, ob es intern (ohne Beteiligung der Firewall) ebenfalls zu Fehlern kommt. Das kannst du bspw. Mit Thunderbird zumindest für den „Empfang an deinem Server“ ja schnell testen indem du mal auf Port 587 per smtp tls was zustellst. Das sieht man ja dann sowohl in der empfangenen Mail (Header) als auch im logfile des connectors.
hast du evtl. An die connectoren manuell ein Zertifikat gebunden, welches jetzt nicht mehr vorhanden oder abgelaufen ist?
Hallo,
nach einer Woche intensiven Tests / Analyse / Config etc. mit mehreren Mitarbeitern (auch aus Soanien direkt von Watchguard) sind wir etwas weiter. Problem ist aber leider noch nicht gelöst.
Es stellte sich nun so heraus dass dies ein TLS - Problem des Exchange sein muss! Wie ein Techniker von gestern heraus fand, kann die Watchguard jedes beliebige Zertifikat herausschicken wenn intern (also vom Exchange) TLS ankommt. Dabei spielt es keine Rolle ob dass interne Zertifikat gültig ist oder nicht. Hauptsache TLS funktioniert und geht an die WG.
Dies ist bei dem Kunden anscheinend nicht so. D.h., obwohl ein wildcard-Zertufikat installiert (Powershell) und eingebunden ist und auch IISCrypto sagt dass 1.2 und 1.1 (Exchange 2016) eingerichtet ist, muss es ein Problem mit dem TLS geben...
Habe inzwischen auch Zertifikat nochmals installiert.
Nochmal, ich würde an deiner Stelle erstmal prüfen, ob es intern OHNE die Watchguard das gleiche Problem gibt. Alternativ schau halt endlich mal ins entsprechende Logfile, da sollte jeweils drin stehen ob ne StartTLS session zustande kommt. Kann ja sein, dass es nur sehr wenige betrifft.
IISCrypto sagt dass 1.2 und 1.1 (Exchange 2016) eingerichtet ist, muss es ein Problem mit dem TLS geben...
IISCrypto sagt, was es ggf. in der Registry vorfindet. Wenn du kein Zertifikat am Exchange hast (oder ein Problem damit), dann ist IISCrypto echt das unwichtigste an der ganzen Geschichte. ;)