Dovecot TLS: IMAPS/POP3S, SNI, cipher suites и проверка через openssl s_client

Почтовый сервер обычно «прощают» меньше всего: пользователи сразу видят предупреждения клиента, а корпоративные шлюзы и провайдеры быстро режут слабый TLS. В Dovecot (IMAP/POP3) важно не просто «включить SSL», а сделать это предсказуемо: правильные порты (IMAPS/POP3S и STARTTLS), корректная цепочка, понятные ограничения шифров и поддержка SNI для нескольких доменов.

Ниже — практичная шпаргалка по настройке TLS в Dovecot и проверке, где именно ломается IMAPS/POP3S: сертификат, цепочка, SNI, протоколы или ssl_cipher_list. В конце — готовые команды openssl s_client для диагностики.

Как Dovecot отдаёт TLS: IMAPS/POP3S и STARTTLS

В Dovecot TLS используется в двух основных сценариях:

• Нативный TLS на отдельном порту: IMAPS (обычно 993), POP3S (обычно 995). Клиент сразу открывает TLS-соединение.
• STARTTLS на «обычном» порту: IMAP 143, POP3 110. Клиент подключается в открытом виде и затем повышает соединение до TLS командой STARTTLS.

С точки зрения безопасности оба варианта могут быть нормальными, но на практике IMAPS/POP3S проще для поддержки пользователей и меньше зависит от сетевых фильтров. STARTTLS полезен для совместимости, но требует аккуратной политики (например, запрет логина без TLS).

Базовая настройка портов и запрета логина без TLS

Проверьте, какие протоколы включены, и какая политика TLS применяется в Dovecot. Конфигурация может быть разбита по файлам, но ключевые параметры обычно такие:

protocols = imap pop3 lmtp

# Для STARTTLS на 143/110: шифрование становится обязательным
disable_plaintext_auth = yes

# Требовать TLS для IMAP/POP3
ssl = required

Параметр ssl исторически может встречаться как ssl = yes или ssl = required. Для «почты по-взрослому» чаще выбирают required, чтобы исключить аутентификацию в открытом виде. Если у вас есть отдельный внутренний сегмент или TLS-терминация на прокси — продумайте исключения отдельно, но по умолчанию лучше принудительный TLS.

Сертификаты: файл, ключ и цепочка (самая частая причина ошибок)

Классическая причина проблем — не сам сертификат, а неправильная цепочка: клиент не может построить доверие к промежуточным центрам.

Для Dovecot важно:

• ssl_cert — сертификат сервера. В большинстве случаев это fullchain (сертификат + промежуточные).
• ssl_key — приватный ключ сервера.
• Права на ключ: доступен пользователю, под которым работает Dovecot, но не «всем подряд».

ssl_cert = </etc/ssl/mail/fullchain.pem
ssl_key = </etc/ssl/mail/privkey.pem

Обратите внимание на синтаксис с символом <: Dovecot читает содержимое файла. Это удобно и обычно рекомендуется.

Проверка, что ключ соответствует сертификату

Если вы случайно подложили не тот ключ, TLS не поднимется или будет вести себя нестабильно. Быстрая проверка через OpenSSL:

openssl x509 -noout -modulus -in /etc/ssl/mail/fullchain.pem | openssl md5
openssl pkey -noout -modulus -in /etc/ssl/mail/privkey.pem | openssl md5

Хэши должны совпадать. Если нет — ищите правильную пару ключ/сертификат.

Проверка цепочки (локально)

Если у вас есть файл с промежуточными и корневыми сертификатами CA (или вы используете системное хранилище), можно проверить цепочку так:

openssl verify -purpose sslserver -CAfile /etc/ssl/certs/ca-certificates.crt /etc/ssl/mail/fullchain.pem

Если проверка не проходит — клиенты могут ругаться на ошибки вида “unable to get local issuer certificate”, “unknown CA” и т.п.

Если вы выпускаете сертификаты под почтовые домены и хотите минимизировать проблемы совместимости, удобнее сразу брать полноценные SSL-сертификаты с корректной цепочкой и поддержкой нужных имён (SAN).

Чтобы не зависеть от «случайной» комплектации цепочки и получить предсказуемую поддержку имён (SAN) под почтовые хосты, удобно использовать коммерческие SSL-сертификаты и централизованно обновлять их по регламенту.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

SNI в Dovecot: несколько доменов и разные сертификаты

SNI нужен, когда один сервер обслуживает несколько доменов (например, mail.example.com и mail.example.org) и вы хотите отдавать корректный сертификат под каждое имя. Без SNI клиенты будут получать «дефолтный» сертификат, что приведёт к ошибкам несоответствия имени.

В Dovecot SNI настраивается через механизм local_name для SSL-настроек. Общая идея: задаём сертификат по умолчанию, а затем добавляем блоки для конкретных имён.

# Сертификат по умолчанию
ssl_cert = </etc/ssl/mail/default/fullchain.pem
ssl_key = </etc/ssl/mail/default/privkey.pem

local_name mail.example.com {
  ssl_cert = </etc/ssl/mail/example-com/fullchain.pem
  ssl_key = </etc/ssl/mail/example-com/privkey.pem
}

local_name mail.example.org {
  ssl_cert = </etc/ssl/mail/example-org/fullchain.pem
  ssl_key = </etc/ssl/mail/example-org/privkey.pem
}

Практическая рекомендация: держите «безопасный» сертификат по умолчанию, который хотя бы не просрочен и содержит админское имя хоста. Тогда даже старые клиенты без SNI получат валидный сертификат (пусть и не совпадающий по имени для всех доменов — это ожидаемое ограничение старых клиентов).

Если у клиента нет SNI, он не передаст имя хоста в TLS-рукопожатии, и Dovecot выберет сертификат по умолчанию. Это не баг: так устроен TLS без SNI.

Ограничение протоколов и выбор cipher suites: что реально нужно

Цель настройки cipher suites — не «сделать максимально длинный список», а исключить устаревшие протоколы и алгоритмы, сохранив предсказуемую совместимость. Помните: управление наборами шифров для TLS 1.3 и TLS 1.2 различается.

Минимальная версия протокола

Разумный минимум сегодня — запретить TLS 1.0 и 1.1. В Dovecot это делается параметром ssl_min_protocol:

ssl_min_protocol = TLSv1.2

Если у вас нет совсем древних клиентов, можно оставлять минимум TLS 1.2 и выше: TLS 1.3 включится автоматически при поддержке библиотекой OpenSSL и вашей сборкой Dovecot.

Наборы шифров для TLS 1.2

Для TLS 1.2 задаётся строка шифров через ssl_cipher_list. Типовой безопасный подход: ECDHE, AEAD (AES-GCM/CHACHA20-POLY1305), без статического RSA key exchange.

ssl_cipher_list = ECDHE+AESGCM:ECDHE+CHACHA20:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!SRP:!DSS

Точный оптимальный список зависит от вашей аудитории. Если у вас много Outlook на старых Windows, могут потребоваться послабления — но делайте это осознанно и проверяйте реальными тестами через openssl s_client и логи.

TLS 1.3 cipher suites

Для TLS 1.3 шифры задаются отдельно (зависит от версии Dovecot и OpenSSL). Если ваша версия поддерживает параметр ssl_cipher_suites, можно явно ограничить набор:

ssl_cipher_suites = TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256

Если параметра нет — управлять TLS 1.3-шифрами обычно нужно на уровне OpenSSL (и это зависит от сборки дистрибутива). В таком случае типовая практика: оставить TLS 1.3 по умолчанию, а строго контролировать TLS 1.2 через ssl_cipher_list.

Кривые ECDHE (если нужно)

Иногда требуется зафиксировать кривые (например, чтобы обеспечить X25519 и P-256). В Dovecot это настраивается параметром ssl_curve_list:

ssl_curve_list = X25519:P-256:P-384

Это полезно, если вы видите точечные проблемы совместимости на отдельных клиентах или хотите исключить редкие и медленные варианты.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Диагностика IMAPS/POP3S через openssl s_client

Когда почтовый клиент пишет «не удалось установить защищённое соединение», ваша задача — быстро понять, что именно ломается: SNI и имя, цепочка, протоколы или наборы шифров. openssl s_client позволяет воспроизвести TLS-рукопожатие почти как клиент, но прозрачно.

Проверка IMAPS (993) с SNI

openssl s_client -connect mail.example.com:993 -servername mail.example.com -showcerts

Смотрите на три вещи:

• какой сертификат отдан (CN и SAN должны подходить);
• есть ли промежуточные сертификаты в выводе -showcerts;
• строку Verify return code в конце.

Проверка POP3S (995) с SNI

openssl s_client -connect mail.example.com:995 -servername mail.example.com -showcerts

Проверка STARTTLS для IMAP (143)

openssl s_client -connect mail.example.com:143 -servername mail.example.com -starttls imap -showcerts

Проверка STARTTLS для POP3 (110)

openssl s_client -connect mail.example.com:110 -servername mail.example.com -starttls pop3 -showcerts

Принудительный тест конкретной версии TLS

Если подозреваете проблему по версии протокола, проверьте явно:

openssl s_client -connect mail.example.com:993 -servername mail.example.com -tls1_2
openssl s_client -connect mail.example.com:993 -servername mail.example.com -tls1_3

Тест конкретного шифра (для TLS 1.2)

Полезно, когда вы ужали ssl_cipher_list и хотите убедиться, что нужный шифр принимается сервером:

openssl s_client -connect mail.example.com:993 -servername mail.example.com -cipher ECDHE-RSA-AES128-GCM-SHA256

Если рукопожатие не состоялось, OpenSSL обычно пишет, что не удалось согласовать cipher suite.

Что делать с “Verify return code: 20/21”

Коды 20 и 21 чаще всего означают проблему с цепочкой доверия (не отдан intermediate, неверный порядок, клиент не знает CA). Проверьте:

• что ssl_cert указывает на fullchain, а не только на серверный сертификат;
• что в файле цепочки порядок корректный: серверный сертификат, затем промежуточные;
• что сертификат не просрочен и соответствует имени (SAN).

Типовые грабли в Dovecot TLS (и как быстро локализовать)

1) Клиент ругается на имя, но сертификат “валидный”

Почти всегда это одна из причин:

• клиент подключается по одному имени (например, imap.domain.tld), а сертификат выдан на другое (mail.domain.tld);
• SNI не сработал и отдаётся сертификат по умолчанию;
• в сертификате нет нужного SAN.

Воспроизведите подключение именно по тому имени, которое использует клиент, и обязательно добавьте -servername в openssl s_client.

2) IMAPS работает, STARTTLS нет (или наоборот)

Проверьте, что нужные сервисы слушают порты (firewall, listen-адреса), и что Dovecot разрешает STARTTLS для протокола. Для проверки STARTTLS используйте -starttls imap или -starttls pop3: без этого вы проверяете «сырой» порт, а не upgrade.

3) После ужесточения cipher suites часть клиентов отвалилась

Это ожидаемо, если у клиентов нет поддержки ECDHE или AEAD, либо они застряли на старых TLS-библиотеках. Практика: сначала включить информативное логирование TLS-ошибок, затем временно расширить ssl_cipher_list и сузить по фактическим данным. В качестве «страховки» от перебора паролей полезно настроить бан по логам, например через материал про fail2ban для Postfix и Dovecot.

4) Сервер «вроде отдаёт сертификат», но клиенты всё равно не доверяют

Очень частая причина — неправильный bundle промежуточных сертификатов, особенно после перевыпуска. Сравните то, что сервер реально отдаёт (вывод -showcerts), с тем, что вы ожидаете увидеть. Если в цепочке не хватает intermediate — исправляйте ssl_cert.

Мини-чеклист перед вводом в прод

1. Включены 993 и 995 и (при необходимости) STARTTLS на 143 и 110, а disable_plaintext_auth не позволяет логин без TLS.
2. ssl_cert указывает на fullchain, ssl_key — на корректный ключ с правильными правами.
3. Для multi-domain настроен SNI через local_name, есть безопасный сертификат по умолчанию.
4. ssl_min_protocol не ниже TLS 1.2.
5. Список ssl_cipher_list соответствует вашей клиентской базе; для TLS 1.3 (если нужно) задан ssl_cipher_suites.
6. Проверено через openssl s_client для IMAPS/POP3S и STARTTLS с -servername.

Заключение

Надёжный TLS в Dovecot — это не один параметр, а связка: правильная цепочка, корректное имя (и SNI при необходимости), адекватные версии протоколов и управляемые cipher suites. А openssl s_client — самый быстрый способ превратить «не работает у пользователя» в конкретную причину на стороне сервера.

Если вы планируете переносить ящики или менять хранилище, учтите, что на миграциях часто «всплывают» разные имена хостов и устаревшие настройки клиентов. В таком случае пригодится план работ из материала про миграцию IMAP без простоя через imapsync.

Для инфраструктуры, где почтовые сервисы изолированы на отдельной машине, удобнее держать Dovecot на VDS, чтобы гибко управлять TLS-политикой, обновлениями и логированием.