Impossible de recevoir des e-mails de Gmail

15

Il y a quelques jours, Gmail a soudainement décidé d'arrêter d'envoyer des e-mails à mon serveur de messagerie. J'utilise Postfix et Dovecot avec un certificat SSL payant fonctionnant sur Debian 7 avec tout mis à jour.

Mes mail.logspectacles l'erreur suivante:

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]

extraits de mon suffixe 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

Je ne sais pas où est le problème, car je reçois régulièrement des mails des autres. Il n'y a aucune erreur de connexion au port 25 via telnet ou au port 465 via openssl

Addition: J'ai reçu ce mail en retour de Google:

Delivery to the following recipient failed permanently:

     <removed>

Technical details of permanent failure:
TLS Negotiation failed

----- Original message -----
[...]

C'est peut-être un problème avec ma liste de chiffrement?

Réponse à la question de 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

Mise à jour 1: réédition de mon certificat SSL. Tout généré comme suit:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256

J'ai ensuite créé un nouveau fichier comprenant le crtet le key, après cela j'ai créé le bundle CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt

Ajout de tout à ma configuration pigeonnier et postfix et redémarrage des deux services.
Google ne parvient toujours pas à envoyer des e-mails sur mon serveur, ce qui entraîneTLS Negotiation failed

J'ai essayé un autre fournisseur de messagerie (web.de) et le courrier est envoyé.
Journal web.de:

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:
Après l'activation TLSv1et TLSv1.1dans la smtpd_(mandatory)_protocolssection, tout fonctionne bien. Merci 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)
postfix  dovecot 
— Octfx
source
Quelle est la sortie de la commande openssl s_client -connect localhost:25 -starttls smtp?
— masegaloeh
Ajouté à ma question @masegaloeh
— Octfx
Cela m'affecte également avec exim; grande question.
— Boyd Stephen Smith Jr.,
Cela vient de commencer à m'affecter, je n'avais pas les lignes tls_protocol dans mon main.cf, et la valeur par défaut documentée est de désactiver uniquement SSL2 / 3. Cependant, la réponse ci-dessous a résolu mon problème.
— Bwooce

Réponses:

21

TLDR : Vos protocoles TLS sont trop stricts car vous autorisez uniquement la connexion TLSv1.2.

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3

Et GMAIL envoie des e-mails à votre serveur avec le protocole TLSv1 . C'est pourquoi la négociation TLS échoue.

La solution évidente consiste à autoriser les protocoles TLSv1 et TLSv1.1 tout en désactivant les protocoles SSLv2 et SSLv3 (non sécurisés).

Explication

Je peux confirmer votre cas lorsque je ne reçois pas d'e-mail de GMAIL et FACEBOOK via STARTTLS .

Pourquoi ne GMAIL qui ne parvient pas à envoyer des e-mails à mon serveur

Ceci est l'extrait de maillog lorsque GMAIL envoie un e-mail

Dec 19 23:37:47 tls postfix/smtpd[3876]: initializing the server-side TLS engine
Dec 19 23:37:47 tls postfix/smtpd[3876]: connect from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: setting up TLS connection from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: mail-wg0-f47.google.com[74.125.82.47]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept:before/accept initialization
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept:error in unknown state
Dec 19 23:37:48 tls postfix/smtpd[3876]: SSL_accept error from mail-wg0-f47.google.com[74.125.82.47]: -1
Dec 19 23:37:48 tls postfix/smtpd[3876]: warning: TLS library problem: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Dec 19 23:37:48 tls postfix/smtpd[3876]: lost connection after STARTTLS from mail-wg0-f47.google.com[74.125.82.47]
Dec 19 23:37:48 tls postfix/smtpd[3876]: disconnect from mail-wg0-f47.google.com[74.125.82.47]

Et voici l'extrait de maillog lorsque FACEBOOK envoie un e-mail

Dec 19 23:11:14 tls postfix/smtpd[3844]: initializing the server-side TLS engine
Dec 19 23:11:14 tls postfix/tlsmgr[3846]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache
Dec 19 23:11:14 tls postfix/tlsmgr[3846]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup
Dec 19 23:11:14 tls postfix/smtpd[3844]: connect from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:14 tls postfix/smtpd[3844]: setting up TLS connection from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:14 tls postfix/smtpd[3844]: outcampmail003.ash2.facebook.com[66.220.155.162]: TLS cipher list "aNULL:-aNULL:ALL:+RC4:@STRENGTH:!aNULL:!DES:!3DES:!MD5:!DES+MD5:!RC4:!RC4-MD5"
Dec 19 23:11:14 tls postfix/smtpd[3844]: SSL_accept:before/accept initialization
Dec 19 23:11:15 tls postfix/smtpd[3844]: SSL_accept:error in unknown state
Dec 19 23:11:15 tls postfix/smtpd[3844]: SSL_accept error from outcampmail003.ash2.facebook.com[66.220.155.162]: -1
Dec 19 23:11:15 tls postfix/smtpd[3844]: warning: TLS library problem: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:647:
Dec 19 23:11:15 tls postfix/smtpd[3844]: lost connection after STARTTLS from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:15 tls postfix/smtpd[3844]: disconnect from outcampmail003.ash2.facebook.com[66.220.155.162]
Dec 19 23:11:16 tls postfix/smtpd[3844]: connect from outcampmail004.ash2.facebook.com[66.220.155.163]
Dec 19 23:11:17 tls postfix/smtpd[3844]: 962C281443: client=outcampmail004.ash2.facebook.com[66.220.155.163]
Dec 19 23:11:18 tls postfix/cleanup[3849]: 962C281443: message-id=<722b2b198d163c43d3bf013bdd396817@www.facebook.com>
Dec 19 23:11:18 tls postfix/qmgr[3843]: 962C281443: from=<notification+zj4zc0zzjfac@facebookmail.com>, size=18002, nrcpt=1 (queue active)
Dec 19 23:11:18 tls postfix/local[3850]: 962C281443: to=<root@tls.example.net>, orig_to=<zera@tls.example.net>, relay=local, delay=1.6, delays=1.5/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Dec 19 23:11:18 tls postfix/qmgr[3843]: 962C281443: removed
Dec 19 23:11:24 tls postfix/smtpd[3844]: disconnect from outcampmail004.ash2.facebook.com[66.220.155.163]

Quelques analyses

  • Dans le premier extrait, GMAIL essaiera d'envoyer des e-mails via STARTTLS. Lors de la négociation TLS, une erreur se produit, donc le serveur GMAIL le déconnecte. Nous expliquerons pourquoi l'erreur survenue ci-dessous.
  • Dans le deuxième extrait, FACEBOOK a également échoué à envoyer des e-mails via STARTTLS. Dans le processus de secours, FACEBOOK renvoie les e-mails en mode texte brut. Dans ce cas, notre serveur l'accepte volontiers.

C'est pourquoi cela explique pourquoi seul GMAIL ne parvient pas à envoyer de courrier électronique à votre serveur. GMAIL n'a pas de mécanisme de secours si la négociation TLS échoue . D'autres serveurs de messagerie peuvent utiliser un mécanisme de secours pour garantir la réussite de la remise des e-mails.

Pourquoi l'erreur de négociation TLS se produit

Je repère une ligne intéressante de web.de maillog 

Dec 19 17:33:15 foxdev 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)

Et découvrez que vous spécifiez cette configuration dans main.cf

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols=!SSLv2,!TLSv1,!TLSv1.1,!SSLv3

Cela signifie que votre serveur n'accepte la connexion TLS que lorsque TLSv1.2 est utilisé. Autre que TLSv1.2, votre serveur se plaindra d'une erreur de négociation TLS.

Si je passe smtpd_tls_(mandatory_)protocolsà !SSLv2,!SSLv3,!TLSv1, l'erreur se produit toujours. Cela signifie que GMAIL et FACEBOOK tenteront de contacter votre serveur de messagerie avec des protocoles autres que TLSv1.1 et TLSv1.2.

Si je passe smtpd_tls_(mandatory_)protocolsà !SSLv2,!SSLv3, la négociation TLS réussira. Il confirme que GMAIL et FACEBOOK contacteront votre serveur avec le protocole TLSv1

Dec 20 00:21:46 tls postfix/smtpd[4261]: Anonymous TLS connection established from outmail038.prn2.facebook.com[66.220.144.165]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
Dec 20 00:23:00 tls postfix/smtpd[4261]: Anonymous TLS connection established from mail-wi0-f174.google.com[209.85.212.174]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

D'autres personnes sur le forum FreeBSD confirment également ce comportement.

Solution

La solution évidente est d'activer TLSv1 et TLSv1.1 dans votre postfix. Cela garantira qu'un serveur de messagerie qui n'a pas de mécanisme de secours - comme GMAIL - peut toujours communiquer avec votre serveur.

Je ne connais pas votre raison de désactiver le support TLSv1 et TLSv1.1, ne laissant que le protocole TLSv1.2. S'il s'agit d'un serveur Web et que votre utilisateur utilisera uniquement un navigateur moderne, vous pouvez désactiver TLSv1 sur votre serveur. Ceci est acceptable car seul un navigateur plus ancien qui ne prend pas en charge le protocole TLSv1 .

— masegaloeh
source
0

Un problème potentiel que je peux voir est l'utilisation apparente d'un certificat auto-signé tel que rapporté par OpenSSL:

Verify return code: 19 (self signed certificate in certificate chain)

Si vous utilisez un certificat SSL payant, vous ne devez pas utiliser de certificat auto-signé.

Je voudrais vérifier que votre fichier PEM contient votre certificat payé, et vérifier également qu'il contient la chaîne de certificats complète.

— Craig Watson
source
Eh bien, le certificat auto-signé est le certificat racine de l'autorité de certification qui est auto-signé par l'autorité de certification.
— octobre
Qui est votre CA? S'ils utilisent des certificats auto-signés dans leur chaîne, vous devrez fournir la chaîne entière dans votre fichier .pem.
— Craig Watson
Il s'agit d'un certificat de Comodo. Je n'utilise pas de certificats signés par moi. Comme dit Comodo signe leur certificat racine par eux-mêmes, ce qui entraîne dans ce cascode: 19 (self signed certificate)
— Octfx
1
Vous ne devriez pas recevoir de code 19message si votre chaîne complète est diffusée. J'utilise un certificat de StartSSL, qui donne la même erreur en haut de la commande, mais comme je fournis la chaîne complète (y compris l'autorité de certification racine) dans le smtpd_tls_cert_filefichier PEM, le client a tous les certificats nécessaires pour valider la chaîne complète .
— Craig Watson
Je vais rééditer mon certificat juste pour le tester. Le problème est que je n'ai rien changé, google ne peut plus me livrer de mails
— Octfx
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.