Запуск Amazon Linux на инстансе EC2 с sendmail. У меня есть учетная запись электронной почты в Network Solutions, и я использую ее в качестве SMART_HOST реле в моем sendmail конфигурация. Работает хорошо, за исключением одной маленькой детали.
В моем maillog file я вижу такие записи:
sendmail[28450]: STARTTLS=client, relay=mail.example.com.netsolmail.net., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256
После небольшого исследования я пришел к выводу, что verify=FAIL по сути безвреден: соединение действительно было зашифровано, просто сертификат хоста проверить не удалось.
Поскольку никто, кроме меня, не читает файл журнала, мне было бы все равно. Но когда приходит сообщение, Received заголовок показывает
Received: from unknown (HELO example.com) (info@example.com@12.34.56.78)
by 0 with ESMTPA; 15 Aug 2016 07:10:15 -0000
Я надеялся увидеть with ESMPTSA но я бы предположил, что ошибка проверки сертификата вызвала подавление буквы «S».
Как я могу получить более подробную информацию о том, что было не так с сертификатом, и как избежать неудачной проверки? Я предполагаю, что несколько поддоменов mail.example.com.netsolmail.net не совпадают достаточно точно с именем в сертификате. Но как я могу это проверить и как избежать жалобы - или, точнее, как я могу получить Received заголовок, чтобы подтвердить безопасное соединение с ESMTPSA.
РЕДАКТИРОВАТЬ: я редактировал sendmail.mc добавить
define(`confLOG_LEVEL', `15')dnl
Теперь maillog дает более подробную информацию. Сразу после verify=FAIL строка, которую я теперь вижу:
sendmail[30706]: STARTTLS=client, cert-subject=/OU=GT39680792/OU=See+20www.rapidssl.com/resources/cps+20+28c+2915/OU=Domain+20Control+20Validated+20-+20RapidSSL+28R+29/CN=*.hostingplatform.com, cert-issuer=/C=US/O=GeoTrust+20Inc./CN=RapidSSL+20SHA256+20CA+20-+20G3, verifymsg=unable to get local issuer certificate
Я полагаю, это означает, что по крайней мере одна из причин сбоя проверки заключается в том, что sendmail не может найти сертификат для локальной машины, на которой он работает? Поскольку я только ретранслирую исходящую почту на сервер netsol и никогда не принимаю входящую почту из Интернета, я не думал, что мне понадобится сертификат для этого сервера. Если он мне нужен, где / как мне его установить? И может ли это быть тот же сертификат, который я использую для своего веб-сервера, или мне нужен другой? Достаточно ли использовать самоподписанный сертификат, чтобы получить Received заголовок сказать with ESMTPSA, или это должен быть коммерческий сертификат от центра сертификации?
РЕДАКТИРОВАТЬ № 2:
Принимаю ответ @MadHatter. Ключ получал confCACERT определено. Я смущен, мое единственное оправдание - старый дряхлый мозг не трясет источником m4. В файле sendmail.mc по умолчанию в Amazon Linux уже есть
define(`confCACERT_PATH', `/etc/pki/tls/certs')dnl
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.crt')dnl
в нем, и я убедился, что файл существует. Но Я не заметил хитрого маленького dnl это было фактически в начале этих строк! Я знаю, что это значит, но так как я очень редко смотрю исходники m4, и это было сразу после какого-то другого dnl-ed строки, отмеченные как комментарии с помощью #мой мозг зарегистрировал их как не комментируется!
На самом деле я прошел через кучу циклов, скачивая сертификаты из Firefox и указывая sendmail на сертификат Digicert, который я использую для нашего веб-сайта, но поскольку этот хост только отправляет, никогда не получает электронную почту, больше ничего не нужно. Я положил обратно dnl на определениях для confSERVER_CERT и confSERVER_KEY, и все было хорошо, с maillog показывая verify=OK и verifymsg=ok на соответствующем STARTTLS=client линий.
Но хотя диагностики TLS не было, Received заголовок для подключения к нетсол все еще показывает with ESMTPA и нет with ESMTPSA. Да ладно, у @MadHatter тоже был наркотик. Извините, это было так долго и что-то вроде охоты на диких гусей. Но я многому научился и улучшил свою конфигурацию (несущественным образом). Я надеюсь, что кто-то, достаточно отчаявшийся, чтобы преодолеть это, тоже может чему-то научиться.
Это очень часто вопрос по частям, и я приму его как таковой. Я использовал sendmail в качестве моего любимого MTA в течение нескольких десятилетий, но я не могу утверждать, что я в этом эксперт (т.е. я не Эрик Оллман).
verifymsg=unable to get local issuer certificateЯ полагаю, это означает, что по крайней мере одна из причин сбоя проверки заключается в том, что sendmail не может найти сертификат для локальной машины, на которой он работает?
Это кажется сообщение OpenSSL, а не сообщение MTA, и, насколько я понимаю, это означает, что проверяющее приложение не может получить локальную копию сертификата эмитента. Другими словами, sendmail не имеет доступа к набору сертификатов, который включает корневой сертификат для того, кто выпустил сертификат удаленного сервера. Помните, что Linux не предоставляет централизованную службу управления сертификатами, поэтому каждое приложение должно создавать свой собственный пакет. В моем случае я предоставил sendmail доступ к набору сертификатов со следующим кодом m4:
define(`confCACERT', `/etc/pki/tls/certs/ca-bundle.with.intermediate.crt')dnl
Я надеялся увидеть с ESMPTSA, но я предполагал, что сбой проверки сертификата привел к подавлению буквы «S».
Я думаю, что это неверное предположение. RFC2821 и 2822 довольно гибки в отношении формата заголовка Received :, и я не могу найти в них ничего, что различает ESMTPA и ESMPTSA (так в оригинале). Все мои заголовки содержат такие строки, как:
Received: from example.com (example.com [80.70.90.61])
by lory.teaparty.net (8.14.4/8.14.4) with ESMTP id u6G25OXi006577
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <me@example.net>; Sat, 16 Jul 2016 03:05:24 +0100
Чтобы понять, что означает MTA вашего приемника, ESMTPA, вам нужно узнать, что это за MTA, и прочитать документацию. Пока вы этого не сделаете, я не думаю, что вы сможете многое прочитать в этом сборнике писем.
Могу ли я избежать стартапов
verify=failкогда имя хоста сервера не соответствует сертификату
Я не думаю, что ты сможешь. Основная идея SSL заключается в том, что (а) имя хоста, к которому вы подключаетесь (б) предлагает сертификат, подписанный доверенной третьей стороной (c) с этим именем хоста в поле CN или SAN. Если какое-либо из этих свойств не выполняется, SSL правильно отмечает, что он не может проверить идентичность партнера.
Не стоит вдаваться в подробности; самоподписанные сертификаты все еще очень распространены при обработке электронной почты. Из моих последних 1919 отправленных / полученных сообщений электронной почты, защищенных TLS, 1764 касались однорангового узла, личность которого не удалось проверить по какой-либо причине, в то время как только 155 могли. Вы сами работаете с самоподписанным сертификатом; поэтому вы должны быть счастливы, что большинство людей действительно не заботятся о цепочке доверия на SMTP TLS-узлах!