Задачи электронной почты не выполняются после последнего обновления: ошибка проверки сертификата (не удалось получить локальный сертификат издателя)

Извините за еще один избыточный вопрос, так как я вижу, что есть много похожих запросов в службу поддержки, например: Email Notifications Failing after Update, но наше сообщение об ошибке немного отличается:

“ошибка проверки сертификата (не удалось получить локальный сертификат издателя)”

Это произошло после обновления 11 мая до версии 2.9.0
from_version: a76256756fc8442eab960cc1c7d37a737efb5a69,
repository: /var/www/discourse, /var/www/discourse/plugins/styleguide

Я вижу на GitHub, что это затрагивает sidekiq — не стал ли он внезапно более придирчивым? Я также решаю эту проблему с нашим mailrelay, но если я смогу предоставить им более конкретную информацию о том, как это исправить, или если проблема на стороне нашего форума (https://forum.solarfarmer.dnv.com/), это поможет нам быстрее устранить неполадки.

Спасибо за любую помощь.

Это та же проблема, что и Email Hostname Certificate Mismatch Causing sidekiq Queue Overload, Severe Site Instability

@RGJ Я попробовал запустить

openssl s_client -connect  smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"

но это не показывает никаких других доменов, а выводит ту же ошибку, что и sidekiq: “unable to get local issuer certificate” и ещё много чего. Я пробовал менять настройки почты в app.yml на наш почтовый релей и обратно, каждый раз запуская ./launcher rebuild app, но пока ничего не работает.

Это может быть вызвано тремя причинами:

  • истёкший срок действия сертификата
  • имя хоста в сертификате отличается от имени хоста, к которому вы подключаетесь
  • отсутствие сертификата вообще

Похоже, что у вас возникла последняя проблема. Единственное решение — убедиться, что у вас настроен корректно SMTP-сервер, поддерживающий STARTTLS и имеющий правильный сертификат.

Спасибо, @RGJ, но почему эта проблема возникла только после обновления до версии 2.9.0? Связано ли это с тем, что STARTTLS стал строже применять это требование? В нашем почтовом ретрансляторе и в конфигурации почты в файле app.yml ничего не менялось. IP-адрес сайта добавлен в белый список почтового ретранслятора, который обслуживается отделом ИТ. Я не имею над этим контроля. CNAME сайта также контролируется нашим отделом ИТ. У них разные домены: CNAME — «dnv.com», а почтовый ретранслятор — «dnvgl.com». Может ли это быть частью проблемы? Я параллельно работаю над этим вопросом с нашим отделом ИТ, но стараюсь предоставить им как можно больше информации. Прошу прощения за мою неосведомлённость: многое из этого для меня слишком сложно, поэтому я могу использовать неверные термины. Извините :frowning:

Это произошло из-за того, что между версиями 2.9.0.beta3 и beta4 Discourse обновилась до Rails 7, что и вызвало данную проблему.

Подробнее: Email Hostname Certificate Mismatch Causing sidekiq Queue Overload, Severe Site Instability - #47 by RGJ

Наш IT-отдел говорит: «С сертификатами [для почтового ретранслятора] всё в порядке: все они активны и правильно настроены для использования с SMTP-сервисом. Во-вторых, мы не получали никаких сообщений о проблемах от других сервисов/клиентов, использующих этот почтовый ретранслятор». :cry:

IT создал новый почтовый аккаунт с использованием Office365 onmicrosoft, но у меня всё ещё возникают проблемы. Теперь я получаю либо ReadTimeout, либо SMTPAuthenticationError: Unrecognized authentication type.

Моя текущая конфигурация:

DISCOURSE_SMTP_ADDRESS: smtp.office365.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: myusername
DISCOURSE_SMTP_PASSWORD: "mypassword"  # нужны ли кавычки?
DISCOURSE_SMTP_ENABLE_START_TLS: true  # это правильно?
DISCOURSE_SMTP_DOMAIN: outlook.com
DISCOURSE_NOTIFICATION_EMAIL: myusername@mycompany.onmicrosoft.com

где my* специфичны для нового почтового аккаунта.

@RGJ Хочу поблагодарить всех за помощь. Наконец-таки, наконец-таки я решил эту проблему. Настройка для Office365 заключается в использовании DISCOURSE_SMTP_AUTHENTICATION: login.

Настройки SMTP-сервера и порта для Office365: smtp.office365.com:587 с включённым STARTTLS, что является настройкой по умолчанию.

Имя пользователя — это полный адрес электронной почты организации, использующей Office365, обычно в формате myaccount@mycompany.onmicrosoft.com. Он может совпадать, а может и не совпадать с вашим адресом для уведомлений.

Вот моя финальная конфигурация:


  DISCOURSE_SMTP_ADDRESS: smtp.office365.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: myacct@mycompany.onmicrosoft.com
  DISCOURSE_SMTP_PASSWORD: mypassword
  DISCOURSE_SMTP_ENABLE_START_TLS: true
  DISCOURSE_SMTP_DOMAIN: outlook.com
  DISCOURSE_NOTIFICATION_EMAIL: myacct@mycompany.com
  DISCOURSE_SMTP_AUTHENTICATION: login

Согласно Mail Tester, результат — 10 из 10!

У нас наблюдается точно такая же проблема с корректно настроенным SMTP-сервером, который используется десятками других служб. На SMTP-сервере используется wildcard-сертификат, выпущенный Let’s Encrypt.

Ошибка гласит: «(unable to get local issuer certificate)».

Я думаю, что это ошибка, описанная здесь: Disabling starttls or certificate verification does not work any more

Хотя вы говорите, что у вас действительный сертификат. Так что, возможно, я ошибаюсь.

Попробуйте проверить доменное имя, используя команды, рекомендованные @RGJ:

openssl s_client -connect smtp.mydomain.info:25 -starttls smtp -showcerts 2>&1|grep "depth=0"

Убедитесь, что ваш домен совпадает с сертификатом, возвращённым утилитой openssl, если таковой имеется. Также ознакомьтесь с темой «Email Hostname Cert Mismatch Causing sidekiq…», ссылкой на которую выше.

Кроме того, руководство по устранению неполадок с электронной почтой очень помогло мне. Мне пришлось несколько раз внимательно его перечитать, чтобы найти нужную информацию. Возможно, вы тоже что-то там обнаружите?