Exchange 2003 Mails von GMX kommen nicht an (TLS)

[sconsulting 0]

Ein Schuss ins Blaue: hat der Exchange 2010 auch ein Zertifikat von Thawte? Falls nicht, kann es evtl. sein dass GMX aus welchen Gründen auch immer das Thawte Zertifikat nicht akzeptiert? Wobei dann wären sehr wahrscheinlich viel mehr Exchange Installationen betroffen.  Wir verwenden ein Zertifikat von COMODO welches auch für OWA im Einsatz ist und dort keine Probleme verursacht.

[CoolBlue 10]

Hab ich auch schon geprüft.. beide haben ein SSL123 Zertifikat von Thawte mit der gleichen CA Chain, die laut gnu-tls auch immer mit geschickt wird, was ich ebenfalls verglichen habe. :-(

[sconsulting 0]

Danke für die Auskunft, das wollte ich ebenfalls gerade prüfen. Ich habe vor ein paar Stunden ein Mail an gmx@gmxnet.de mit Verweis auf diesen Thread geschickt, ich fürchte jedoch dass das keine brauchbare Antwort zurück kommt.

[NeMiX 76]

Habt Ihr es mal hier probiert:

http://postmaster.gmx.de/de/kontakt/

 

Dort wurde mir schon 2x kompetent bei einem Blacklist Problem geholfen.

[CoolBlue 10]

Ja dort habe ich meinen Fall bereits geschildert und warte noch auf Antwort.

 

 

Hallo,

mein Kunde, den ich betreue kann keine E-Mails von GMX empfangen. Eingesetzt wird ein Exchange 2003 Server mit Thawte SSL123 Zertifikat auf SMTP Ebene.

Laut Log kommt die Verbindung durch GMX an, jedoch wird im Nachrichtenprotokoll keine ankommende E-Mail verzeichnet.

2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +mout.gmx.net 250 0 345 17 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 0 8 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 STARTTLS - - 220 0 29 8 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 EHLO - +mout.gmx.net 250 0 355 17 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 MAIL - +FROM:<[hidden]@gmx.de> 250 0 73 37 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 RCPT - +TO:<[hidden]@beba-energie.de> 250 0 0 44 0 SMTP - - - -
2013-08-15 10:30:00 212.227.17.20 mout.gmx.net SMTPSVC1 EXBEBA 192.168.0.12 0 QUIT - mout.gmx.net 240 156 0 44 0 SMTP - - - -

Schalte ich STARTTLS ab (Entfernung des Zertifikats) dann erhält der Kunde GMX E-Mail unverschlüsselt problemlos. Leider ist mir nicht möglich eine verschlüsselte Verbindung sinnvoll zu tracen. Versuche mit anderen E-Mail Servern eine STARTTLS Verbindung aufzubauen und eine E-Mail zu versenden haben bisher immer geklappt. Sowohl manuell mit OpenSSL, als auch über einen befreundeten Exchange Server.

Server1 ~ # openssl s_client -connect mail.beba-energie.de:25 -crlf -starttls smtp
CONNECTED(00000003)
depth=1 C = US, O = "Thawte, Inc.", OU = Domain Validated SSL, CN = Thawte DV SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/OU=Domain Validated/CN=mail.beba-energie.de
   i:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
 1 s:/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=© 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE8DCCA9igAwIBAgIQMtyjhBIvr85TMiSBVnNZAzANBgkqhkiG9w0BAQUFADBe
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMVGhhd3RlLCBJbmMuMR0wGwYDVQQLExRE
b21haW4gVmFsaWRhdGVkIFNTTDEZMBcGA1UEAxMQVGhhd3RlIERWIFNTTCBDQTAe
Fw0xMzAxMjIwMDAwMDBaFw0xNjAyMjEyMzU5NTlaMIGbMTswOQYDVQQLEzJHbyB0
byBodHRwczovL3d3dy50aGF3dGUuY29tL3JlcG9zaXRvcnkvaW5kZXguaHRtbDEi
MCAGA1UECxMZVGhhd3RlIFNTTDEyMyBjZXJ0aWZpY2F0ZTEZMBcGA1UECxMQRG9t
YWluIFZhbGlkYXRlZDEdMBsGA1UEAxQUbWFpbC5iZWJhLWVuZXJnaWUuZGUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKTIovoFOsj+k313/nsQ9sVT8b
hkY/bW5JqIgYhKcrpCBfLHLurFoDuV7ViO1VRAPGm5VfxI+fjtiMuc1WsI4bSKiJ
QlgQ2bfp0MgPgyR5eQbDSneZ6+rw/6ltqX60TrguM+iTYNkl3M/6h7SuKtRAe7J0
Iq5nJjNCWkGiKmgAdDlSQlQKmKBf++V2ROEYYOASDky3Ys42nUUBXhf+aWTSAzMc
g+YoVhYuJoZqkPshh2VJC1JEf/GscCYXmq4vSGx+yRu95Q7PM3c+pfcf7Bf9JrAN
LStwTYxBuOkddm2IotsuZTtWSBmmXw/nkxsi0roBjgdhhv2f1hVl/a/Kdh5tAgMB
AAGjggFqMIIBZjAfBgNVHREEGDAWghRtYWlsLmJlYmEtZW5lcmdpZS5kZTAJBgNV
HRMEAjAAMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9zdnItZHYtY3JsLnRoYXd0
ZS5jb20vVGhhd3RlRFYuY3JsMEEGA1UdIAQ6MDgwNgYKYIZIAYb4RQEHNjAoMCYG
CCsGAQUFBwIBFhpodHRwczovL3d3dy50aGF3dGUuY29tL2NwczAfBgNVHSMEGDAW
gBSrRORd7IPH2cCFn/fhxpeQsIw/mDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMGkGCCsGAQUFBwEBBF0wWzAiBggrBgEFBQcw
AYYWaHR0cDovL29jc3AudGhhd3RlLmNvbTA1BggrBgEFBQcwAoYpaHR0cDovL3N2
ci1kdi1haWEudGhhd3RlLmNvbS9UaGF3dGVEVi5jZXIwDQYJKoZIhvcNAQEFBQAD
ggEBAGIg8ieThCKU9izctSNK7TbhlOvlqMD0x4YDfSyICRDvmMaf9CjIT7kufGCi
FjMQOYLeHQIAIZLXVo2ijLeMJ0VSvcKNavtj4lOPZjMXuOb/jS0EVdM2hI1DOlOO
SzSzAUpRW3H+g6J3RYTSCEw7zl5O+d0tzai3knmRQh+9BhV2heMZw/T6RbtGjSRl
DXMyhKmbOidoydrFOxuYLB8HqEm7C63xRDRCU8M/W4BDfn4abYTSUJdX7hFWdeub
aPNzDR17I9IP6BYF/h+5Vo0oaELBrmNFPXzTuNNikHRYiIQifmFVNF8viuOCrmrk
c4wSXyb8Z+bcvFHcHgBcp3NLFXk=
-----END CERTIFICATE-----
subject=/OU=Go to https://www.thawte.com/repository/index.html/OU=Thawte SSL123 certificate/OU=Domain Validated/CN=mail.beba-energie.de
issuer=/C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3081 bytes and written 556 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: A9100000ABE7BE8EB6963EA377D1E8896B8318734B5B30BB704E90298F3E5201
    Session-ID-ctx:
    Master-Key: BC21D41633B1942DB6D07FCBFE7264F2731CD064465BCBE8EE5DA33CBF921A0F7D0EB36AF8C621C72F7196B7672F8A26
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1376568122
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
250 OK
mail from: [hidden]@itlange.de
250 2.1.0 [hidden]@itlange.de....Sender OK
rcpt to: [hidden]@beba-energie.de
250 2.1.5 [hidden]@beba-energie.de
data
354 Start mail input; end with <CRLF>.<CRLF>
test
.
250 2.6.0 <EXBEBAbbbJXncnm5c4G0000101e@mail.beba-energie.de> Queued mail for delivery
quit
221 2.0.0 mail.beba-energie.de Service closing transmission channel
read:errno=0

Haben Sie die Möglichkeit die Verbindung zu prüfen. Gern können Sie Test E-Mails an [hidden]@beba-energie.de senden. Der Kollege wird den Empfang jeder Mail kurz bestätigen mit einer Rückmail.

Server: mail.beba-energie.de / 212.185.189.211
Port: 25

Vor dem Exchange ist keine Firewall mit Spamfilter Eigenschaften.. Die Verbindung wird direkt via NAT durchgereicht.

bearbeitet 19. August 2013 von CoolBlue

[sconsulting 0]

Habt Ihr es mal hier probiert:

http://postmaster.gmx.de/de/kontakt/

 

Dort wurde mir schon 2x kompetent bei einem Blacklist Problem geholfen.

 

Danke für den Tipp, habe soeben GMX über das Postmaster-Formular kontaktiert.

[viragomann 10]

Also mit meiner Logik bin ich hier längst am Ende. Die Kommunikation zwischen GMX und Exchange 2010 funktioniert, aber nur über TLS 1.0. Auch trotz AES256 und SHA1 kommt keine Übertragung auf den Exchange 2003 zustande.
Ich sehe dann nicht, wo hier der Unterschied zwichen den Exchange Versionen liegt, der zum Problem führt.
 
@CoolBlue:
Mit den Updates bist du ja schon ein ganzes Stück weiter.
Aber der Sache mit dem Zertifikat solltest du auf den Grund gehen, denn bei mir meldet gnutls-cli (V3.0) dieses Problem nicht und ich verwende ein gleiches Zertifikat. Vielleicht hast du das TLS schon soweit auf Vordermann, aber es scheitert nun am Zertifikat.

 

Hier sieht das so aus:

- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `OU=Go to https://www.thawte.com/repository/index.html,OU=Thawte SSL123 certificate,OU=Domain Validated,CN=firma.at', issuer `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2012-07-11 00:00:00 UTC', expires `2015-07-11 23:59:59 UTC', SHA-1 fingerprint `3d237c273e9a796f634e9628bb17adf1c3b691e5'
- Certificate[1] info:
 - subject `C=US,O=Thawte\, Inc.,OU=Domain Validated SSL,CN=Thawte DV SSL CA', issuer `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=© 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', RSA key 2048 bits, signed using RSA-SHA1, activated `2010-02-18 00:00:00 UTC', expires `2020-02-17 23:59:59 UTC', SHA-1 fingerprint `3ca958f3e7d6837e1c1acf8b0f6a2e6d487d6762'
- Certificate[2] info:
 - subject `C=US,O=thawte\, Inc.,OU=Certification Services Division,OU=© 2006 thawte\, Inc. - For authorized use only,CN=thawte Primary Root CA', issuer `C=ZA,ST=Western Cape,L=Cape Town,O=Thawte Consulting cc,OU=Certification Services Division,CN=Thawte Premium Server CA,EMAIL=premium-server@thawte.com', RSA key 2048 bits, signed using RSA-SHA1, activated `2006-11-17 00:00:00 UTC', expires `2020-12-30 23:59:59 UTC', SHA-1 fingerprint `1fa490d1d4957942cd23545f6e823d0000796ea2'
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: ARCFOUR-128
- MAC: MD5
- Compression: NULL
- Handshake was completed
 

Hier gibt es 3 Zertifikate in der Kette. Bei dir fehlt offenbar die ROOT-CA "thawte Primary Root CA".

Überprüfe deine Installtation mal hiermit:

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO9555&actp=LIST&viewlocale=en_US

[zahni 554]

Das Root-Zertifikat mit zu übertragen ist eigentlich sinnfrei. Die Gegenstelle muss die CA's kennen und vertrauen.

[sconsulting 0]

Ich konnte inzwischen während unserem Wartungsfenster http://support.microsoft.com/kb/948963  einspielen und den Server neustarten.  Sicherheitshalber hab ich die Intermediate und Root Zertifikate von Comodo neu installiert, leider führte dies auch bei uns zu keinem Erfolg.

[CoolBlue 10]

Also der Test oben schlägt bei mir mit dem dritten Zertifikat fehl. Allerdings bekomme ich IIS6.0 auch nicht dazu das dritte Zertifikat auszuliefern. Lokal wenn ich das SSL123 öffne zeigt er mir den Chain mit dem DV SSL und der Root CA an und sagt auhc ist gültig. Habe ebenfalls mal alle Thawte CAs gelöscht und als Paket von deren Website neu heruntergeladen und installiert. Das hilft nix.

 

Der Exchange 2010 STMP Server liefert aber auch immer nur 2 ab. Reicht ja eigentlich auch, wenn am Client die Root CA bekannt ist.

Also mein Exchange 2003 ist nun im ars***! Jede Verbindung nach einem STARTTLS wird nach MAIL FROM disconnected.. egal wer mir was sendet....

 

Sprich ich kann jetzt gar keine TLS Mails mehr empfangen.. hmpf.

[viragomann 10]

Laut meinem Anbieter muss die gesamte Zertifikatskette am Server korrekt installiert sein, damit es keine Probleme gibt. Jedoch überprüfen dies die Webbrowser üblicherweise nicht.

 

Auf einem Win 2k3 ist ein altes Primary Root-CA standardmäßig installiert. Das hat sich aber einmal geändert und muss erst deinstalliert oder deaktiviert werden. Siehe dazu hier Step 5:

 

https://search.thawte.com/support/ssl-digital-certificates/index?page=content&actp=CROSSLINK&id=SO15447

 

Wenn die Kette passt, werden alle 3 Stufen angezeigt.

[Wolf1961 0]

Hallo,

 

nachdem ich heute auf meinem 2003 Exchange Server (SBS 2003) darauf gestossen bin, dass Mails von gmx und web.de seit ca. dem 8.08.13 nicht mehr ankommen, habe ich diesen Thread hier gefunden und heute den Tag über verfolgt.

 

Zu Schluss habe ich heute Abend nur vom virtuellen Standardserver für Smtp das Zertifikat entfernt, jetzt empfängt mein Exchangeserver die Mails wieder, da kein Versuch einer Verschlüsselung erfolgt. Ist zwar auch nicht super gut, aber bis eine Lösung/Änderung von gmx/web.de erfolgt oder von MS veröffentlicht wird, kommen die Mails erst einmal wieder an.

 

Auf den anderen virtuellen Servern ist das Zertifikat (was ein übrigens ein Eigenzertifikat ist) weiter vorhanden und die Verschlüsselung für POP3 Clients oder HTTP etc. funktioniert weiterhin.

[CoolBlue 10]

Solange mich der Kunde nicht zu dieser Lösung drängt, werde ich die Verschlüsselung nicht deaktivieren. Man muss es ja nicht drauf ankommen lassen.. viele MTAs nutzen die TLS Funktion

 

 

Status Update:

 

 

 

1) Der Patch KB948963 macht meinen Server kaputt. Die AES algorithmen bringen die TLS Verbindung zum absturz. Weder checktls.com noch gnutls oder openssl können via SSL kommunizieren. Beim ersten Befehle nach STARTTLS bricht die Verbindung ab. Schließe ich AES aus, so dass er einen anderen Algho nimmt, gehts wieder einwandfrei. Also hab ich den  KB wieder runtergeworfen.. nun gehen die Verbindungen wieder.

 

2) Mein Intermediate Zertifikat war nicht richtig installiert + der Tipp mit dem deaktivieren der alten Root CA hat den gewünschten Zertifikatschain Erfolg gebracht. Danke

 

3) GMX und WEB mögen Exchange 2003 immer noch nicht.

 

Also alles wieder beim alten. Ich gebe jetzt auf und stelle den Kunden vor die Wahl:

a) Kostenpflichten Microsoft Support kontaktieren. (Ich habe wenig Hoffnung das das ernsthaft was bringt)

B) TLS abschalten mit der Konsequenz das gar nichts mehr verschlüsselt wird

c) Update auf Exchange 2010/2013 (leider ist dazu auch eine neue Hardware Infrastruktur notwendig)

d) Abwarten und Tee trinken. Wenn sich genug beschweren, reagiert GMX vielleicht. Noch ist Exchange 2003 offiziell supportet bei M$, also darf es nicht sein das große globale Unternehmen die Software ausschließen.

 

Gute Nacht.

bearbeitet 20. August 2013 von CoolBlue

[sconsulting 0]

KB948963 macht auch bei uns Probleme: seit der Installation antwortet Exchange nicht mehr auf IMAP über SSL Anfragen.  Werde den Patch wieder deinstallieren.

[CoolBlue 10]

Vermutlich das gleiche AES Algho Problem. Da hat MS wohl einen halb fertigen Patch rausgebracht ohne QS.