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

На самом деле это нигде явно не определено, и то, должен ли сервер быть «доверенным», зависит от подключающегося к нему клиента (который, конечно, может быть другим почтовым сервером); цитата из соответствующего 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-запись альтернативного имени субъекта. Использование подстановочных знаков также не рекомендуется.

Думаю, что лучше всего будет скопировать то, что делается на практике. Я проверил адрес электронной почты 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 или создать сертификат с подстановочным знаком ;-)