Привет! Сегодня разберём одну из тех ситуаций, когда всё «вроде работает», но клиенты всё равно ломаются. Конкретно — Thunderbird не подключается к почтовому серверу по IMAP/SMTP, выдаёт ошибку безопасности, а веб-интерфейс работает нормально. Причём сертификат только что перевыпущен. Кто виноват и что делать?
Симптомы
- Веб-версия почты (HTTPS) — работает, браузер доверяет сертификату.
- Thunderbird при настройке IMAP/SMTP выдаёт: «Не удалось получить информацию о подлинном статусе сайта».
- Сертификат выпущен Let’s Encrypt, срок ещё не истёк (кажется).
- Сервер — Ubuntu, почта на Dovecot, сертификат через Certbot.
Диагностика
Первым делом проверяем сертификат вручную через OpenSSL:
openssl s_client -connect pochta.example.com:993 -servername pochta.example.comВ выводе видим:
verify error:num=10:certificate has expired
notAfter=Nov 6 14:19:44 2025 GMTА сегодня — 7 ноября 2025 года. То есть сертификат уже просрочен на один день.
Но ведь мы его обновляли! Или нет?
Перевыпуск сделан — но не применён
Запускаем принудительное обновление:
sudo certbot renew --force-renewalВсё проходит успешно. Файлы в /etc/letsencrypt/live/pochta.example.com/ обновились. Веб-сервер (Nginx/Apache) подхватил новый сертификат — поэтому HTTPS работает.
А вот Dovecot — нет. Он продолжает держать старый сертификат в памяти, потому что его никто не попросил перечитать конфигурацию.
Результат: Thunderbird подключается к Dovecot → Dovecot отдаёт старый (просроченный) сертификат → Thunderbird блокирует соединение.
Решение
Нужно просто сказать Dovecot: «Эй, перечитай сертификат!»
sudo systemctl reload dovecotИли, если не уверены в мягкости reload:
sudo systemctl restart dovecotПосле этого проверяем снова:
openssl s_client -connect pochta.example.com:993 -servername pochta.example.com | grep "Not After"Видим дату на 3 месяца вперёд — отлично! А в самом выводе:
Verify return code: 0 (ok)Thunderbird теперь подключится без проблем.
Как не повторять это вручную через 3 месяца?
Let’s Encrypt сертификаты живут 90 дней. Если не автоматизировать перезагрузку Dovecot — через 3 месяца всё повторится.
Но Certbot умеет выполнять команды после успешного обновления. Для этого в конфигурации домена добавляем post_hook.
Открываем:
sudo nano /etc/letsencrypt/renewal/pochta.example.com.confИ в секции [renewalparams] добавляем:
post_hook = systemctl reload dovecotЕсли у вас также используется Postfix для SMTP — добавьте и его:
post_hook = systemctl reload dovecot postfixТеперь при каждом реальном обновлении сертификата Dovecot (и Postfix) будут автоматически перезагружены. И ни вы, ни ваши пользователи не увидят ошибок.
Почему не стоит делать это через крон с задержкой?
Некоторые советуют написать в кроне:
# НЕ ДЕЛАЙТЕ ТАК!
0 2 * * * sleep 600 && systemctl reload dovecotЭто ненадёжно:
- Если Certbot обновит сертификат за 2 секунды — вы перезагрузите Dovecot слишком рано (со старым сертификатом).
- Если Certbot не обновит сертификат (ещё не время) — вы зря перезагрузите Dovecot.
post_hookработает ТОЛЬКО если обновление действительно произошло. Это чище, надёжнее и логичнее.
Вывод
Проблема не в Thunderbird, не в сертификате и даже не в Let’s Encrypt. Проблема — в том, что почтовый сервер не знал, что сертификат поменялся.
Решение: обновить сертификат → перезагрузить Dovecot → настроить post_hook.
После этого всё будет работать тихо, надёжно и без танцев с бубном раз в три месяца.
Если у вас похожая ситуация — проверьте, не забыли ли вы перезапустить Dovecot после обновления сертификата. А лучше — настройте post_hook и забудьте об этом навсегда.
Удачи в автоматизации! А если что — пишите в комментарии. Может, вместе что-нибудь починим.
Комментарии
Пока нет комментариев. Будьте первым!