Обновлен EXIM4, теперь не используется TLS из-за сбоя проверки

Обновлен EXIM4, теперь не используется TLS из-за сбоя проверки

У меня есть домашний сервер, и я обновил системный диск до SSD, поскольку он был на комбинации USB и HDD для /home и /var. Поскольку USB был на предыдущей версии Debian, я сделал новую установку, которая также обновила меня до версии 4.95 EXIM, ранее я был на 4.94.2.

Несмотря на ту же конфигурацию смарт-хоста для использования SMTP-сервера моего интернет-провайдера, он больше не использует TLS и выдает ошибку проверки.

/var/log/exim4/mainlog:

2022-04-12 03:30:25 1ne6I7-000AHw-MF TLS session: (certificate verification failed): delivering unencrypted to H=<DOMAIN> [<IP>] (not in hosts_require_tls)

Почта по-прежнему принимается незашифрованной, но теперь почта из заданий cron помечается моим провайдером как спам. Единственное изменение — это сообщения, заголовок Receivedкоторых изменился with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2)с with esmtp (Exim 4.95). Так что, по-видимому, эта разница и есть то, что помечает его для дополнительного внимания.

Я использовал тот же самоподписанный ключ и сертификат (с меткой времени 2013), что и в предыдущей установке. Я также попытался создать новую пару с аналогичным отсутствием эффекта.

После поиска в интернете советов было предложено использовать конфигурацию letsencrypt, чтобы ее можно было проверить. Я уже использую ее, но она вызывала то же самое поведение в EXIM.

Это моя конфигурация

/etc/exim4/update-exim4.conf.conf:

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='<LOCAL DOMAIN>'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='<ISP DOMAIN>:587'
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'

/etc/exim4/etc/exim4/conf.d/main/00_local_settings:

MAIN_TLS_ENABLE = yes
MAIN_TLS_CERTIFICATE = /etc/letsencrypt/live/<LOCAL DOMAIN>/fullchain.pem
MAIN_TLS_PRIVATEKEY = /etc/letsencrypt/live/<LOCAL DOMAIN>/privkey.pem

/etc/letsencrypt/archive/<ЛОКАЛЬНЫЙ ДОМЕН>/*15.*

-rw-r--r-- 1 root Debian-exim 1870 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/cert15.pem
-rw-r--r-- 1 root Debian-exim 3749 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/chain15.pem
-rw-r--r-- 1 root Debian-exim 5619 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/fullchain15.pem
-rw------- 1 root Debian-exim 1708 Mar 28 00:48 /etc/letsencrypt/archive/<LOCAL DOMAIN>/privkey15.pem

У меня также есть /etc/exim4/passwd.clientфайл с моими данными для входа в SMTP, который, очевидно, работает и вообще отправляет почту.

— это домен, который указывает на мой домашний IP-адрес.

Записи ключей letsencrypt в 00_local_settings указывают на его символические ссылки, которые ведут к текущим версиям. На них я изменил владельца группы, чтобы EXIM мог видеть закрытый ключ, но оставил разрешения в покое.

Моя предыдущая рабочая конфигурация была такой же, но с самоподписанными файлами exim.crtи exim.keyв /etc/exim4, и, следовательно, без последних двух строк в моем файле 00_local_settings.

Я также пробовал скопировать файлы letsencrypt /etc/exim4и назвать их exim.certс exim.keyтеми же разрешениями 640 и ничего в 00_local_settings, но это ничего не изменило.

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

решение1

Я продолжил исследование и нашел ответ, своего рода. Мне было непонятно, чей сертификат проверялся, я предположил, что мой, но понял, что это мог быть сертификат удаленного SMTP-сервера.

Добавление записи ниже /etc/exim4/etc/exim4/conf.d/main/00_local_settingsотключает проверку и позволяет использовать TLS.

REMOTE_SMTP_SMARTHOST_TLS_VERIFY_HOSTS = !*

Это можно подтвердить в заголовке сообщения, который теперь показывает, что оно получено.with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95)

Я предполагаю, что именно это и происходило раньше, и что либо Debian, либо Exim изменили настройки по умолчанию, чтобы требовать проверку с момента моей первоначальной настройки.

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

Связанный контент