LINUX.ORG.RU

Проблемы с SSL на почтовом сервере

 , , ,


0

3

Имеется почтовый сервер под управлением Debian 8/Postfix/Dovecot. Для сервера получен платный SSL сертификат. Сертификат лежит в директории /etc/ssl/certs с правами 600 root root (скомпонован в порядке root+intermediate+public). Приватный ключ лежит в /etc/ssl/private с правами 400 root ssl-cert.

Теперь симптомы:

1.) Гугль стал отправлять мои письма в спам без вариантов. При этом в веб интерфейсе гугля изображён разомкнутый замочек и надпись:

example.com did not encrypt this message
http://imgur.com/JQALQaG learn (предлагает гугль).

2.) Следующий симптом:

openssl s_client -starttls smtp -crlf -connect mx.example.com:587
выдаёт следующее:
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=RU/OU=Domain Control Validated/CN=mx.example.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
...
...
...
Start Time: 1455137423
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
Хотя я точно помню, что, когда установил этот недавно купленный сертификат, то код был 0. Вот так:
  Verify return code: 0 (ok)

3.) Следующий симптом:

openssl s_client -connect mx.example.com:993
Получаю ответ:
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=RU/OU=Domain Control Validated/CN=mx.example.com
   i:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - SHA256 - G2
 1 s:/C=BE/O=GlobalSign nv-sa/CN=GlobalSign Domain Validation CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
 2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
...
...
...
Start Time: 1455137583
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

Теперь резюмирую: сертификат новый, получен пару недель назад. Verify return code был 0, это факт. Права на сертификат и на ключ я менял для проверки, ничего не изменилось. nginx с эти сертификатом не показывает никаких проблем. Но openssl s_client -connect выдаёт тот же код ошибки.

Вопрос: что это может быть? Имеет ли смысл перевыпускать сертификат? Куда копать?

P.S.: порядок сертификатов точно правильный. Вот такой:

-----BEGIN CERTIFICATE-----
#Your GlobalSign SSL Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Intermediate Certificate#
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
#GlobalSign Root Certificate#
-----END CERTIFICATE-----

UPDATE: Вот что сообщает гугль:

Предупреждения о шифровании

Если в полученном сообщении или черновике появился красный значок взломанного значка , это означает, что письмо не зашифровано.

Красный значок взломанного замка в черновике

Значок указывает, что на стороне получателя шифрование не поддерживается, поэтому конфиденциальные данные, например бухгалтерскую документацию, лучше не отправлять.

Красный значок взломанного замка в полученном письме

Сообщение не было зашифровано. В этом случае вы ничего не можете предпринять. Если переписка с этим отправителем носит конфиденциальный характер, сообщите ему о возможных рисках и попросите обратиться к его поставщику услуг электронной почты.

Почему некоторые сообщения не шифруются

Gmail шифрует 100% входящих и исходящих сообщений по протоколу TLS. Однако если почтовый сервис человека, с которым вы переписываетесь, шифрует не все сообщения, некоторые письма от него могут быть небезопасными. Чтобы шифрование по TLS сработало, оно должно поддерживаться и на стороне отправителя, и на стороне получателя. Подробнее…

Особые случаи

Когда вы пишете сообщение, Gmail проверяет, поддерживается ли шифрование в почтовом сервисе получателя, и предупреждает о возможных рисках. Результаты этой проверки могут быть неточными, если в поле "От" вы указываете добавленный адрес из другого домена (не @gmail.com).

Теперь мои настройки:

# /etc/postfix/main.cf
smtpd_use_tls=yes
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_ciphers = medium
tls_medium_cipherlist = AES128+EECDH:AES128+EDH

smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_cert_file = /etc/ssl/certs/mx.example.com.crt
smtpd_tls_key_file = /etc/ssl/private/mx.example.com.private.key
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
#/etc/dovecot/dovecot.conf
ssl = yes
ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = AES128+EECDH:AES128+EDH

#ssl = required
ssl_ca = </etc/ssl/certs/ca-certificates.crt
ssl_cert = </etc/ssl/certs/mx.example.com.crt
ssl_key = </etc/ssl/private/mx.example.com.private.key

Я правда не использую TLS?

Deleted

кто-то по дороге тебе сертификат поменил? ты цепляешься на сервер откуда?

anonymous ()
Ответ на: комментарий от anonymous

В смысле откуда? Mutt использую и ssh. Копия сертификата лежит у меня в надежном месте. Сравнил с помощью vimdiff. Ничего не поменялось. Надежда была на то, что я чтог-то с правами намутил: на сам сертификат или на приватный ключ. Но смена прав ничего не даёт.

Факт тот, что всё работало ещё пару недель назад.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 2)
Ответ на: комментарий от anonymous

локалхост?

Подключаюсь удалённо: сервер находится у Digital Ocean.

openssl s_client -connect mx.example.com:993 -showcerts -CApath /etc/ssl/certs

Вот

Deleted ()
Ответ на: комментарий от Deleted

smtp и smtpd это два разных демона, посмотрите архитектуру postfix'a
smtp - Postfix SMTP+LMTP client
smtpd - Postfix SMTP server
согласно документации, использование TLS для доставки на удаленный сервер включается именно опцией smtp_use_tls

thematt ()
Последнее исправление: thematt (всего исправлений: 2)
Ответ на: комментарий от thematt

Спасибо, это помогло от красного замочка. Проблема с сертификатами так и осталась (пункты 2 и 3), и письма по прежнему падают в спам на гугле.

Deleted ()
Ответ на: комментарий от Deleted

self-signed сертификат в цепочке будет всегда по определению. Корневые сертификаты всегда самоподписаны. Твой openssl client не доверяет /C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA. Попробуй разобраться, откуда openssl client берёт список доверенных корневых сертификатов. Вероятно он у тебя изменился, раньше в нём был этот корневой сертификат, а потом исчез.

А со спамом техническими средствами проблему не решить. Настрой что можешь, но не рассчитывай, что твоя почта не будет падать в спам. Это только алгоритмы гугла решают. Можешь отправлять своё письмо друзьям и попросить их убрать метку «Спам» с писем, это может помочь обучить гугл.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Вероятно он у тебя изменился, раньше в нём был этот корневой сертификат, а потом исчез.

Да, так и оказалось!

Раньше я запускал команду openssl с centos 7, и получал правильный результат (код 0). Сейчас же запускал в Debian и получил код 19.

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.