Какое имя хоста должно содержать SSL-сертификат для SMTP-сервера?

У меня есть сервер foo.example.com на 192.0.2.1

Он запускает exim для получения электронной почты для нескольких моих доменов.

Каждый из моих доменов имеет запись MX, указывающую на mx.example.com, которая разрешает 192.0.2.1

Если я хочу, чтобы exim предлагал шифрование TLS для входящих соединений электронной почты, какое имя хоста я должен указать в сертификате SSL?

• foo.example.com потому что это то, что сервер скажет в HELO?
• mx.example.com потому что это имя хоста, к которому будут подключаться клиенты?

http://www.checktls.com предполагает, что последний является правильным, но я не могу найти окончательный ответ.

На самом деле это нигде явно не определено, и то, должен ли сервер быть «доверенным», зависит от клиента (который может, конечно, быть другим почтовым сервером), подключающегося к нему; цитата из соответствующего RFC ( RFC 2487 ):

Если SMTP-клиент решает, что уровень аутентификации или
конфиденциальности недостаточно высок для продолжения, он ДОЛЖЕН выполнить команду
SMTP QUIT сразу после завершения согласования TLS.
Если SMTP-сервер решает, что уровень аутентификации или
конфиденциальности недостаточно высок для продолжения, он ДОЛЖЕН ответить на
каждую SMTP-команду от клиента (кроме команды QUIT) с
кодом ответа 554 (с возможной текстовой строкой, такой как как «Командование
отказалось из-за отсутствия безопасности»).

Решение о том, верить ли подлинности
другой стороны в переговорах TLS, является локальным вопросом. Тем не менее, некоторые
общие правила для решений:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

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

Но подождите, это еще не все. Цитирую снова из того же RFC:

После завершения квитирования TLS протокол SMTP сбрасывается
в исходное состояние (состояние в SMTP после того, как сервер выдает
приветствие 220 готовности к услуге). Сервер ДОЛЖЕН отбросить любые знания,
полученные от клиента, такие как аргумент команды EHLO,
который не был получен из самого согласования TLS. Клиент
ДОЛЖЕН отбросить любые знания, полученные от сервера, такие как список
расширений службы SMTP, который не был получен из самого
согласования TLS . Клиент ДОЛЖЕН отправить команду EHLO в качестве
первой команды после успешного согласования TLS.

Таким образом, то, что сервер говорит в ответ на HELO / EHLO до того, как квитирование TLS, кажется, на самом деле не имеет никакого значения.

По моему опыту, самозаверяющие сертификаты довольно хорошо работают на почтовых серверах с выходом в Интернет, а это означает, что другие почтовые серверы даже не удосуживаются их проверить, они просто с радостью примут все, что может обеспечить шифрование TLS, независимо от выдачи название органа или субъекта.

MTA, доставляющий почту на ваш домен, будет искать запись MX (которая даст имя хоста), а затем искать запись A для этого имени хоста. Следовательно, имя хоста, к которому он подключается, является именем хоста MX, и поэтому оно будет проверено по общему имени сертификата SSL. Проверка имени хоста HELO не имеет смысла, поскольку сервер может предоставить любое имя хоста HELO, которое он хочет, - он не обеспечивает дополнительную безопасность.

Тем не менее, строгая проверка SSL-сертификатов при доставке почты в настоящее время не особенно полезна, поскольку адаптеры MTA (почти всегда) возвращаются к доставке без поддержки SSL, поскольку именно так сейчас работает SMTP. Поэтому разумной конфигурацией является использование SSL, если сервер MX предлагает его, независимо от того, проверяется ли сертификат SSL или нет (поскольку шифрование без аутентификации лучше, чем без шифрования и без аутентификации). Поэтому вы можете также использовать самоподписанный сертификат для этой цели.

Задача проверки сертификата сервера и его соответствия имени хоста сервера является исключительно ролью клиента для любого протокола, использующего SSL / TLS.

Таким образом, имя хоста в сертификате должно совпадать с именем, к которому клиент пытается получить доступ.

Когда соединение SSL / TLS инициируется заранее (SMTPS), сервер не может увидеть, что говорится в сообщении HELO до установления соединения, поэтому он должен использовать тот, с которым он сделал запрос.

При использовании SSL / TLS после того STARTTLS, как клиент все еще собирается общаться с сервером, с которым он был настроен, это все еще то, что он должен проверить. В противном случае возможны атаки MITM:

• C-> S: Привет, я Алиса, я хочу поговорить с Бобом.
• S-> C: Привет, я Чак, вот мой сертификат для Чака.
• C-> S: О да, ваш сертификат действительно подходит для Чака. Давайте продолжим.
• ... Конечно, есть недостаток, так как Алиса хотела безопасного общения с Бобом.

В обоих случаях следует использовать адрес MX.

Правила сопоставления имен хостов были недавно собраны во всех протоколах в RFC 6125 , но лишь немногие клиенты реализуют его полностью (это скорее RFC, чем полное изменение, и это все еще довольно недавно).

В своем приложении он суммирует то, что существовало о SMTP раньше (взято из RFC 3207 и RFC 4954 ). В частности, « Клиент НЕ ДОЛЖЕН использовать какую-либо форму имени хоста сервера, полученного из незащищенного удаленного источника (например, небезопасного поиска DNS). » (Что, конечно, относится к баннеру сервера). Кроме того, устаревшие правила SMTP были немного более мягкими, чем HTTPS в отношении альтернативных имен субъектов (их следует использовать вместо обязательных ).

Современный способ - это однозначно поместить имя хоста в DNS-запись Subject Alternative Name. Использование подстановочных знаков также не рекомендуется .

Я думаю, что лучше всего будет скопировать то, что сделано на практике. Я проверил адрес электронной почты yahoo.com, используя http://checktls.com. Надеюсь, на Yahoo они использовали другой домен для своего имени хоста и для своего домена mx. Итак, их имя хоста - yahoo.com, а их домен mx оканчивается на yahoodns.net.

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Результат проверки: SSL-сертификат CN = MX домен (* .yahoodns.net)

Я сделал то же самое с Cisco, и у меня был тот же результат.

При шифровании SSL / TLS клиент всегда проверяет соответствие между «реальным» / «объявленным» именем хоста на удаленной машине и информацией, содержащейся в сертификате.

Итак, вам, вероятно, следует установить foo.example.com или сгенерировать групповой сертификат ;-)