Server sendet mit TLSv1.2 aber Empfänger empfängt mit SSL3
Hallo,
ich habe bei uns einen Exchange 2019 Server auf einem Windows Server 2019 aufgesetzt und dieser funktioniert auch ordentlich. Ich habe aber mittlerweile von zwei Firmen Feedback bekommen dass unsere E-Mails bei denen mit SSL3 ankommen und habe auch Auszüge aus deren Firewall bekommen:
Ich habe auf https://de.ssl-tools.net/mailservers einen Test durchgeführt, und da steht dass unsere Mails mit TLS ankommen: TLSv1.2 / Ecdhe-RSA-AES256-GCM-SHA384
hat da jemand eine Idee ob das an uns oder dem Empfänger liegt?
ich habe bei uns einen Exchange 2019 Server auf einem Windows Server 2019 aufgesetzt und dieser funktioniert auch ordentlich. Ich habe aber mittlerweile von zwei Firmen Feedback bekommen dass unsere E-Mails bei denen mit SSL3 ankommen und habe auch Auszüge aus deren Firewall bekommen:
2020:11:25-07:28:16 vpn exim-in[5717]: 2020-11-25 07:28:16 SMTP connection from [xxx]:36434 (TCP/IP connection count = 1)
2020:11:25-07:28:16 vpn exim-in[29164]: 2020-11-25 07:28:16 TLS error on connection from mail1.xxx.de [xxx]:36434 (SSL_accept): error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher
2020:11:25-07:28:16 vpn exim-in[29164]: 2020-11-25 07:28:16 TLS client disconnected cleanly (rejected our certificate?)
2020:11:25-07:28:16 vpn exim-in[29164]: 2020-11-25 07:28:16 SMTP connection from mail1.xxx.de [xxx]:36434 closed by EOF
Ich habe auf https://de.ssl-tools.net/mailservers einen Test durchgeführt, und da steht dass unsere Mails mit TLS ankommen: TLSv1.2 / Ecdhe-RSA-AES256-GCM-SHA384
hat da jemand eine Idee ob das an uns oder dem Empfänger liegt?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 625633
Url: https://administrator.de/forum/server-sendet-mit-tlsv1-2-aber-empfaenger-empfaengt-mit-ssl3-625633.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
7 Kommentare
Neuester Kommentar
Beide Seiten müssen sich auf ein Protokoll einigen. Finden sie beide keine auf beiden Seiten vorhandene Cipher können sie nicht verschlüsselt miteinander kommunizieren. Wenn du also auf deinem Server bspw. nur TLS1.2 und SSL3 aktiviert hast und sonst keine andere Cipher und die Gegenseite spricht bspw. nur TLS1 und TLS1.1 aber kein TLS1.2 inkl der passenden Cipher ist klar das sich hier auf keine gemeinsame Cipher geeinigt werden kann. Die gängigsten Protokolle sollte man für einen Mailserver immer aktiviert halten sonst kommt es zu solchen Fallen wie du sie gerade siehst wenn der Empfangende Mailserver nur explicit TLS statt opportunistic TLS aktiviert hat.
Das war ja nur ein Beispiel um zu verdeutlichen was da im Hintergrund abläuft.
Hast du zufällig eins der diversen SSL Hardening Tools auf dem Server angewendet also ihn schon diesbezüglich modifiziert oder ist dieser in dieser Hinsicht jungfräulich?
habe ich gar kein SSL3.0 aktiviert
Schalte dich doch einfach mal mit Wireshark dazwischen dann siehst du was tatsächlich Sache ist.denke ich
Schwarz auf Weiß nachprüfen ist besser als nur "denken" das es so ist .Hast du zufällig eins der diversen SSL Hardening Tools auf dem Server angewendet also ihn schon diesbezüglich modifiziert oder ist dieser in dieser Hinsicht jungfräulich?
Dann hast du deinen Fehler also selbst produziert ... dann wundert mich das ehrlich gesagt nicht.
naja, das ist ein Tools was in der IT-Welt großen Anklang findet und viel verwendet wird
Nur leider auch oft fehlerhafte Configs produziert.das Zertifikat passt auch nicht zum mx record
Naja , wenn das schon nicht stimmt dann bringt das alles nichts ... das ist Grundvorraussetzung das der Common-Name oder die SANs im Cert passen.Pointer (RR) auch richtig gesetzt?