TLS електронної пошти: чому «дійсний сертифікат» усе ще не працює (і справжнє рішення)

Що насправді означає «дійсний сертифікат» у світі SMTP

Коли хтось каже «сертифікат дійсний», зазвичай мають на увазі: підпис листового сертифіката підтверджується, він не прострочений,
і він ланцюжиться до довіреного кореня в якомусь клієнті. Це базова вимога. SMTP додає способи бути неправильним.

В електронній пошті TLS-ідентичність сервера прив’язана до DNS-імен, поведінки MX і політик. Деякі клієнти суворо перевіряють імена хостів.
Деякі — ні. Деякі звертають увагу на SNI. Деякі не вміють SNI. Деякі застосовують сучасні шифри. Деякі застрягли в 2012 році, але все ще доставляють пошту для банку.
«Дійсний» — це спектр, і приймаюча MTA вирішує, де провести межу.

Цікаві факти та історичний контекст (коротко, конкретно, корисно)

• STARTTLS для SMTP стандартизовано у 2002 році (RFC 3207). Він задумувався як опортуністичне підвищення, а не суворе застосування.
• SMTP спочатку відправлявся без шифрування, бо ранній інтернет припускав співпрацю; шифрування було додане пізніше.
• «Опортуністичний TLS» став нормою на роки: зашифровувати якщо можливо, інакше відкотитися. Добре для доставлюваності, посередньо для конфіденційності.
• Перевірки імен сертифікатів історично були непослідовними між різними MTA. Саме через це «працює з Gmail» не є тестом сертифіката.
• SNI з’явився пізніше за багато SMTP-стеків. Деякі старі MTA досі не надсилають SNI, що важливо для багатоквартирних серверів.
• Perfect Forward Secrecy увійшов у масову практику після 2013 року. Старі налаштування шифрів можуть й досі ламати взаємодію, якщо одна сторона занадто агресивно вимикає «легасі».
• MTA-STS відносно новий (RFC 8461, 2018) і змістив частину email TLS з «найкраща спроба» до «політично керованого» примусу.
• DANE для SMTP існує (TLSA записи, RFC 7672) і може забезпечувати TLS без публічних ЦС — чудово, поки DNSSEC не розгорнуто наскрізно.
• Багато MTA досі трактують порт 465 як «SMTPS» для submission-стилю використання, тоді як порт 25 залишається орієнтований на STARTTLS для сервер‑до‑сервера.

Тут є фундаментальне невідповідність: веб — це «клієнт до одного імені сервера», тоді як SMTP — це «сервер до того, що поверне MX у DNS, можливо багато імен,
можливо змінюваних, можливо за балансувальниками навантаження». Сертифікати не люблять неоднозначності. SMTP любить її.

Одне висловлення варте запам’ятовування під час налагодження: На надії далеко не заїдеш. (парафраз ідеї з культури операцій, широко використовуваний в SRE і менеджменті проектів)

«Дійсний» — це те, що приймає віддалена сторона. Ваше завдання — передбачити, що прийме різноманіття віддалих сторін, а потім налаштувати систему відповідно.

Швидкий план діагностики (перевірте це, потім те)

Коли TLS у пошті ламається, ви можете втратити години на інтуїтивну налагоджувальну роботу. Не робіть так. Виконуйте це в порядку, і ви зазвичай швидко знайдете вузьке місце.

1. По-перше: підтвердьте, яке ім’я перевіряють.
   • Ви підключаєтесь до mx1.example.com, mail.example.com чи до голого домену?
   • Чи покриває сертифікат це точне ім’я через SAN?
   • Ви за балансувальником навантаження або проксі, який змінює TLS-ендпоінт?
2. По-друге: зафіксуйте реальний рукопотиск, який бачить віддалена MTA.
   • Використовуйте openssl s_client зі STARTTLS і (за потреби) SNI.
   • Перевірте, який ланцюжок подається: leaf + проміжні, у правильному порядку.
3. По-третє: прочитайте журнали вашої MTA на предмет політик.
   • Чи віддалений бік застосовує MTA-STS, DANE або «TLS обов’язковий» для submission?
   • Чи ваша сторона вимагає перевірок імен хостів або мінімальних версій TLS?
4. По-четверте: перевірте збіг протоколів і шифрів.
   • TLSv1.2 — мінімум для багатьох сучасних MTA; TLSv1.0/1.1 дедалі частіше відкидають.
   • Але відключення всього, крім TLSv1.3, також може нашкодити, якщо peer старий.
5. По-п’яте: виключіть «це фаєрвол» з доказами.
   • Підтвердіть порти, NAT і будь‑які пристрої перехоплення/інспекції TLS.
   • Перевірте MTU/фрагментацію, якщо бачите дивні зависання під час рукопотиску.

Жарт №1: Налагодження TLS для пошти схоже на детективний роман, де лиходій завжди — «один відсутній проміжний», що кожну главу одягається в новий капелюх.

Чому TLS ламається навіть при дійсному сертифікаті

1) Невідповідність імені хоста: сертифікат дійсний, але не для того MX-імені

Це найпоширеніша проблема «але ж він дійсний!». Сертифікат може бути дійсним для mail.example.com,
тоді як відправна MTA підключається до mx1.example.com. Або вона підключається до домену в записі MX, який вказує на
провайдера, про існування якого ви забули. Ланцюжок може бути в порядку; ідентичність — ні.

SMTP додає тонкість: багато MTA перевіряють ім’я, до якого вони підключилися (ціль MX), а не те, що сервер каже в SMTP‑банері.
Банер може бути чесним, але все одно не релевантним.

Виправлення: додайте імена хостів MX до SAN сертифіката або змініть MX на ім’я, яким ви керуєте і яке ви можете сертифікувати.
«Працює в моєму браузері» не має значення, якщо ваш браузер ніколи не підключається до імені MX.

2) Відсутній проміжний сертифікат: браузери підтягують, MTA часто ні

Сучасні браузери надзвичайно поблажливі. Вони кешують проміжні сертифікати, підтягують їх через AIA і закривають очі на недбалу конфігурацію сервера.
Багато MTA за дизайном не виконують AIA-підвантаження. Вони очікують, що сервер подасть повний ланцюжок.

Ось чому сертифікат може перевірятись на вашому ноутбуку і падати при доставці пошти в продакшені.
Віддалена MTA може працювати на старішому OpenSSL у контейнері з мінімальним сховищем довірених сертифікатів і без AIA.
Вона бачить листовий сертифікат, не може побудувати ланцюжок і відкидає його.

Виправлення: налаштуйте вашу MTA так, щоб вона подавала листовий сертифікат плюс проміжні у правильному порядку. Не включайте корінь.

3) SNI і багатоарендність: ви отримали «сертифікат за замовчуванням»

Якщо кілька доменів ділять IP, сервер повинен використовувати SNI, щоб обрати правильний сертифікат. Багато SMTP-клієнтів тепер відправляють SNI,
але не всі. Деякі старі MTA підключаться без SNI і отримають сертифікат за замовчуванням, який може бути дійсним, але не для вас.

Весела частина: це може бути переривчасто. Деякі відправники пройдуть (вони надсилають SNI), інші впадуть (вони не надсилають). Ви отримаєте привид у журналах.

Виправлення: зробіть сертифікат за замовчуванням таким, що безпечно покриває основне MX-ім’я, або виділіть IP для пошти, коли можливо.
Якщо ви змушені використовувати багатоарендність, тестуйте з SNI і без нього.

4) Несумісність версій TLS і наборів шифрів: «модернізація» може означати «зламати пошту»

Команди безпеки люблять гайди з жорсткої політики. SRE любить не отримувати тривогу о 2:00 ночі. Ці уподобання не завжди узгоджуються.
Якщо ви вимкнете TLSv1.2 або приберете загальні шифри, ви можете відрізати старі, але ще легітимні відправники.

З іншого боку, якщо віддалений наполягає на TLSv1.2+ і ваш стек застряг на TLSv1.0, то ви — «легасі».
Це проявиться у відмовах рукопотиску, повідомленнях про версію протоколу або помилках узгодження шифрів.

Виправлення: тримайте TLSv1.2 увімкненим на SMTP-серверах. TLSv1.3 — чудово, але не припускайте універсальної підтримки.
Вимикайте відомі вразливі шифри, але зберігайте розумний набір перетину.

5) Плутанина політик STARTTLS: опортуністичний проти обов’язкового

STARTTLS задумувався як опортуністичний. Це означає: якщо шифрування не відбулося, пошта все ще може бути доставлена відкритим текстом.
Але кілька механізмів можуть змінити цю поведінку:

• Submission (587) часто вимагає TLS, бо передаються облікові дані користувача.
• Транспорт партнер‑до‑партнера може вимагати TLS через політику або налаштування конектора.
• MTA-STS каже відправникам: «Доставляйте мені лише по валідному TLS, або не доставляйте взагалі».
• DANE може вимагати TLS на рівні DNS (коли DNSSEC валідується).

Тому у вас може бути «дійсний» сертифікат, який все одно не пройде, бо політика вимагає перевірку імені хоста, або конкретного імені,
або конкретного ланцюжка, а не лише шифрування.

6) Некоректний EHLO/HELO ім’я та зворотний DNS: не TLS, але часто плутають з TLS

Ця помилка забирає час, бо стоїть поруч із помилками TLS у логах. Деякі MTA відмовляють або карають
з’єднання з поганим rDNS, неузгодженим HELO іменем або загальними банерами. Це може виглядати як «проблема TLS»,
коли насправді це питання репутації/ідентичності.

Виправлення: узгодьте PTR (зворотний DNS), прямі A/AAAA записи та ім’я HELO, яке використовує ваш сервер. Це не виправить зламаний ланцюг,
але зменшить шум у логах під час виправлення TLS.

7) Проміжні пристрої: інспекція TLS, NAT і «допоміжні» фаєрволи

STARTTLS особливо часто тригерить корпоративні middlebox’и, які думають, що все має виглядати як HTTPS.
Деякі пристрої пошкоджують переговори STARTTLS, обрізають розширення або скидають з’єднання при незнайомих рукопотисканнях.

Виправлення: обходьте інспекцію TLS для SMTP або використовуйте маршрути, які не проходять через пристрій інспекції.
Якщо не можете — готуйтеся до страждань і документуйте кожне додане виключення.

8) Неправильний формат сертифіката / невідповідність ключа / права доступу: базова, але реальна

Сертифікат може бути дійсним і одночасно не завантажуватися. Postfix, Exim та інші поведуться по‑різному — впадуть у відкритий або закритий стан залежно від конфігурації.
Якщо ваш сервіс відкотиться до відкритого режиму або підставить сертифікат за замовчуванням, бо не може прочитати потрібний, ви отримаєте заплутані симптоми.

Виправлення: переконайтесь, що працююча служба дійсно використовує той файл, який ви думаєте, і що ключ співпадає.

9) DANE і MTA-STS: коли правила змінюються під вашими ногами

DANE з DNSSEC дозволяє використовувати самопідписані або приватні CA, якщо TLSA-запис збігається. Це потужно — і крихко.
Поміняли сертифікат і забули оновити TLSA? Ви самі собі створили відмову.

MTA-STS інше: він усе ще покладається на публічну PKI, але примушує «дійсний сертифікат» і «правильне ім’я» так, як опортуністичний TLS не робить.
Якщо ви опублікували політику MTA-STS, а ваші MX-ендпоінти не послідовні, ви побачите раптові відмови доставки від відправників, які її виконують.

Практичні завдання: команди, виводи, рішення (12+)

Це перевірки для продакшену. Це не теорія. Виконуйте їх, читайте вивід, вирішуйте наступний крок.
Команди припускають Linux‑сервер з типовим набором інструментів.

Завдання 1: Подивіться, який сертифікат насправді представляє ваш SMTP-сервер (STARTTLS на 25)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts -verify_return_error
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R11
verify return:1
depth=0 CN=mail.example.com
verify return:1
---
Certificate chain
 0 s:CN=mail.example.com
   i:C=US, O=Let's Encrypt, CN=R11
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:C=US, O=Let's Encrypt, CN=R11
   i:C=US, O=Internet Security Research Group, CN=ISRG Root X1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
...

Що це означає: CN листового сертифіката — mail.example.com, але ви підключилися до mx1.example.com.
Якщо SAN не містить mx1.example.com, суворі відправники відкинуть з’єднання.

Рішення: Перевипустіть сертифікат, що містить імена MX у SAN, або змініть MX, щоб відповідати сертифікату.

Завдання 2: Явно перевірте покриття SAN

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com 

cr0x@server:~$ openssl x509 -noout -text | sed -n '/Subject:/,/X509v3 Subject Alternative Name:/p'
Subject: CN = mail.example.com
            X509v3 Subject Alternative Name:
                DNS:mail.example.com, DNS:smtp.example.com

Що це означає: mx1.example.com у SAN немає. CN сам по собі ненадійний, і сучасна валідація все одно використовує SAN.

Рішення: Додайте mx1.example.com (та інші цільові MX) у SAN під час випуску.

Завдання 3: Перевірте відсутність проміжних (повнота ланцюжка)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++}{print > ("cert" i ".pem")}'
cr0x@server:~$ for f in cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer -in "$f"; done
== cert1.pem ==
subject=CN = mail.example.com
issuer=C = US, O = Let's Encrypt, CN = R11
== cert2.pem ==
subject=C = US, O = Let's Encrypt, CN = R11
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

Що це означає: Сервер подав листовий сертифікат + проміжний. Добре. Якби ви бачили лише cert1.pem,
багато MTA не змогли б побудувати ланцюжок.

Рішення: Якщо проміжний відсутній, виправте smtpd_tls_cert_file (Postfix) або еквівалент, щоб включити fullchain.

Завдання 4: Переконайтесь, що приватний ключ відповідає листовому сертифікату

cr0x@server:~$ openssl x509 -noout -modulus -in /etc/ssl/mail/fullchain.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10
cr0x@server:~$ openssl rsa -noout -modulus -in /etc/ssl/mail/privkey.pem | openssl md5
MD5(stdin)= 6f0c9a7d5b0c0b3f4b6a7e3c2d1a9e10

Що це означає: Хеші модулів збігаються: ключ і сертифікат належать один одному.
Якби ні — ваша MTA могла б не включити TLS або показати інший сертифікат.

Рішення: Якщо є невідповідність, розгорніть правильну пару ключ/сертифікат і перезавантажте сервіс.

Завдання 5: Підтвердіть, що Postfix налаштований і чи увімкнено TLS

cr0x@server:~$ postconf -n | egrep 'smtpd_tls_|smtp_tls_|myhostname|mydomain'
myhostname = mx1.example.com
smtpd_tls_cert_file = /etc/ssl/mail/fullchain.pem
smtpd_tls_key_file = /etc/ssl/mail/privkey.pem
smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Що це означає: Вхідний та вихідний TLS опортуністичні (may), і рівень логування невисокий, але ненульовий.

Рішення: Якщо ви намагаєтеся задовольнити вимогу партнера про примусовий TLS, можливо, потрібні політики на рівні домену, а не глобальне encrypt.

Завдання 6: Перетворіть логи на докази (деталі логів TLS у Postfix)

cr0x@server:~$ sudo postconf -e 'smtpd_tls_loglevel=2' 'smtp_tls_loglevel=2'
cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo tail -n 30 /var/log/mail.log
Feb  4 12:10:21 mx1 postfix/smtpd[22110]: Anonymous TLS connection established from mail-oi1-f169.google.com[209.85.167.169]: TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
Feb  4 12:10:44 mx1 postfix/smtpd[22110]: warning: TLS library problem: error:0A000086:SSL routines::certificate verify failed: TLS alert unknown ca

Що це означає: Перший рядок: успіх з сучасним відправником. Другий: інший peer провалив перевірку (або ваш сервер не пройшов перевірку їхнього сертифіката, залежно від напрямку).

Рішення: Якщо відмови — вхідні й ви не вимагаєте клієнтських сертифікатів, переконайтесь, що ви не помилково налаштовані на перевірку клієнтів. Якщо вихідні — перевірте ваше сховище довіри.

Завдання 7: Визначте, чи змінює SNI сертифікат, що подається

cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = default.invalid
cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.25:25 -servername mx1.example.com -showcerts 2>/dev/null | openssl x509 -noout -subject
subject=CN = mx1.example.com

Що це означає: Без SNI ви отримуєте сертифікат за замовчуванням (default.invalid), з SNI — правильний (mx1.example.com).

Рішення: Якщо ви не можете виділити IP, встановіть сертифікат за замовчуванням прийнятним для вашого основного MX і протестуйте з клієнтом без SNI.

Завдання 8: Перевірте перекриття протоколів (примусити версії TLS)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_2 -servername mx1.example.com 

cr0x@server:~$ openssl s_client -starttls smtp -connect mx1.example.com:25 -tls1_1 -servername mx1.example.com
...
ssl3_read_bytes:tlsv1 alert protocol version
...

Що це означає: TLS 1.2 працює; TLS 1.1 відкидається. Це добра гігієна у 2026 році.
Якщо ваш peer підтримує лише TLS 1.1 — вони падатимуть.

Рішення: Тримайте TLS 1.2 увімкненим. Питання підтримки legacy вирішуйте індивідуально (зазвичай не для публічних MX).

Завдання 9: Підтвердіть, які шифри пропонує ваш сервер (з боку сервера)

cr0x@server:~$ sudo postconf -n | egrep 'smtpd_tls_mandatory_protocols|smtpd_tls_protocols|smtpd_tls_mandatory_ciphers|tls_high_cipherlist'
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_ciphers = high

Що це означає: Обов’язкові протоколи — TLSv1.2+. Опортуністичний режим все ще дозволяє більше, якщо явно не обмежено.
«high» — неточно; залежить від OpenSSL.

Рішення: Якщо виникають проблеми з сумісністю, явно задайте сучасний, але сумісний список шифрів, а не покладайтеся на «high».

Завдання 10: Перевірте записи MX і подивіться, до яких імен фактично підключається світ

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.
cr0x@server:~$ dig +short A mx1.example.com
203.0.113.25
cr0x@server:~$ dig +short AAAA mx1.example.com
2001:db8:25::25

Що це означає: Це імена хостів, які мають бути покриті сертифікатами (або щонайменше подавати коректні сертифікати за замовчуванням).

Рішення: Переконайтеся, що кожна ціль MX має сертифікат, чиї SAN включають це точне ім’я, для IPv4 і IPv6 ендпоінтів.

Завдання 11: Перевірте відповідність зворотного DNS (зменшує «TLS‑подібні» проблеми доставки)

cr0x@server:~$ dig +short -x 203.0.113.25
mx1.example.com.
cr0x@server:~$ hostname -f
mx1.example.com

Що це означає: PTR співпадає з вашим FQDN. Багато приймачів це цінують. Деякі вимагають для скорингу репутації.

Рішення: Якщо PTR неправильний — виправляйте його у вашого провайдера IP. Не ганяйтеся за TLS-привидами, поки базова ідентичність не узгоджена.

Завдання 12: Перевірте статус MTA-STS у DNS (чи ви вимагаєте суворий TLS?)

cr0x@server:~$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=2024020401"
cr0x@server:~$ dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Що це означає: Ви публікуєте MTA-STS і TLS‑репорти. Відправники, які дотримуються STS, тепер можуть вимагати перевірку сертифікатів і імен.

Рішення: Якщо ви ще не готові до суворості — не публікуйте MTA-STS. Якщо готові — переконайтеся, що імена MX і сертифікати послідовні всюди.

Завдання 13: Подивіться TLSRPT (якщо ви збираєте звіти), щоб побачити, хто падає і чому

cr0x@server:~$ sudo grep -R "sts-policy" -n /var/mail/tlsrpt/ | head
/var/mail/tlsrpt/report-2026-02-04.json:42:    "result_type": "sts-policy-invalid"
/var/mail/tlsrpt/report-2026-02-04.json:43:    "sending_mta_ip": "198.51.100.10"

Що це означає: Деякі відправники падають через проблеми з STS-політикою, а не через просту механіку TLS.

Рішення: Виправте публікацію STS і узгодженість, або тимчасово пом’якшіть режим політики, щоб уникнути жорстких збоїв під час переходу.

Завдання 14: Переконайтесь, що служба слухає і рекламує STARTTLS

cr0x@server:~$ nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
cr0x@server:~$ printf "EHLO test.example\r\nQUIT\r\n" | nc -v mx1.example.com 25
Connection to mx1.example.com 25 port [tcp/smtp] succeeded!
220 mx1.example.com ESMTP Postfix
250-mx1.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME

Що це означає: STARTTLS пропонується. Якщо його немає, відправники не зможуть оновити з’єднання — навіть якщо у вас гарний сертифікат.

Рішення: Якщо STARTTLS відсутній, виправте увімкнення TLS у MTA, переконайтесь, що сертифікат/ключ читаються MTA, і що проксі не обрізає розширення.

Три короткі історії з корпоративного життя

Коротка історія 1: Аутейж через хибне припущення (перевірка імен)

Середня SaaS‑компанія перемістила вхідну пошту на новий кластер. Команда зробила «дорослий» крок:
нові IP, нові MX записи і блискучий сертифікат від публічної ЦС. Вони протестували з кількома зовнішніми акаунтами,
спостерігали потік пошти і оголосили перемогу.

Потім фаєрвол великого клієнта почав відкладати повідомлення з причиною TLS. Не відхиляти — відкладати.
Це гірше: накопичується і стає проблемою наступного дня, саме тоді, коли вам хотілося поспати.

Сертифікат компанії був дійсним для mail.example.com. Їхні MX записи вказували на mx1.example.com та mx2.example.com.
Вони припустили, що CN покриє це («чого ще чекати від сертифікатів?»), і що відправні MTA перевіряють проти банера сервера.
Шлюз клієнта перевіряв проти імені MX, до якого він підключався. Строго. Правильно.

Виправлення було нудним: перевипустити сертифікат із SAN, що містить обидва MX і ім’я для submission,
розгорнути fullchain, перезавантажити Postfix. Доставка відновилась негайно для того клієнта і кількох інших, які тихо відкладали пошту.

Урок: дійсний сертифікат — це не ідентичність; це ствердження. SMTP‑пір вирішує, чи вірити йому і з чим порівнювати.
Ваші припущення голосу не мають.

Коротка історія 2: Оптимізація, яка повернулася бумерангом (жорстка політика → несумісність)

Ініціатива безпеки пройшла через велику корпорацію: стандартизувати «сучасний TLS скрізь». Команді пошти сказали вимкнути
старі протоколи і шифри «щоб відповідати відповідності». Ніхто не сперечався з метою; сперечалися про терміни.
Терміни перемогли.

Вони відправили конфігурацію, яка фактично вимагала TLS 1.3 для вхідного SMTP. На папері це виглядало прогресивно.
На практиці це перетворило їхні MX на воротаря з блокнотом і без терпіння.

Деякі відправники погоджували TLS 1.3 добре. Інші — промислові пристрої, невеликі бізнес‑MTA і кілька партнерів на старих бібліотеках —
могли лише TLS 1.2. Доставка почала періодично падати. Не тільки зі спамних джерел. Реальні рахунки. Реальні оновлення тикетів.
Інцидент спочатку класифікували як «нестабільність мережі», бо виглядав випадковим по відправниках.

Відновлення було контрольованим відкатом: дозволити TLS 1.2, тримати TLS 1.0/1.1 вимкненими, і використати розумний набір шифрів, що перекривається
з поширеними версіями OpenSSL. Вони також впровадили моніторинг розподілу версій TLS на вхідних з’єднаннях.

Урок: хардінг — це не один перемикач. Це переговори. SMTP — це екосистема, а не ваш додаток.
Прагнете безпеки без тестування інтероперабельності — і ви «безпечно» втратите пошту.

Коротка історія 3: Нудна, правильна практика, що врятувала день (TLSRPT + поетапне застосування)

Інша компанія хотіла примусити шифрування для вхідної пошти. Мали юридичні вимоги і реальну модель загроз.
Замість того, щоб різко перемкнути налаштування, вони зробили це поетапно: спостерігали, вимірювали, а потім примушували.

Вони опублікували звітність TLS і збирали TLSRPT звіти централізовано. Тижнями команда пошти переглядала категорії відмов.
Більшість — очікуваний шум, але кілька були реальними: один MX‑вузол після оновлення пакету почав подавати неправильний ланцюжок;
інший мав адресу IPv6 з застарілим сертифікатом, бо автоматизація оновлювала лише IPv4 VIP.

Вони виправили невідповідності, додали щоденну задачу, яка перевіряє кожний MX-ендпоінт по IPv4 і IPv6,
і лише потім перемкнули MTA-STS у режим enforce. Коли вони нарешті ввели примус, кількість відмов не зросла.
Навпаки — впала, бо вони усунули некоректні конфігурації, які тихо викликали опортуністичні відкотіння TLS.

Урок: нудна телеметрія краще, ніж героїчне налагодження. Якщо хочете суворий TLS — заробіть його, роблячи ендпоінти нудно послідовними перед перемиканням.

Жарт №2: Єдина річ, що настирливіша за відсутній проміжний — це запрошення на зустріч «повернутись до цього» наступного кварталу.

Типові помилки: симптом → коренева причина → виправлення

1) «TLS handshake failed» з сертифікатом, який у браузері виглядає нормально

Симптом: Віддалені MTA в логах — certificate verify failed або unknown ca; у браузері — замочок.

Коренева причина: Відсутній проміжний у ланцюжку. Браузери підтягують; багато MTA — ні.

Виправлення: Подавати fullchain.pem (листовий + проміжні) з вашої MTA. Не сподівайтеся на AIA.

2) Працює для одних відправників, падає для інших (ніби випадково)

Симптом: Частина відправників постійно не проходить перевірку STARTTLS; інші проходять.

Коренева причина: Вибір сертифіката залежно від SNI або різна суворість валідації між MTA.

Виправлення: Тестуйте з SNI і без. Зробіть сертифікат за замовчуванням прийнятним для вашого MX або виділіть IP.

3) «hostname mismatch» або «certificate does not match»

Симптом: У логах згадується невідповідність; доставка відкладена або TLS відкотиться.

Коренева причина: SAN сертифіката не містить цільового імені MX (поширено під час міграцій).

Виправлення: Перевипустіть сертифікат, щоб включити всі MX‑імена в SAN; або змініть MX, щоб відповідати існуючому сертифікату.

4) STARTTLS не пропонується, хоча ви налаштували сертифікати

Симптом: У EHLO немає 250-STARTTLS.

Коренева причина: TLS вимкнено в конфігурації MTA; проблеми з chroot шляхом; права доступу; або проксі обрізає розширення.

Виправлення: Переконайтеся, що TLS увімкнено, сертифікат/ключ доступні для MTA, і що ніякий middlebox не змінює SMTP‑розширення.

5) Раптові відмови після увімкнення MTA-STS

Симптом: Раніше доставлялася пошта, тепер вона відкладається від великих провайдерів; TLSRPT показує політичні помилки.

Коренева причина: Публікація MTA-STS перетворила опортуністичний TLS у жорстку валідацію, виявивши невідповідності імен/ланцюжків.

Виправлення: Узгодьте сертифікати на всіх MX‑ендпоінтах (включаючи IPv6), перевірте імена, виправте подачу ланцюжка, потім знову застосуйте enforce.

6) TLS падає тільки по IPv6

Симптом: Шлях по IPv4 працює; IPv6 показує неправильний сертифікат або прострочений ланцюжок.

Коренева причина: Окремий VIP, окремий слухач, застаріла автоматизація або інший пул балансувальника для AAAA.

Виправлення: Тестуйте A і AAAA ендпоінти явно; уніфікуйте автоматизацію, щоб розгортання сертифікатів охоплювало обидва.

7) «no shared cipher» або «handshake failure» після жорсткої політики

Симптом: TLS ламається на узгодженні; у логах — невідповідність шифрів або протоколу.

Коренева причина: Надмірний хардінг прибрав загальний набір (або змусив лише TLS 1.3).

Виправлення: Тримайте TLS 1.2; використовуйте сучасний, але сумісний список шифрів. Перевіряйте на матриці реальних стеків відправників.

8) Сертифікат ротейтиться, потім партнери ламаються (особливо з DANE)

Симптом: Після ротації частина відправників відмовляється від TLS, хоча новий сертифікат дійсний.

Коренева причина: TLSA записи не оновлені (DANE), або партнери мають закешовані очікування/пінінг.

Виправлення: Оновлюйте TLSA до або під час ротації; плануйте вікна перекриття; комунікуйте зі строгими партнерами.

Чеклісти / покроковий план

Крок за кроком: зробіть SMTP‑сертифікат справді робочим

1. Інвентаризуйте ваші публічні імена.
   • Перерахуйте всі цілі MX (включно з резервними MX).
   • Перерахуйте submission/IMAP/POP імена, якщо вони ділять ендпоінти.
   • Включіть IPv6 AAAA ендпоінти.
2. Випустіть сертифікати для імен, до яких підключаються люди.
   • Додайте кожне MX‑ім’я в SAN.
   • Не покладайтеся на CN тільки.
   • Вирішіть, чи потрібні wildcard SAN (зазвичай уникайте для пошти; явні імена чистіші).
3. Розгорніть повний ланцюг правильно.
   • Використовуйте fullchain.pem (листовий + проміжні).
   • Не включайте корінь CA в представлений ланцюг.
4. Установіть сертифікат за замовчуванням свідомо.
   • Припускайте, що деякі клієнти не надсилатимуть SNI.
   • Зробіть сертифікат за замовчуванням дійсним для основного MX‑імені.
5. Оберіть версії TLS з думкою про інтероп.
   • Увімкніть TLS 1.2 і TLS 1.3.
   • Вимкніть TLS 1.0/1.1, якщо немає вузької бізнес‑потреби і компенсуючих контролів.
6. Тестуйте ззовні вашої мережі.
   • Запустіть STARTTLS‑перевірки проти кожного MX‑імені і кожної IP‑сім’ї.
   • Тестуйте з SNI і без нього.
7. Обдумайте механізми примусу політик.
   • Опортуністичний TLS підходить для «базової безпеки».
   • MTA-STS/DANE — для випадків, коли ви можете утримувати консистентність конфігурації під змінами.
8. Оперіоналізуйте ротації.
   • Автоматизуйте розгортання і перезавантаження.
   • Моніторьте закінчення строку, коректність ланцюжка і паритет ендпоінтів (IPv4/IPv6).

Чекліст: перед публікацією MTA-STS у режимі enforce

• Кожен MX‑ендпоінт (всі A/AAAA адреси) подає однаковий коректний сертифікатний ланцюг.
• SAN сертифіката включає всі цільові MX‑імена.
• Сертифікат за замовчуванням прийнятний, коли SNI відсутній.
• TLS 1.2 працює всюди; TLS 1.3 працює там, де підтримується.
• Ні один middlebox не обрізає STARTTLS і не підмінює переговори.
• Ви маєте логування і процес для швидкого розслідування TLS‑відмов.

Чекліст: усунення проблем з партнерським «TLS required» конектором

• Отримайте точне ім’я і порт, до яких підключається партнер.
• Отримайте точний текст помилки і чи вона під час рукопотиску, перевірки імені або валідації ланцюга.
• Тестуйте вашу сторону з openssl s_client -starttls smtp проти того імені.
• Якщо TLS термінація за балансувальником, перевірте сертифікат LB і поведінку SNI.
• Переконайтесь, що партнер не прив’язався до старого сертифіката або проміжного.

FAQ

1) Чому мій сертифікат перевіряється в браузері, але падає для SMTP?

Браузери часто підтягують відсутні проміжні і мають великі довірені сховища. Багато MTA не підтягують проміжні і покладаються на те, що ви подаєте.
Також SMTP‑пір перевіряє MX‑ім’я, до якого він підключається, а не те, що ви випадково тестували в браузері.

2) Чи потрібен окремий сертифікат для кожного MX‑сервера?

Не обов’язково. Можна використовувати один сертифікат з SAN‑записами для всіх MX‑імен і розгортати його скрізь.
Операційно це часто простіше — один канал видачі, один графік реневалу — якщо розповсюдження під контролем.

3) Чи варто використовувати wildcard‑сертифікат для пошти?

Зазвичай: уникайте, якщо немає сильної причини. Wildcard не покриває багатосегментні імена і може приховувати недбалість у інвентарі.
Явні SAN краще підходять для аудиту і політик.

4) Чи потрібен порт 465 для безпечної пошти?

Для сервер‑до‑серверу: ні, порт 25 зі STARTTLS — норма. Для client‑submission порт 587 стандартний зі STARTTLS,
а порт 465 часто використовується для implicit TLS submission. Використовуйте те, що підтримують ваші клієнти, але не переміщуйте MX‑трафік з 25.

5) У чому різниця між опортуністичним TLS і примусовим TLS у SMTP?

Опортуністичний TLS оновлює з’єднання коли можливо і може відкотитись до plaintext якщо переговори не вдались.
Примусовий TLS (через MTA-STS, DANE або конектори партнерів) відмовляється доставляти, якщо TLS не відповідає політиці.

6) Чи всі MTA перевіряють імена хостів у сертифікатах?

Ні, але більше перевіряють, ніж раніше — особливо під MTA-STS або коли налаштовано «TLS required».
Ви повинні розраховувати, що деякі піри будуть перевіряти строго, і відповідно налаштовуватися.

7) Яка найпоширеніша неправильна конфігурація, яку ви бачите?

Подання лише листового сертифіката без проміжного. Це класична помилка «на моєму ноутбуку працює» у вбранні PKI.

8) Якщо ми використовуємо DANE, чи можемо ми пропустити публічні ЦС повністю?

Можливо так, якщо ваш домен правильно підписаний DNSSEC і ваші кореспонденти валідно перевіряють DNSSEC і DANE для SMTP.
На практиці потрібно розуміти екосистему кореспондентів перед тим, як робити ставку на універсальну валідацію DNSSEC.

9) Чому деякі відправники підключаються до IPv6 і падають, тоді як IPv4 працює?

Бо ваш AAAA вказує на інший слухач або пул з застарілим сертифікатом, неправильним ланцюжком або іншим сертифікатом за замовчуванням.
Тестуйте і керуйте IPv6 як першокласний ендпоінт, а не як галочку.

10) Чи слід включати корінь CA у представлений ланцюг?

Ні. Подайте листовий і потрібні проміжні, щоб побудувати до довіреного кореня. Включення кореня зайве і іноді шкідливе.

Висновок: практичні наступні кроки

«Дійсний сертифікат» — це заспокійлива фраза, як «сервер працює». Вона також не є відповіддю.
TLS для пошти ламається у щілинах: неправильне ім’я, неповний ланцюг, несумісність SNI, політика, неузгоджені ендпоінти.
Виправлення — це радше не купівля кращого сертифіката, а приведення у згодженість ідентичності, DNS і розгортання всюди.

1. Прогоніть STARTTLS‑тести проти кожного MX‑імені (і по IPv4/IPv6). Зафіксуйте поданий ланцюг і SAN.
2. Зробіть сертифікат таким, яким світ до вас підключається: SAN для всіх MX‑цілей, коректний сертифікат за замовчуванням, послідовне розгортання.
3. Подавайте повний ланцюг (листовий + проміжні) і перевіряйте непользуючись браузером.
4. Тримайте TLS 1.2 увімкненим; додайте TLS 1.3; уникайте хардінгу, який прибирає загальний набір без доказів.
5. Якщо хочете примусу (MTA-STS/DANE) — заробіть його зробивши ендпоінти нудно послідовними перед перемиканням.

Виконайте ці п’ять кроків — і більшість «загадкових TLS‑помилок у пошті» перестануть бути загадковими. Вони стануть тим, чим завжди були:
дрейф конфігурації, невідповідність ідентичності і оптимізм, що не витримує зустрічі з реальним світом.