Thunderbird не обновляет сертификат, продолжает использовать старый и сообщает, что он истек.

У меня есть почтовый сервер, где у меня есть SSL-сертификаты Let’s Encrypt, которые истекают каждые 3 месяца, и certbot автоматически их обновляет. Если я получаю доступ к серверу через веб-сайт в браузере, используется правильный и самый новый SSL-сертификат, но Thunderbird жалуется, что SSL-сертификат недействителен, т.е. он истек.

Жалоба отображается через диалоговое окно, и если я нажимаю, чтобы просмотреть сертификат через это окно, оно показывает старый сертификат, который действительно истек. Однако, если я нажимаю кнопку “Получить сертификат”, эта кнопка сереет, но ничего больше не происходит. Я пробовал щелкнуть правой кнопкой мыши на имени адреса электронной почты (аккаунта) в Thunderbird, перейти в Настройки -> Безопасность и удалить все сертификаты для домена, но, тем не менее, все равно остается старый сохраненный сертификат.

Моя конфигурация – dovecot + postfix.

Есть хоть какие-то идеи?

Thunderbird не использует тот же сервер для доступа к почте, как это делает браузер. Браузер подключается к веб-серверу через HTTP/HTTPS, в то время как Thunderbird подключается к почтовому серверу через протоколы IMAP/IMAPs или POP3/POP3s для получения почты и протокол SMTP для отправки. Это отдельные серверы с отдельной конфигурацией, что означает, что их необходимо настроить на использование соответствующих сертификатов в первую очередь, и их также нужно перезапускать, когда сертификаты обновляются.

Хотя невозможно сказать, что конкретно включает ваша установка (ИЗМЕНЕНИЕ: после редактирования вопроса стало ясно, что это установка, которую я описал), общей практикой является использование dovecot для получения почты и postfix для отправки. Так что вам, возможно, стоит изучить это программное обеспечение и конфигурации на вашей (неизвестной) системе и убедиться, что они обновляются и перезапускаются каждый раз, когда сертификаты меняются.

Dovecot может потребовать перезагрузки. У меня был именно такой случай с Postfix+Dovecot+certbot. Certbot показывал, что сертификат уже обновлен, но сервер по-прежнему использовал истекший сертификат. Я смог это увидеть, протестировав с помощью openssl (Ubuntu):

openssl s_client -connect mydomain.com:993 -quiet
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = mydomain.com
verify error:num=10:certificate has expired
notAfter=Dec  5 15:42:11 2020 GMT
verify return:1
depth=0 CN = mydomain.com
notAfter=Dec  5 15:42:11 2020 GMT
verify return:1
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE  AUTH=CRAM-MD5 AUTH=LOGIN AUTH=PLAIN] Dovecot (Ubuntu) готов.
^C

Перезагрузите Dovecot:

sudo service dovecot reload

Этого оказалось достаточно, чтобы исправить это в моем случае. Тем не менее, стоит проверить, требуется ли перезагрузка для сервера:

ls -l /var/run/reboot-required

Я сталкивался с аналогичной проблемой при подключении к серверу SMTP с включенным letsencrypt (postfix), используя порт 587 с STARTTLS. После часа отладки я выяснил, что Thunderbird использовал восстановление сессии TLS и, следовательно, не выполнял полноценное рукопожатие TLS, в результате чего новый сертификат не был отправлен сервером. Я пока не уверен, является ли это ошибкой в TB или неправильной конфигурацией на стороне сервера – на данный момент я установил время истечения сессии на 0 секунд на стороне сервера (тем самым фактически отключив кэширование сессий на стороне сервера) и перезапустил postfix, что мгновенно решило проблему.

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

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

Я запускаю CentOS (Stream) с postfix, dovecot, amavisd, mysql, clamd, spamassassin, selinux, opendkim, opendmarc и letsencrypt / certbot.

У меня есть 3 домена электронной почты и несколько веб-доменов, поэтому у меня есть отдельные сертификаты для каждого домена и сервера, которые certbot автоматически обновляет без проблем.

Тем не менее, поскольку я использую sni_maps (проверьте postfix), когда сертификат заменяется certbot, хотя postfix может перезапускаться / перезагружаться, файл sni_map.db необходимо пересоздать с помощью postmap -F, иначе сертификат не будет обновлен.

Благодаря ответу Роберта Холлера ответ, я смог это исправить. Если кто-то застрял на этой проблеме с Thunderbird, который не видит новые и действительные сертификаты, и имеет ту же конфигурацию с dovecot postfix и certbot, с несколькими почтовыми серверами на своем ВМ, вы, вероятно, используете sni.map, который необходимо повторно сопоставить после обновления сертификата. Поэтому решение для меня было:

postmap -F hash:/etc/postfix/sni.map

Это немного устарело, но я тоже столкнулся с этой проблемой. Это касалось postfix и postmap.

То, что произошло со мной, заключалось в том, что в vim /etc/postfix/sni_map URL не указывал на правильные сертификаты letsencrypt, потому что letsencrypt не был настроен с самого начала для моей системы.

Например, в моем /etc/postfix/sni_map (используя более новый postfix с debian 11):

domain.ca     /home/domain/ssl.key,/home/domain/ssl.cert,/home/domain/chain.pem    
.domain.ca
/home/domain/ssl.key,/home/domain/ssl.cert

даже несмотря на то, что это было настроено с тремя сертификатами, вы можете сделать это с letsencrypt

domain.ca  /etc/letsencrypt/live/domain.ca/privkey.pem,/etc/letsencrypt/live/domain.ca/fullchain.pem
.domain.ca /etc/letsencrypt/live/domain.ca/privkey.pem,/etc/letsencrypt/live/domain.ca/fullchain.pem

Затем для базы данных вы можете регенерировать с

postmap -F hash:/etc/postfix/sni_map

И перезагрузить или перезапустить postfix (я забываю, если перезагрузка работает)

systemctl restart postfix