Vor ein paar Tagen hat Google Mail plötzlich beschlossen, keine Mails mehr an meinen Mailserver zu senden. Ich verwende Postfix und Dovecot mit einem kostenpflichtigen SSL-Zertifikat, das auf Debian 7 läuft, wobei alles aktualisiert ist.
Meine mail.logzeigt den folgenden Fehler:
Dec 19 11:09:11 server postfix/smtpd[19878]: initializing the server-side TLS engine
Dec 19 11:09:11 server postfix/tlsmgr[19880]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 19 11:09:11 server postfix/tlsmgr[19880]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 19 11:09:11 server postfix/smtpd[19878]: connect from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: setting up TLS connection from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: mail-wi0-x230.google.com[2a00:1450:400c:c05::230]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STR ENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept:before/accept initialization
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept:error in unknown state
Dec 19 11:09:11 server postfix/smtpd[19878]: SSL_accept error from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]: -1
Dec 19 11:09:11 server postfix/smtpd[19878]: warning: TLS library problem: 19878:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Dec 19 11:09:11 server postfix/smtpd[19878]: lost connection after STARTTLS from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Dec 19 11:09:11 server postfix/smtpd[19878]: disconnect from mail-wi0-x230.google.com[2a00:1450:400c:c05::230]
Auszüge aus meinem Postfix main.cf:
smtpd_use_tls=yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_CAfile = path to CA Bundle
smtpd_tls_cert_file= path to cert (pem)
smtpd_tls_key_file=path to key (pem)
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_exclude_ciphers = aNULL, DES, 3DES, MD5, DES+MD5, RC4, RC4-MD5
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_received_header = yes
tls_preempt_cipherlist = yes
tls_medium_cipherlist = AES256+EECDH:AES256+EDH
Ich weiß nicht, wo das Problem liegt, weil ich regelmäßig Mails von anderen erhalte. Es gibt keine Fehler beim Verbinden mit Port 25 über Telnet oder Port 465 über OpenSSL
Zusatz: Ich habe diese E-Mail als Antwort von Google erhalten:
Delivery to the following recipient failed permanently:
<removed>
Technical details of permanent failure:
TLS Negotiation failed
----- Original message -----
[...]
Vielleicht ist es ein Problem mit meiner Chiffrierliste?
Antwort auf die Frage von masegaloeh:
openssl s_client -connect localhost:25 -starttls smtp
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
[...]
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
---
No client certificate CA names sent
---
SSL handshake has read 6267 bytes and written 477 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 3600 (seconds)
TLS session ticket: [...]
Compression: 1 (zlib compression)
Start Time: 1418986680
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
250 DSN
Update 1:
Mein SSL-Zertifikat wurde erneut ausgegeben. Erzeugte alles wie folgt:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256
Ich habe dann eine neue Datei erstellt, bestehend aus crtund key, danach habe ich das CA-Bundle erstellt:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt
Fügte alles zu meiner Dovecot- und Postfix-Konfiguration hinzu und startete beide Dienste neu.
Google noch nicht Mails zo mein Server in resultierenden schickenTLS Negotiation failed
Ich habe einen anderen Mail-Provider (web.de) ausprobiert und die Mail wird gesendet.
web.de log:
Dec 19 17:33:15 server postfix/smtpd[14105]: connect from mout.web.de[212.227.15.3]
Dec 19 17:33:15 server postfix/smtpd[14105]: setting up TLS connection from mout.web.de[212.227.15.3]
Dec 19 17:33:15 server postfix/smtpd[14105]: mout.web.de[212.227.15.3]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH"
Dec 19 17:33:15 server postfix/smtpd[14105]: mout.web.de[212.227.15.3]: save session EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647 to smtpd cache
Dec 19 17:33:15 server postfix/tlsmgr[14107]: put smtpd session id=EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647 [data 127 bytes]
Dec 19 17:33:15 server postfix/tlsmgr[14107]: write smtpd TLS cache entry EA1635ED786AFC2D9C7AB43EF43620A1D9092DC640FDE21C01E7BA25981D2445&s=smtp&l=268439647: time=1419006795 [data 127 bytes]
Dec 19 17:33:15 server postfix/smtpd[14105]: Anonymous TLS connection established from mout.web.de[212.227.15.3]: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Soultion:
Nach dem Aktivieren TLSv1und TLSv1.1im smtpd_(mandatory)_protocolsAbschnitt funktioniert alles gut. Danke masegaloeh !
Dec 20 11:44:46 server postfix/smtpd[31966]: initializing the server-side TLS engine
Dec 20 11:44:46 server postfix/tlsmgr[31968]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 20 11:44:46 server postfix/tlsmgr[31968]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 20 11:44:46 server postfix/smtpd[31966]: connect from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]
Dec 20 11:44:46 server postfix/smtpd[31966]: setting up TLS connection from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]
Dec 20 11:44:46 server postfix/smtpd[31966]: mail-wi0-x235.google.com[2a00:1450:400c:c05::235]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH"
Dec 20 11:44:46 server postfix/smtpd[31966]: Anonymous TLS connection established from mail-wi0-x235.google.com[2a00:1450:400c:c05::235]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
openssl s_client -connect localhost:25 -starttls smtp?Antworten:
TLDR : Ihre TLS-Protokolle sind zu streng, da Sie nur TLSv1.2-Verbindungen zulassen.
Und GMAIL sendet E-Mails mit dem TLSv1-Protokoll an Ihren Server . Aus diesem Grund schlägt die TLS-Aushandlung fehl.
Die naheliegende Lösung besteht darin, die Protokolle TLSv1 und TLSv1.1 zuzulassen und weiterhin die (unsicheren) SSLv2- und SSLv3-Protokolle zu deaktivieren.
Erläuterung
Ich kann Ihren Fall bestätigen, wenn ich keine E-Mails von GMAIL und FACEBOOK über STARTTLS erhalten habe .
Warum nur GMAIL, der keine E-Mails an meinen Server sendet
Dies ist das Mailing-Snippet, wenn GMAIL eine E-Mail sendet
Und dies ist das Mailing-Snippet, wenn FACEBOOK eine E-Mail sendet
Einige Analysen
Das erklärt, warum nur GMAIL keine E-Mails an Ihren Server senden kann. GMAIL verfügt nicht über einen Mechanismus zum Zurückgreifen, wenn die TLS-Aushandlung fehlschlägt . Andere Mail-Server verwenden möglicherweise einen Fallback-Mechanismus, um sicherzustellen, dass die E-Mail-Zustellung erfolgreich ist.
Warum TLS-Aushandlungsfehler auftritt
Ich finde interessante Zeilen von web.de Maillog
Und finden Sie heraus, dass Sie diese Konfiguration in angeben
main.cfDas bedeutet, dass Ihr Server nur TLS-Verbindungen akzeptiert , wenn TLSv1.2 verwendet wird. Anders als TLSv1.2 wird Ihr Server einen TLS-Aushandlungsfehler beklagen.
Wenn ich zu ändere
smtpd_tls_(mandatory_)protocols,!SSLv2,!SSLv3,!TLSv1tritt der Fehler weiterhin auf. Dies bedeutet, dass GMAIL und FACEBOOK versuchen, Ihren Mailserver mit anderen Protokollen als TLSv1.1 und TLSv1.2 zu kontaktieren.Wenn ich zu ändere
smtpd_tls_(mandatory_)protocols,!SSLv2,!SSLv3wird die TLS-Aushandlung erfolgreich sein. Es wird bestätigt, dass GMAIL und FACEBOOK Ihren Server mit dem TLSv1-Protokoll kontaktierenAndere Leute im FreeBSD-Forum bestätigen dieses Verhalten ebenfalls.
Lösung
Die naheliegende Lösung ist, TLSv1 und TLSv1.1 in Ihrem Postfix zu aktivieren. Dadurch wird sichergestellt, dass einige Mailserver, die nicht über einen Fallback-Mechanismus verfügen, wie z. B. GMAIL, weiterhin mit Ihrem Server kommunizieren können.
Ich kenne Ihren Grund nicht, die TLSv1- und TLSv1.1-Unterstützung zu deaktivieren und nur das TLSv1.2-Protokoll zu belassen. Wenn es sich um einen Webserver handelt und Ihr Benutzer nur einen modernen Browser verwendet, können Sie TLSv1 auf Ihrem Server deaktivieren. Dies ist akzeptabel, da nur ältere Browser das Protokoll TLSv1 nicht unterstützen .
quelle
Ein mögliches Problem, das ich sehen kann, ist die offensichtliche Verwendung eines selbstsignierten Zertifikats, wie von OpenSSL gemeldet:
Wenn Sie ein kostenpflichtiges SSL-Zertifikat verwenden, sollten Sie kein selbstsigniertes Zertifikat verwenden.
Ich würde überprüfen, ob Ihre PEM-Datei Ihr bezahltes Zertifikat enthält, und sicherstellen, dass sie die vollständige Zertifikatskette enthält.
quelle
code: 19 (self signed certificate)code 19Nachricht erhalten, wenn Ihre gesamte Kette bedient wird. Ich verwende ein Zertifikat von StartSSL, das am Anfang des Befehls denselben Fehler ausgibt, aber da ich die vollständige Kette (einschließlich der Stammzertifizierungsstelle) in dersmtpd_tls_cert_filePEM-Datei bereitstelle , verfügt der Client über alle zum Überprüfen der vollständigen Kette erforderlichen Zertifikate .