Почему Thunderbird ругается на сертификат, хотя он вроде свежий? И как это починить

Привет! Сегодня разберём одну из тех ситуаций, когда всё «вроде работает», но клиенты всё равно ломаются. Конкретно — 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 и забудьте об этом навсегда.

Удачи в автоматизации! А если что — пишите в комментарии. Может, вместе что-нибудь починим.

Посетителей сегодня: 0

кто я | книга | контакты без контактов