Как проверить сертификат и TLS, если Outlook не подключается

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

Сверьте имя сервера с сертификатом

При TLS сервер предъявляет сертификат, а почтовый клиент сопоставляет его с адресом сервера из настроек и проверяет доверие к издателю и срок действия. Если сертификат выпущен для другого имени, просрочен или ведёт к центру сертификации, которому клиент не доверяет, шифрование само по себе не спасает: подключение может быть отвергнуто. Для настройки и сопровождения корпоративной почты я начинаю с этой простой сверки, а не с переустановки Outlook. Срок проверяйте также с учётом часов на рабочем компьютере: неверная дата или время мешают корректно оценить период действия сертификата. Для входящей почты и отправки могут быть заданы разные адреса серверов, поэтому сверяйте сертификат отдельно для каждого подключения.

В условном примере сети «Шафран» в настройках Outlook указан mail.example.com, а сервер по ошибке отдаёт сертификат для mx.example.com. Оба имени могут вести на один адрес, но это не делает их взаимозаменяемыми для проверки личности. Современные правила идентификации DNS-имени опираются на поле subjectAltName с типом dNSName; полагаться на Common Name как на запасной вариант не следует. Сверьте точное имя узла, который указал почтовый администратор, с именами в сертификате. Сравнивайте не адрес после знака @, а имя узла, указанное отдельно в настройках входящей или исходящей почты. Даже если оба имени принадлежат одной организации и ведут на один сервер, каждый из них должен быть допустим по сертификату, который выдан при конкретном соединении.

Самоподписанный сертификат не означает, что TLS технически невозможен: его можно явно доверить на управляемых устройствах, если имя и срок в порядке. Но раздавать такой сертификат на каждый рабочий компьютер вручную — хрупкий способ сопровождения. Для внешнего сервиса обычно проще сертификат от доверенного центра. Если на одном сервере обслуживается несколько имён, отдельно проверьте, какой сертификат выдаётся для нужного имени; про эту часть подробнее рассказываю в разборе сертификатов для нескольких доменов.

Сопоставьте порт и режим TLS

Порт — это не косметическая настройка. Для SMTP submission стандартно используют 587 с переходом в TLS через STARTTLS; порт 465 применяют для SMTP с TLS с самого начала соединения. Порт 25 обычно обслуживает обмен между почтовыми серверами, однако стандарт допускает и отдельные сценарии отправки через него. Поэтому фраза «Outlook обязан ходить только на 587» неверна: используйте адрес, порт и режим шифрования, которые указал владелец почтового сервера. Для IMAP тоже различайте режимы: обычно 143 с STARTTLS или 993 с TLS сразу. Настройки зависят от сервиса; Microsoft, например, публикует для своих ящиков конкретные значения, а не универсальную таблицу для всех серверов. При 465 TLS начинается сразу; если выбрать STARTTLS, клиент ждёт SMTP-ответ не в том состоянии. И наоборот, при немедленном TLS на порту, где сервер сначала ждёт обычный SMTP-запрос, стороны не договорятся о начале сеанса. Номер порта сам по себе не включает шифрование: клиент и сервер должны одинаково понимать первый шаг соединения.

В Postfix проверьте не только main.cf, но и то, какой сервис реально слушает выбранный порт: параметры submission могут отличаться от настроек публичного SMTP-приёма. smtpd_tls_security_level = may объявляет TLS доступным, но не требует его от каждого соединения; значение encrypt требует TLS на этом сервисе. Не копируйте encrypt на публичный порт приёма писем без понимания последствий: так можно отвергать легитимные серверы, которые доставляют почту без обязательного TLS. Для клиентской отправки и межсерверного приёма правила не всегда одинаковы.

Для первичной проверки подключитесь к тому же имени и порту, что указаны в Outlook, и попросите SMTP-переход STARTTLS. Команда покажет ответ сервера, результат рукопожатия и отправленные сервером сертификаты; она не проверит пароль Outlook и не проверит IMAP. Если соединение закрывается до TLS-рукопожатия, смотрите соответствующий listener, firewall и серверный журнал. Если рукопожатие проходит, но Outlook не работает, переходите к проверке имени, доверия и аутентификации. Сравните результат из той же сети, где работает Outlook: тест с домашнего подключения не показывает, что происходит через офисный firewall или корпоративный DNS. Тайм-аут, отказ TCP-соединения и обрыв во время TLS — разные наблюдения; зафиксируйте их отдельно, прежде чем менять параметры Postfix.

• Сверьте сервер и порт с настройками провайдера.
• Для 587 выберите STARTTLS, если так требует сервер.
• Для 465 выберите TLS до начала SMTP.
• Для IMAP не путайте 143 и 993.
• Не меняйте публичный порт 25 наугад.

Отделите TLS от входа в почту

TLS защищает канал и помогает клиенту проверить сервер. Вход в почтовый ящик — отдельный этап. При отправке Outlook обычно использует SMTP-аутентификацию, а конкретный способ входа задаёт почтовая система: пароль, OAuth или её собственная политика. Поэтому успешное рукопожатие не подтверждает, что включён SMTP AUTH, принят логин или разрешена отправка с этого ящика. Если TLS установился, а отправка всё равно не проходит, проверьте аутентификацию и ответ SMTP отдельно. В настройках Outlook проверяйте, включена ли аутентификация исходящего SMTP и какой способ входа требует сервер. Некоторые системы используют разные правила для IMAP-входа и SMTP-отправки. Неверный пароль, выключенный SMTP AUTH или ограничение провайдера не исправляются заменой сертификата.

В Postfix параметр smtpd_tls_auth_only = yes означает: не объявлять и не принимать SASL-аутентификацию на незашифрованном соединении, если TLS в целом необязателен. Он не включает TLS и не исправляет сертификат. В Postfix SMTP AUTH тоже не активируется автоматически: smtpd_sasl_auth_enable по умолчанию имеет значение no. Если сервис отправки требует SMTP AUTH, проверьте серверную настройку SASL. Посмотреть активные значения можно командой postconf smtpd_tls_security_level smtpd_tls_auth_only smtpd_tls_ask_ccert smtpd_tls_req_ccert smtpd_sasl_auth_enable. Сначала снимите показания, затем меняйте конфигурацию. Иначе можно долго чинить не тот слой — любимый спорт почтового сервера.

Отдельная взаимная TLS-аутентификация нужна только если её сознательно внедрили. По документации Postfix smtpd_tls_ask_ccert по умолчанию имеет значение no; при yes сервер запрашивает сертификат SMTP-клиента. Сам запрос не равен обязательному требованию: для требования есть отдельный smtpd_tls_req_ccert. Обычный профиль Outlook не следует настраивать с клиентским сертификатом без явного требования администратора. Если в журнале есть ошибка проверки клиентского сертификата, ищите именно включённую политику mTLS, а не объясняйте ею любое сообщение о недоверии к серверному сертификату. Не включайте обязательный клиентский сертификат как пробный способ «усилить TLS» на рабочем submission-сервисе. Сначала подтвердите, что инфраструктура выдаёт сертификаты пользователям, что клиент умеет их предъявлять, а Postfix доверяет нужному центру. Иначе изменения затронут всю группу клиентов, а причина исходного отказа останется.

Проверьте всю цепочку сертификата

Клиенту нужен не только листовой сертификат сервера, но и возможность построить путь до корня, которому он доверяет. Сервер обычно отправляет листовой сертификат и необходимые промежуточные сертификаты; доверенный корневой сертификат чаще уже находится в хранилище клиента. Если промежуточного звена не хватает или клиенту не известен корень частного центра, проверка может завершиться ошибкой. Не угадывайте по тому, что «в браузере открывается»: у разных программ и операционных систем могут быть разные хранилища доверия и поведение при проверке. В цепочке полезно проверить issuer каждого звена: сертификат сервера должен вести к промежуточному CA, а тот — к корню, которому доверяет клиент. Серверная настройка отвечает за то, какие звенья он отправит; хранилище клиента — за то, как он завершит путь доверия. Это две связанные проверки, но исправляются они в разных местах.

Для проверки отправляемой цепочки запустите OpenSSL с проверкой доверия и имени узла. В примере ниже домен замените на адрес именно почтового сервера. Команда проверяет SMTP STARTTLS; для IMAP нужен соответствующий протокол и порт, а хранилище доверенных CA у OpenSSL может отличаться от хранилища Windows, которым пользуется Outlook. Поэтому результат помогает локализовать причину, но не является точной копией проверки в Outlook.

openssl s_client -connect mail.example.com:587 -starttls smtp -servername mail.example.com -showcerts -verify 5 -verify_hostname mail.example.com -verify_return_error

В сборках, использующих Let's Encrypt, файл fullchain.pem обычно содержит сертификат узла и промежуточную цепочку, но фактический путь и способ подключения зависят от почтовой платформы. Не меняйте имя файла по статье, пока не проверили действующие параметры и права доступа к ключу. После обновления сертификата проверьте, что сервис начал отдавать новый экземпляр, а не просто перезапустился без ошибки. Отдельный сценарий продления сертификата и сбоя IMAP разобран в статье про необновившийся сертификат IMAP. После замены проверьте срок действия и имя уже выданного по сети сертификата, а затем посмотрите журнал нужной службы. Если SMTP и IMAP обслуживают разные процессы или контейнеры, обновление одного из них не гарантирует обновление второго. Именно поэтому я отдельно проверяю оба endpoint, а не ограничиваюсь чтением имени файла на диске.

Сверьте поддержку версий TLS

Для почтовых протоколов ориентир сейчас — TLS 1.2 или новее: IETF обновила рекомендацию для доступа и отправки почты, установив TLS 1.2 как минимальную версию. Это не значит, что любая сборка Outlook предъявляет одинаковое требование к любому серверу: клиентская программа, Windows, TLS-библиотека и конкретный почтовый сервис участвуют в согласовании. TLS 1.3 полезен, если его поддерживают обе стороны, но он не является обязательной целью для каждого Outlook-подключения. Рекомендация относится к согласованию TLS для почтового клиента и сервера; она не сообщает, какую версию поддерживает конкретный старый компьютер. Если клиент или операционная система не предлагают совместимую версию, сервер не сможет договориться о сеансе даже с исправным сертификатом. Версию, реально выбранную в соединении, проверяйте на обеих сторонах, а не выводите по названию Outlook.

Не переносите настройку ssl_protocols из другой программы в Postfix: у Postfix собственные параметры smtpd_tls_protocols и smtpd_tls_mandatory_protocols, а значение зависит от версии и режима TLS. Сначала зафиксируйте версию Postfix и текущие значения, сопоставьте их с документацией именно для установленной версии, затем планируйте изменение и проверку. TLS 1.0 и 1.1 устарели для почтового доступа, но отключать протоколы сразу на всех службах без проверки старых клиентов — способ получить вторую аварию вместо первой. В документации Postfix есть отдельные параметры для протоколов обычного и обязательного TLS; при выборе учитываются режим smtpd_tls_security_level и установленная версия Postfix. Сначала смотрите фактические значения через postconf и документацию этого релиза. Слепо вставить строку с TLS 1.2 или TLS 1.3 — плохая замена проверке совместимости и синтаксиса. Есть и узкий платформенный случай: Microsoft указывает, что Office-клиент на Windows 7 не получает TLS 1.1 и 1.2 для связи с сервисами Microsoft 365 через WinHTTP без обновления KB3140245. Это относится именно к этой связке Office, Windows и Microsoft 365; такой факт нельзя автоматически переносить на подключение к произвольному IMAP- или SMTP-серверу.

Если проблема появилась после обновления, отдельно выясните, что изменилось на сервере и рабочем месте: версия Outlook, Windows, Postfix, библиотеки TLS или сам профиль. У Postfix есть отдельный случай, где совместимость старого Outlook затрагивала TLS 1.3; это другая задача, чем несовпадение имени сертификата или порта, и она разобрана в статье про Postfix 3.9 и старый Outlook. Если сертификат, порт и согласованная версия TLS в порядке, а профиль по-прежнему не находит сервер, проверьте Autodiscover отдельно — этому посвящён материал про Outlook и Autodiscover.

• Зафиксируйте версии Outlook, Windows и Postfix.
• Проверьте согласованный протокол на клиенте и сервере.
• Не переносите ssl_protocols в main.cf.
• Меняйте TLS-параметры по документации своей версии.

Частые вопросы