Как исправить Let’s Encrypt, Dovecot и SMTP в Thunderbird на старом почтовом сервере

Как я восстановил Let's Encrypt для mail.examle.com и исправил подключение Thunderbird к старому Dovecot/Postfix​

В этой статье я разберу реальный случай с почтовым сервером mail.examle.com.

Сервер достаточно старый:

• Dovecot 2.0.9;
• OpenSSL 1.0.1e-fips;
• старый Postfix;
• nginx;
• Let's Encrypt через устаревший letsencrypt-auto.

Проблема началась с того, что перестало нормально проходить обновление сертификата Let's Encrypt, а после его получения Thunderbird всё равно не хотел подключаться к почтовому серверу.

В итоге оказалось, что здесь наложились сразу несколько независимых проблем:

1. nginx перенаправлял запрос проверки Let's Encrypt с HTTP на HTTPS;
2. certbot-auto уже официально не поддерживается;
3. Dovecot использовал устаревшие 1024-битные DH-параметры;
4. SMTP на порту 465 согласовывал древний TLS 1.0;
5. Thunderbird нормально заработал после перехода SMTP на порт 587 с STARTTLS.

Ниже покажу всю диагностику по порядку.

Исходная ошибка Let's Encrypt​

Я запускал получение сертификата следующим образом:


Certbot сразу предупреждал:


Это отдельная проблема: certbot-auto давно устарел и больше не получает обновлений.

Но непосредственно выпуск сертификата ломался по другой причине:


Особенно важной здесь была строка:


Для HTTP-01 challenge проверка первоначально приходит по HTTP, то есть на порт 80.

Почему nginx ломал ACME challenge​

В конфигурации mail.examle.com у меня был такой редирект:


Одновременно был location для Let's Encrypt:


На первый взгляд всё выглядело правильно.

Но серверный return 301 отправлял в HTTPS в том числе запросы:


В результате получалась цепочка:

Правильная конфигурация nginx для ACME​

Я разделил HTTP и HTTPS.

Для HTTP оставил отдельный server:


Таким образом:

• обычные HTTP-запросы перенаправляются на HTTPS;
• /.well-known/acme-challenge/ остаётся доступным непосредственно по HTTP.

А HTTPS работает отдельно:

Проверка webroot вручную​

Перед новым запуском Let's Encrypt я решил проверить, действительно ли nginx отдаёт файлы из нужного каталога.

Создал тестовый файл:


Проверил nginx:


После чего перезагрузил конфигурацию:


И проверил с помощью curl:


Правильный результат:


При этом не должно происходить:


Также можно проверить непосредственно backend:


После этого сертификат Let's Encrypt успешно выпустился.

Проверяю новый сертификат​

Проверил симлинки:


В моём случае они уже указывали на свежие файлы сертификата:


Затем:


Сертификат был корректный:


То есть проблема непосредственно с Let's Encrypt была решена.

Thunderbird всё равно ругается​

После обновления сертификата Thunderbird поначалу продолжал показывать окно добавления исключения безопасности для:


Я решил не добавлять исключение, а проверить сервер.

И это правильный подход: если сервер должен использовать нормальный сертификат Let's Encrypt, создавать постоянное исключение в почтовом клиенте не нужно.

Проверяю IMAPS на порту 993​

Сначала проверил, слушает ли порт Dovecot:


Результат:


Затем проверил TLS локально:


И по DNS-имени:


В обоих случаях сертификат был правильным:


То есть:

• порт 993 доступен;
• Dovecot работает;
• сертификат правильный;
• цепочка сертификатов валидна.

Проверяю конфигурацию Dovecot​

Проверил:


Получил:


То есть Dovecot уже использовал именно новый Let's Encrypt.

Версия оказалась очень старой:


Результат:

Обнаруживаю ещё одну проблему: DH 1024​

При TLS-подключении OpenSSL показывал:


Проверил настройки:


Получил:


Полные SSL-настройки выглядели примерно так:


В /etc/dovecot/conf.d/10-ssl.conf при этом находилась строка:


То есть использовалось значение по умолчанию.

Для такого старого сервера разумно увеличить DH хотя бы до 2048:


После изменения:


Проверить результат можно так:


В идеале:

ECDHE старый Dovecot не использовал​

Сам OpenSSL на сервере поддерживал ECDHE:


Например:


Но при принудительном подключении:


Dovecot отвечал:


То есть наличие ECDHE в OpenSSL ещё не означает, что конкретная старая версия Dovecot будет его нормально использовать.

Проблема оказалась ещё и в SMTP​

После исправления сертификата Thunderbird всё равно не мог завершить автоматическую проверку учётной записи.

Настройки были такими:


Я проверил открытые порты:


Все необходимые службы слушали:


Следовательно, дело было не в закрытом порте.

Проверяю SMTP 465​

Запустил:


Сертификат снова был правильный:


Но в конце обнаружилось главное:


То есть SMTP на 465 порту договаривался всего лишь о:


Для современного Thunderbird это уже слишком старый TLS.

Почему порт 465 не работал в Thunderbird​

Сам порт был открыт.

Сертификат был валиден.

DNS был правильным.

Но сервер предлагал старый TLS:


Современный Thunderbird такие настройки по умолчанию уже не принимает.

Поэтому я не стал ослаблять настройки безопасности Thunderbird.

Вместо этого проверил второй стандартный SMTP submission порт — 587.

Окончательное решение: SMTP 587 + STARTTLS​

В Thunderbird я изменил только настройки сервера исходящей почты.

Было:


Стало:


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

Моя итоговая конфигурация Thunderbird​

Входящая почта — IMAP


Например:


Исходящая почта — SMTP


То есть в моём случае итоговая схема получилась такой:

Набор команд для быстрой диагностики​

Если столкнусь с подобной проблемой снова, сначала проверю именно эти вещи.

1. Какие почтовые порты слушаются:


2. IMAPS:


3. SMTPS 465:


4. SMTP Submission 587:


5. Сертификат Let's Encrypt:


6. SSL-настройки Dovecot:


7. Версия Dovecot:


8. Версия OpenSSL:

На что смотреть в openssl s_client​

Меня интересуют прежде всего строки:


Хороший результат проверки сертификата:


Если вижу:


это уже тревожный сигнал для современного почтового клиента.

Если вижу:


сервер также использует устаревшие DH-параметры.

Не стоит сразу добавлять исключение безопасности​

Если Thunderbird предлагает:


я теперь сначала проверяю сервер через OpenSSL.

Если сервер должен использовать публичный сертификат Let's Encrypt, лучше устранить причину на сервере, а не создавать постоянное исключение в Thunderbird.

Особенно проверяю:

• правильное ли имя хоста;
• правильный ли сертификат отдаётся;
• полная ли цепочка сертификатов;
• действителен ли сертификат;
• какая версия TLS используется;
• какой cipher согласован;
• какой размер DH используется;
• на каком SMTP-порту работает современный TLS.

Что ещё нужно модернизировать​

После восстановления почты сама инфраструктура всё равно остаётся устаревшей.

В моём случае это:


Поэтому решение с портом 587 позволило быстро вернуть работоспособность Thunderbird, но в перспективе такой почтовый сервер стоит обновить.

Особенно желательно избавиться от:

• TLS 1.0;
• 1024-битного DHE;
• старого OpenSSL;
• Dovecot 2.0.x;
• certbot-auto.

Итог​

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

Сначала Let's Encrypt не мог пройти HTTP-01 из-за nginx:


После исправления nginx новый сертификат успешно выпустился.

Dovecot на 993 уже корректно отдавал сертификат Let's Encrypt:


Но Thunderbird всё равно не завершал настройку.

Причина обнаружилась на SMTP 465:


В итоге мне даже не пришлось серьёзно переделывать Postfix.

Я просто перевёл Thunderbird с:


на:


И после этого всё заработало.

Итоговая рабочая схема:


Для старого почтового сервера это оказалось самым простым способом восстановить работу современного Thunderbird без искусственного снижения требований безопасности на стороне клиента.