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)
openssl s_client -connect localhost:25 -starttls smtp?Réponses:
TLDR : Vos protocoles TLS sont trop stricts car vous autorisez uniquement la connexion TLSv1.2.
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
Et voici l'extrait de maillog lorsque FACEBOOK envoie un e-mail
Quelques analyses
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
Et découvrez que vous spécifiez cette configuration dans
main.cfCela 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 TLSv1D'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 .
la source
Un problème potentiel que je peux voir est l'utilisation apparente d'un certificat auto-signé tel que rapporté par OpenSSL:
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.
la source
code: 19 (self signed certificate)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 lesmtpd_tls_cert_filefichier PEM, le client a tous les certificats nécessaires pour valider la chaîne complète .