Несколько дней назад Gmail неожиданно решил прекратить отправку почты на мой почтовый сервер. Я использую Postfix и Dovecot с платным SSL-сертификатом, работающим на Debian 7 со всем обновленным.
Мой mail.logпоказывает следующую ошибку:
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]
выдержки из моего постфикса 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
Я не знаю, где проблема, потому что я регулярно получаю письма от других. Нет ошибок при подключении к порту 25 через telnet или порт 465 через openssl
Дополнение: я получил это письмо взамен Google:
Delivery to the following recipient failed permanently:
<removed>
Technical details of permanent failure:
TLS Negotiation failed
----- Original message -----
[...]
Может быть, это проблема моего шифровщика?
Ответ на вопрос 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
Обновление 1:
Переиздание моего сертификата SSL. Сгенерировано все следующим образом:
openssl req -nodes -newkey rsa:2048 -keyout myserver.key -out server.csr -sha256
Затем я создал новый файл, состоящий из crtи key, после этого я создал пакет CA:
cat COMODORSADomainValidationSecureServerCA.crt COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > bundle.crt
Все добавил в мой конфиг dovecot и postfix и перезапустил обе службы.
Google по-прежнему не может отправить почту на мой сервер, что приводит кTLS Negotiation failed
Я попробовал другого почтового провайдера (web.de) и письмо отправлено.
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:
после включения TLSv1и TLSv1.1в smtpd_(mandatory)_protocolsразделе все работает нормально. Спасибо 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?Ответы:
TLDR : ваши протоколы TLS слишком строги, потому что вы разрешаете только соединение TLSv1.2.
И GMAIL отправляет электронную почту на ваш сервер по протоколу TLSv1 . Вот почему согласование TLS не удается.
Очевидное решение - разрешить протоколы TLSv1 и TLSv1.1 и по-прежнему отключать (небезопасные) протоколы SSLv2 и SSLv3.
объяснение
Я могу подтвердить ваш случай, когда не смог получить электронное письмо от GMAIL и FACEBOOK через STARTTLS .
Почему только GMAIL не может отправить письмо на мой сервер?
Это фрагмент почтового журнала, когда GMAIL отправляет электронную почту
И это фрагмент журнала, когда FACEBOOK отправляет письмо
Некоторый анализ
Итак, это объясняет, почему только GMAIL не может отправить электронную почту на ваш сервер. У GMAIL нет механизма восстановления в случае сбоя согласования TLS . Другой почтовый сервер может использовать резервный механизм для обеспечения успешной доставки электронной почты.
Почему возникает ошибка согласования TLS
Я замечаю интересную строку из почтового журнала web.de
И узнайте, что вы указываете эту конфигурацию в
main.cfЭто означает, что ваш сервер принимает соединение TLS только при использовании TLSv1.2. Кроме TLSv1.2, ваш сервер будет жаловаться на ошибку согласования TLS.
Если я изменяю
smtpd_tls_(mandatory_)protocolsна!SSLv2,!SSLv3,!TLSv1, ошибка все еще происходит. Это означает, что GMAIL и FACEBOOK будут пытаться связаться с вашим почтовым сервером с протоколами, отличными от TLSv1.1 и TLSv1.2.Если я перейду
smtpd_tls_(mandatory_)protocolsна!SSLv2,!SSLv3TLS, переговоры пройдут успешно. Это подтверждает, что GMAIL и FACEBOOK свяжутся с вашим сервером по протоколу TLSv1.Другие люди на форуме FreeBSD также подтверждают это поведение.
Решение
Очевидное решение - включить TLSv1 и TLSv1.1 в вашем постфиксе. Это позволит почтовому серверу, у которого нет резервного механизма, например, GMAIL, по-прежнему взаимодействовать с вашим сервером.
Я не знаю, почему вы отключили поддержку TLSv1 и TLSv1.1, оставив только протокол TLSv1.2. Если это веб-сервер и ваш пользователь будет использовать только современный браузер, то вы можете отключить TLSv1 на своем сервере. Это приемлемо, потому что только старый браузер не поддерживает протокол TLSv1 .
источник
Одна потенциальная проблема, которую я вижу, это очевидное использование самозаверяющего сертификата, как сообщает OpenSSL:
Если вы используете платный SSL-сертификат, вы не должны использовать самоподписанный сертификат.
Я бы проверил, содержит ли ваш PEM-файл ваш платный сертификат, а также убедитесь, что он содержит полную цепочку сертификатов.
источник
code: 19 (self signed certificate)code 19сообщение, если ваша полная цепочка обслуживается. Я использую сертификат из StartSSL, который выдает ту же ошибку в верхней части команды, но, поскольку я предоставляю полную цепочку (включая корневой CA) вsmtpd_tls_cert_fileфайле PEM, у клиента есть все сертификаты, необходимые для проверки полной цепочки ,