Збої TLS-рукопотискання в SMTP: як правильно виправити сертифікати, шифри й ланцюги

Швидкий план діагностики

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

1) Підтвердіть, на якому етапі відбувається збій: до STARTTLS, під час рукопотискання чи після

• До STARTTLS: STARTTLS не пропонується, невірний порт, брандмауер або політика відмовляє шифрування (так, таке буває).
• Під час рукопотискання: невідповідність протоколу/шифрів, поганий ланцюг сертифікатів, невірний сертифікат через SNI, прострочений сертифікат або проблема зі сховищем довіри клієнта.
• Після рукопотискання: збій SMTP-автентифікації, відхилення політикою або проблеми на рівні застосунку, які помилково повідомляються як TLS.

2) Запустіть один канонічний зонд з боку, який падає

Робіть це з тієї самої мережевої сегментації та хоста, що і помилка. TLS чутливий до «в мене на ноуті працює» брехні.

Використовуйте openssl s_client зі STARTTLS і зафіксуйте ланцюг сертифікатів плюс погоджений протокол і шифр.

3) Вирішіть, у який кошик ви потрапили

• «No peer certificate» / «handshake failure» миттєво: невідповідність протоколу/шифрів, STARTTLS фактично не відбувається або сервер відкидає через політику/SNI.
• «verify error:num=20/21 unable to get local issuer certificate»: неправильна презентація ланцюга або відсутній проміжний сертифікат.
• «certificate has expired» / «not yet valid»: життєвий цикл сертифіката або зсув системного часу.
• «hostname mismatch»: невірний сертифікат, SNI не використовується або налаштований неправильно, або MX вказує туди, куди ви не очікували.

4) Виправляйте сервер першим, якщо ви не контролюєте клієнта

У SMTP ви часто не контролюєте іншу сторону. Отже: виправляйте те, що ви подаєте і з чим ведете переговори. Якщо ваш сервер виступає як клієнт для вихідної пошти, виправляйте також своє сховище довіри та політики, але не залатовуйте зламану конфігурацію сервера параметром «accept_invalid_certs = yes». Це не виправлення; це план порушення безпеки.

Як насправді ламаються TLS-рукопотискання в SMTP (і чому логи брешуть)

SMTP TLS має два поширені режими:

• Неявний TLS (SMTPS на 465): TLS починається відразу після встановлення TCP-з’єднання.
• STARTTLS (зазвичай на 25 або 587): клієнт підключається в незашифрованому вигляді, відправляє EHLO, бачить STARTTLS, а потім піднімає канал до TLS.

Помилки рукопотискання часто звітовані одним пригніченим рядком, але фактичний збій зазвичай одна з цих причин:

1. Невідповідність переговорів: відсутній спільний протокол (TLS 1.0 проти TLS 1.2+) або відсутні спільні набори шифрів.
2. Проблеми ланцюга сертифікатів: сервер показує лише leaf-сертифікат і забуває проміжні. Деякі клієнти можуть добути відсутні проміжні; багато SMTP-стеків — ні.
3. Проблеми довіри: клієнт не довіряє ланцюгу (старе кореневе сховище, приватний CA, відсутній корінь або нещодавно недовірили CA).
4. Проблеми ідентичності: сертифікат не відповідає імені, яке очікує клієнт (ім’я MX проти банера проти SNI).
5. Політичні/політичні питання: сервер вимагає клієнтські сертифікати, вимагає SNI, відкидає слабкі підписи або застосовує очікування MTA-STS/DANE щодо іншої сторони.
6. Проміжні пристрої: брандмауери «допомагають», перехоплюючи або спотворюючи STARTTLS, або інспекція вихідного TLS йде не так.

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

Парафраз ідеї з атрибуцією: «Надія — не стратегія.» — часто приписується у колах надійності Gene Kranz, відображаючи операційний підхід (парафраз).

Цікаві факти та історія, яку можна використати

• STARTTLS був шляхом оновлення, а не проєктом з нуля. Він існує, бо електронна пошта вже була скрізь у незашифрованому вигляді, і ніхто не збирався перевлаштовувати планету.
• Порт 465 мав дивне життя. Він починався як «SMTPS», його відсунули на користь STARTTLS, а потім він повернувся як формально визнаний порт для TLS-подання в сучасній практиці.
• TLS 1.3 змінив форму рукопотискання. Менше кругів відповіді, інші імена шифрів та менше старих налаштувань. Добре для безпеки; збиває з пантелику старі скрипти моніторингу.
• Деякі SMTP-клієнти не добувають відсутні проміжні. Браузери прощаючі; MTA часто — ні. Не припускайте, що щось автоматично виправиться.
• SNI молодший за більшість поштових серверів. Якщо ви розміщуєте декілька доменів на одному IP, сучасні клієнти надсилають SNI, але не всі SMTP-стеки робили це історично.
• Депрекація SHA-1 усе ще переслідує довгоживучі пристрої. Старе обладнання може відкидати нові підписи, а нове — старі підписи. Усі розчаровані.
• CAA записи можуть тихо порушити автоматичне оновлення сертифікатів. Якщо ваша автоматизація оновлює через ACME, а CAA блокує видавця, ви дізнаєтесь про це, коли сертифікат прострочиться — у вихідні.
• DNS-засновані механізми безпеки (DANE, MTA-STS) змінили очікування. Деякі відправники тепер наполягають на валідному TLS для доставки й будуть відкладати, а не понижувати безпеку.
• Сховища довіри — це політичні документи. CA може бути довірена сьогодні та недовірилася завтра. Ваш аргумент «це валідний сертифікат» не допоможе, якщо корінь зник.

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

Ось завдання, які я реально виконую під час інцидентів. Кожне містить команду, що означає вивід і яке рішення з цього випливає.

Завдання 1: Перевірте, чи сервер пропонує STARTTLS на порті 25

cr0x@server:~$ nc -nv mail.example.net 25
(UNKNOWN) [203.0.113.10] 25 (smtp) open
220 mx1.example.net ESMTP Postfix

Значення: TCP працює, і ви дістали банер SMTP. Якщо це зависає або таймаутиться, ви ще не дебажите TLS.

Рішення: Якщо TCP не працює — спочатку виправляйте маршрутизацію/брандмауер/DNS. Якщо банер належить іншому хосту — перевіряйте MX і балансувальники навантаження.

Завдання 2: Підтвердіть, що STARTTLS рекламується

cr0x@server:~$ printf "EHLO probe.example\r\nQUIT\r\n" | nc -nv mail.example.net 25
(UNKNOWN) [203.0.113.10] 25 (smtp) open
220 mx1.example.net ESMTP Postfix
250-mx1.example.net
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
221 2.0.0 Bye

Значення: STARTTLS присутній. Якщо його немає — TLS вимкнено або політика приховує його (рідко, але буває).

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

Завдання 3: Виконайте STARTTLS-зонд із SNI

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net -showcerts -verify_return_error
CONNECTED(00000003)
depth=2 C = US, O = Example Root CA, CN = Example Root CA R1
verify return:1
depth=1 C = US, O = Example Issuing CA, CN = Example Issuing CA G2
verify return:1
depth=0 CN = mail.example.net
verify return:1
---
Certificate chain
 0 s:CN = mail.example.net
   i:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
-----BEGIN CERTIFICATE-----
...snip...
-----END CERTIFICATE-----
 1 s:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
   i:C = US, O = Example Root CA, CN = Example Root CA R1
-----BEGIN CERTIFICATE-----
...snip...
-----END CERTIFICATE-----
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Verify return code: 0 (ok)

Значення: Ви погодили TLS 1.3 і валідація пройшла. Ланцюг містить проміжний сертифікат.

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

Завдання 4: Зонд без SNI, щоб спіймати проблему «сертифікат за замовчуванням»

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -showcerts -verify_return_error
CONNECTED(00000003)
depth=0 CN = default.invalid
verify error:num=62:Hostname mismatch
80DB5E2E677F0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1889:
---
Certificate chain
 0 s:CN = default.invalid
   i:C = US, O = Example Issuing CA, CN = Example Issuing CA G2
---
Verify return code: 62 (Hostname mismatch)

Значення: Без SNI сервер видає сертифікат за замовчуванням для іншого імені.

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

Завдання 5: Визначте невідповідність версій протоколу (клієнт занадто старий або сервер надто суворий)

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -tls1
CONNECTED(00000003)
140735215769152:error:0A000102:SSL routines:ssl_choose_client_version:unsupported protocol:../ssl/statem/statem_lib.c:1950:
no peer certificate available

Значення: Сервер відмовляє TLS 1.0. Це нормально у 2026 році.

Рішення: Якщо застарілий клієнт не підтримує TLS 1.2+, оновіть його або ізолюйте за контрольованим реле. Не вмикайте TLS 1.0 на інтернет-MX тільки заради сумісності.

Завдання 6: Визначте невідповідність набору шифрів

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.net:25 -tls1_2 -cipher 'RC4-SHA'
CONNECTED(00000003)
140735215769152:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1605:SSL alert number 40
no peer certificate available

Значення: Ви запропонували давній шифр; сервер відмовив. Добре.

Рішення: Якщо трапляється зворотна ситуація (клієнт пропонує лише сміття) — виправлення на боці клієнта. Якщо ваш сервер пропонує лише застаріле — оновіть бібліотеку TLS і конфіг.

Завдання 7: Перевірте файл ланцюга сертифікатів на диску

cr0x@server:~$ openssl x509 -in /etc/ssl/mail/mail.example.net.crt -noout -subject -issuer -dates -ext subjectAltName
subject=CN = mail.example.net
issuer=C = US, O = Example Issuing CA, CN = Example Issuing CA G2
notBefore=Dec  1 00:00:00 2025 GMT
notAfter=Mar  1 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:mail.example.net, DNS:mx1.example.net

Значення: Дати та SAN виглядають адекватно. Закінчення терміну незабаром: це вже майбутній інцидент.

Рішення: Якщо SAN не відповідає імені, до якого підключаються пірі (часто ім’я MX), випустіть сертифікат із правильними іменами і вирівняйте DNS.

Завдання 8: Переконайтеся, що представлений ланцюг повний і впорядкований

cr0x@server:~$ openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -untrusted /etc/ssl/mail/intermediate.pem /etc/ssl/mail/mail.example.net.crt
/etc/ssl/mail/mail.example.net.crt: OK

Значення: За наявності проміжного сертифіката leaf перевіряється проти системних корнів.

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

Завдання 9: Подивіться, що фактично представляє SMTP-служба (не те, що ви думаєте)

cr0x@server:~$ openssl s_client -starttls smtp -connect 203.0.113.10:25 -servername mail.example.net 2>/dev/null | openssl x509 -noout -subject -issuer -ext subjectAltName
subject=CN = mail.example.net
issuer=C = US, O = Example Issuing CA, CN = Example Issuing CA G2
X509v3 Subject Alternative Name:
    DNS:mail.example.net, DNS:mx1.example.net

Значення: Ви перевіряєте живу службу, а не файл у /etc/ssl, який ніхто фактично не завантажив.

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

Завдання 10: Підтвердіть, що ваш MTA слухає там, де ви думаєте

cr0x@server:~$ ss -ltnp | egrep ':(25|465|587)\s'
LISTEN 0      100          0.0.0.0:25        0.0.0.0:*    users:(("master",pid=1243,fd=13))
LISTEN 0      100          0.0.0.0:587       0.0.0.0:*    users:(("master",pid=1243,fd=14))
LISTEN 0      100          0.0.0.0:465       0.0.0.0:*    users:(("master",pid=1243,fd=15))

Значення: Postfix master прив’язаний до всіх трьох портів. Якщо 465 відсутній — SMTPS не увімкнено.

Рішення: Погодьте реальність слухачів із опублікованими налаштуваннями та очікуваннями клієнтів.

Завдання 11: Витягніть точні TLS-помилки з логів Postfix

cr0x@server:~$ sudo grep -E "warning: TLS|SSL_accept|SSL_connect|handshake" /var/log/mail.log | tail -n 8
Jan 03 11:04:18 mx1 postfix/smtpd[22418]: warning: TLS library problem: error:0A000076:SSL routines::no suitable signature algorithm:../ssl/t1_lib.c:3364:
Jan 03 11:04:18 mx1 postfix/smtpd[22418]: lost connection after STARTTLS from unknown[198.51.100.23]
Jan 03 11:06:44 mx1 postfix/smtpd[22502]: warning: TLS library problem: error:0A000410:SSL routines::sslv3 alert handshake failure:../ssl/record/rec_layer_s3.c:1605:SSL alert number 40
Jan 03 11:06:44 mx1 postfix/smtpd[22502]: lost connection after STARTTLS from mail.partner.example[203.0.113.77]

Значення: «No suitable signature algorithm» часто вказує на невідповідність RSA/EC-алгоритмів або дуже старі обмеження пірів.

Рішення: Рішіть, чи підтримуватимете TLS-стек цього партнера. Якщо це ключовий бізнес-партнер, маршрутизируйте через виділене реле з підібраною сумісністю; не слабшайте головний MX.

Завдання 12: Перевірте вихідну сторону: що ваш сервер погоджує, виступаючи клієнтом

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.partner.example:25 -servername mx.partner.example -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN = mx.partner.example
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK

Значення: Вихідна переговорка пройшла; протокол/шифр виглядають сучасно.

Рішення: Якщо вихідні спроби провалюються тільки з вашого MTA, але з OpenSSL проходять — перевірте політику TLS MTA, підтримку SNI і шляхи до файлу CA.

Завдання 13: Перевірте системний час і синхронізацію (так, це важливо)

cr0x@server:~$ timedatectl
Local time: Sat 2026-01-03 11:12:29 UTC
Universal time: Sat 2026-01-03 11:12:29 UTC
RTC time: Sat 2026-01-03 11:12:29
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Значення: Час синхронізований. Якщо ні — помилки «not yet valid» гарантовані.

Рішення: Виправляйте NTP перед тим, як лізти в TLS-конфіги. Неправильний годинник робить кожен сертифікат підозрілим.

Завдання 14: Підтвердіть, що сховище CA, яке використовує ваш MTA, заповнене

cr0x@server:~$ ls -l /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 214392 Jan  2 02:14 /etc/ssl/certs/ca-certificates.crt

Значення: Маєте консолідований CA-бандл. Деякі MTA налаштовані на використання кастомних бандлів; переконайтеся, що вони існують і оновлені.

Рішення: Якщо ви використовуєте кастомний CA-файл — документуйте це й автоматизуйте оновлення. Інакше тримайте його в стандартному шляху ОС.

Жарт 1: TLS-рукопотискання — як зустріч двох керівників: обидва наполягають, що сумісні, і ніхто не змінить своїх дефолтів.

Ланцюги сертифікатів: як правильно їх будувати

Найпоширеніша помилка TLS у полях: сервери, що подають неповний ланцюг. Браузери часто ремонтують це, добуваючи проміжні через Authority Information Access (AIA). SMTP-клієнти зазвичай цього не роблять. Вони пробують те, що ви дали, і йдуть геть.

Що означає «правильний ланцюг» у термінах SMTP

• Leaf-сертифікат: для SMTP-імені хоста, до якого підключаються пірі (зазвичай ім’я MX).
• Проміжний(і) сертифікат(и): потрібні, щоб зв’язати leaf з коренем у сховищі довіри клієнта.
• Кореневий сертифікат: зазвичай не надсилається сервером; клієнти вже мають його. Надсилання рідко шкодить, але може плутати деякі зламані стеки й ускладнює налагодження.

Порядок має значення

Коли ви конкатенуєте сертифікати, робіть це в порядку: спочатку leaf, потім кожний проміжний вгору по ланцюгу. Не додавайте корінь, якщо немає конкретної причини. Якщо ви отримали «fullchain.pem» від CA, то зазвичай це leaf + проміжні — саме те, що потрібно подавати.

Як проблеми ланцюга проявляються в реальних логах

• Помилка на боці клієнта: «unable to get local issuer certificate» або «unknown ca».
• Симптом на боці сервера: з’єднання обривається відразу після STARTTLS, часто логовано як «lost connection after STARTTLS».
• Операційний запах: деякі приймачі приймають пошту, інші відкладають її на години, залежно від стека TLS і свіжості їхнього сховища довіри.

Не змішуйте файли ланцюгів для сервісів необережно

Один хост може обслуговувати HTTPS, IMAPS, POP3S і SMTP. Кожен сервіс може бути налаштований на використання різних шляхів до файлу сертифіката. Якщо ви «оновили сертифікат», але оновили лише вебсервер — вітаємо: ви полагодили не той сервіс. Це трапляється частіше, ніж хто зізнається.

Шифри та версії протоколів: припиніть переговори як у 1999 році

Якщо рукопотискання падає з повідомленням «no shared cipher» або «protocol version», ви дивитесь одну з двох ситуацій:

1. Ваш сервер надто суворий для легітимного пірa, якого ви повинні підтримувати.
2. Пір застарілий, і ви не повинні погіршувати базову безпеку.

Ось частина з суб’єктивною думкою: для інтернет-facing MX за замовчуванням обирайте TLS 1.2 і TLS 1.3, сучасні AEAD-шифри і адекватні криві. Якщо хтось не може з таким працювати — вони можуть доставити без TLS тільки якщо ваша політика це дозволяє — або оновитися. Ваше завдання — доставка пошти і управління ризиками, не ведення музею сумісності.

Реальність SMTP: ви не контролюєте більшість пірів

Але ви можете контролювати, як ви відпадаєте:

• Для вхідних: ви можете пропонувати TLS, але приймати plaintext, якщо ваша політика дозволяє. Це зберігає доставку, але не примушує безпеку.
• Для вихідних: ви можете вимагати TLS для певних доменів (карта політик), або застосовувати MTA-STS/DANE там, де доступно.

Пастка оптимізації: «ми відключили TLS 1.2, бо 1.3 швидше»

TLS 1.3 прекрасний. Але вам все одно потрібен TLS 1.2 для сумісності з частиною інфраструктури SMTP, яка не оновилась, включно з деякими управляємиими appliances. Тримайте TLS 1.2 увімкненим, якщо тільки у вас немає контрольованого середовища і документованих винятків.

SNI, перевірка імен і пастка «неправильного сертифіката»

SNI (Server Name Indication) — це те, як клієнт повідомляє серверу, яке ім’я хоста він хоче під час TLS-рукопотискання. Без SNI сервер обирає сертифікат за замовчуванням. Це нормально для одно-доменних серверів. Це катастрофа для багатоклієнтських шлюзів пошти.

Звідки береться очікуване ім’я

SMTP-клієнти зазвичай підключаються до ім’я MX, яке вони отримали з DNS. Вони перевіряють сертифікат проти цього імені. Якщо ваш MX запис вказує на mx1.example.net, а сертифікат лише містить mail.example.net, ви створили власний простій. Виправляйте імена перш ніж «конфігурувати обхід» істини DNS.

Три площини імен, які треба вирівняти

• DNS: MX вказує на ім’я; A/AAAA відображає його на IP.
• SMTP-банер: що ваш сервер каже у привітальному 220. Не використовується безпосередньо для TLS-валидації, але впливає на налагодження і сигнали репутації.
• SAN сертифіката: імена, для яких сертифікат дійсний. Це вирішальне для перевірки імен у TLS.

Якщо ви хостите кілька доменів на одному MX, ви все ще можете використовувати один сертифікат із кількома іменами через SAN, або використовувати SNI-перемикання, якщо ваш MTA чисто це підтримує. «Правильний» вибір залежить від операційної складності: розростання SAN неприємне, але помилка SNI — ще гірша.

Шаблони конфігурації MTA (Postfix, Exim), що не старіють погано

Я триматиму це практично: вам потрібні конфіги, які явні, тестовані і перезавантажувані без сюрпризів.

Postfix: необхідне для вхідного TLS

• Використовуйте файл повного ланцюга для smtpd_tls_cert_file (leaf + проміжні).
• Вкажіть smtpd_tls_key_file на відповідний приватний ключ.
• Встановіть мінімальний рівень протоколу, що відповідає вашій політиці ризику; зазвичай TLS 1.2.
• Логуйте достатньо для налагодження (smtpd_tls_loglevel), але не настільки, щоб влаштувати DDoS ваших дисків.

Postfix: необхідне для вихідного TLS

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

• Опортуністичний: намагайтеся STARTTLS, якщо його пропонують, але доставляйте без нього, якщо пір не підтримує.
• Обов’язковий для доменів: вимагайте TLS для певних партнерів і закривайте доставку, якщо він недоступний.

Exim: та сама фізика, інші ручки

Exim із задоволенням дозволить вам застрелити себе в ногу TLS-конфігом теж. Принцип той самий: подавайте повний ланцюг, переконайтеся у відповідності імен, тримайте сучасні версії протоколів та тестуйте з і без SNI, де це має значення.

Три корпоративні міні-історії з практики

1) Аварія через хибне припущення

Компанія мала один поштовий шлюз, що обслуговував вхід для кількох брендів. DNS був чистий, MX записи вказували на mx.brand-a.example і mx.brand-b.example, обидва резолвилися на один і той самий IP. Команда оновлювала сертифікати через ACME-клієнт, і все «виглядало добре» з перевіркою в браузері.

В понеділок зранку підмножина партнерів почала відкладати пошту на бренд B. Логи показували «TLS handshake failed» на боці відправника, тоді як приймач бачив «lost connection after STARTTLS» без явних помилок сертифікату. Інженер на чергуванні робив те, що роблять багато під тиском: збільшив логування і довго дивився на нього. Нічого.

Хибне припущення було тонким: вони вірили, що всі SMTP-клієнти надсилають SNI так само, як сучасні веб-клієнти. Багато хто так і робив. Декотрі — ні. Ці клієнти отримували сертифікат за замовчуванням — сертифікат бренду A — бо поштовий демон обирав перший налаштований сертифікат за відсутності SNI.

Виправлення полягало не в проханні партнерів оновитись. Виправлення — перестати залежати від SNI для коректності. Вони випустили сертифікат з SAN, що покривав обидва MX-ім’я, і налаштували SMTP-службу подавати цей єдиний сертифікат. Також оновили моніторинг, щоб тестувати з і без SNI, бо реальність має кути.

Після цього команда задокументувала правило: для публічного SMTP SNI — це функція продуктивності/організації, а не залежність коректності — якщо тільки ви явно не перевірили свій екосистему пірів.

2) Оптимізація, що відбилася боком

Інша організація пишалася тим, що загострила безпеку. Вони відключили TLS 1.2 на службі submission, бо «TLS 1.3 безпечніший і швидший». Це було розгорнуто разом з новим балансувальником навантаження і блискучим звітом з відповідності. Усім було спокійно.

Через два тижні з’явилась хвиля скарг: мобільні клієнти не могли відправляти пошту періодично. Не всі клієнти. Не всі мережі. Звісно. Хелпдеск звинувачував паролі і примусово скидав їх, що тільки ускладнило проблему і розсердило користувачів.

Причина була в сумісності: кілька корпоративних керованих мобільних клієнтів все ще погоджували лише TLS 1.2. Ці клієнти не були «неправі», просто «повільно оновлювалися», що фактично є типовим станом корпоративного управління кінцевими точками. Логи балансувальника показали провали рукопотискань; логи застосунку були здебільшого тихі.

Виправлення — знову ввімкнути TLS 1.2 на submission і зберегти TLS 1.3 як пріоритет. Вони також додали процедуру «канарка сумісності»: перед вимкненням версії протоколу вимірювати, хто її ще використовує на краю submission.

Урок: покращення безпеки, що ламають пошту, не є покращенням безпеки; це атака на продуктивність власного персоналу.

3) Нудна, але правильна практика, що врятувала день

Постачальник SaaS середнього розміру тримав реле пошти в двох дата-центрах. Нічого екзотичного. Вони свято дотримувалися двох практик: зберігали інвентар сертифікатів у системі управління конфігом і запускали щоденні синтетичні зонди, які валідували TLS-рукопотискання так, як це роблять реальні SMTP-пірі.

Одного дня CA повернув проміжний у спосіб, який був цілком легітимним. ACME-клієнт поновив leaf, але пайплайн деплою випадково відправив лише leaf-сертифікат в релеи одного дата-центру — без проміжного. Половина вихідних доставок почала відкладатися більш суворими приймачами. Інша половина йшла далі, бо інший дата-центр був налаштований правильно.

Ось чому це не стало «великим інцидентом»: їхній синтетичний зонд спіймав це за кілька хвилин, бо він тестував openssl s_client -starttls smtp -showcerts і перевіряв довжину ланцюга та статус валідації. Алерт був не «черга пошти велика». Він був «неповний TLS-ланцюг на mx2». Конкретний, дієвий, нудний.

Відкат був миттєвим. Ніяких геройств. Просто чистий redeploy з правильним файлом повного ланцюга і постмортем, що зосередився на тому, чому пайплайн дозволив артефакт часткового ланцюга.

Нудна коректність недооцінена, доки вона не залишається єдиним між вами і тижнем поштових проблем з репутацією.

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

1) Симптом: «STARTTLS не пропонується»

• Корінна причина: TLS вимкнено в MTA, неправильна служба (submission vs MX), або проксі/балансувальник навантаження видаляє розширення.
• Виправлення: Підтвердіть сирим EHLO-зондом. Увімкніть STARTTLS на правильному слухачі. Якщо спереду проксі — переконайтеся, що він прозоро передає SMTP або коректно завершує TLS.

2) Симптом: «lost connection after STARTTLS» у логах сервера

• Корінна причина: пір припинив рукопотискання через недовірений ланцюг, невідповідність імені або невідповідність протоколу/шифрів.
• Виправлення: Запустіть openssl s_client -starttls smtp -servername ... -showcerts зі сторони пірa, якщо можливо; інакше відтворіть з зовнішнього хоста. Перевірте повноту ланцюга і погоджений протокол.

3) Симптом: «verify error:num=20 unable to get local issuer certificate»

• Корінна причина: відсутні проміжні(і) у тому, що сервер представляє.
• Виправлення: Налаштуйте сервіс представляти повний ланцюг (leaf + проміжні). Не припускайте, що клієнти добудують AIA.

4) Симптом: «certificate has expired», але ви його оновили

• Корінна причина: сервіс все ще використовує старий файл, не відбулося перезавантаження, оновлено не той слухач або балансувальник завершує TLS зі своїм сертифікатом.
• Виправлення: Запитайте живий сертифікат і порівняйте його серійник/дати з тим, що на диску. Перезавантажте правильний демон. Оновіть сховище сертифікатів балансувальника, якщо він завершує TLS.

5) Симптом: «wrong version number» в OpenSSL

• Корінна причина: ви підключилися з implicit TLS до порту STARTTLS (або навпаки), або на тому порту працює не-TLS служба.
• Виправлення: Використовуйте -starttls smtp для портів 25/587 і простий openssl s_client -connect host:465 для 465.

6) Симптом: працює з деякими відправниками, падає з іншими

• Корінна причина: залежність від SNI, різниця презентації ланцюга між нодами або пірі з різними сховищами довіри/підтримкою протоколів.
• Виправлення: тестуйте з і без SNI; тестуйте кожен MX вузол/IP; забезпечте послідовне розгортання ланцюга по всьому флоту.

7) Симптом: збій рукопотискання лише після оновлення криптобібліотеки

• Корінна причина: суворіші дефолти (мінімальний розмір ключа, алгоритми підпису, відключені застарілі шифри).
• Виправлення: проаналізуйте погоджені підписи/шифри, свідомо підправте політику і задокументуйте винятки. Не вмикайте застарілі алгоритми глобально без розуміння ризиків.

Жарт 2: Якщо ви все ще вмикаєте TLS 1.0 «для того одного партнера», ви фактично заводите собі тигра як домашнього улюбленця, бо йому самотньо.

Контрольні списки / план по кроках

Контрольний список інциденту: відновіть доставку пошти, не створюючи інцидент безпеки

1. Відтворіть з точки, яка падає. По можливості той самий хост/мережа.
2. Визначте режим: STARTTLS (25/587) чи неявний TLS (465).
3. Захопіть докази рукопотискання: протокол, шифр, поданий ланцюг, код валідації.
4. Перевірте імена: до якого імені підключаються пірі (MX) і чи воно є в SAN?
5. Перевірте повноту ланцюга: leaf + проміжні представлені й впорядковані правильно.
6. Перевірте терміни та синхронізацію часу: дати сертифікатів, системний годинник, статус NTP.
7. Перевірте поведінку SNI: порівняйте зонди з і без -servername.
8. Перевірте узгодженість флоту: тестуйте кожен IP MX напряму, а не лише ім’я хоста.
9. Тільки потім змінюйте політику TLS: мінімальні протоколи/шифри, винятки по партнерам якщо критично.
10. Розгорніть безпечно: перезавантажте сервіси, підтвердіть живий сертифікат і повторіть зонди.
11. Закрийте цикл: випорожніть черги, спостерігайте відтермінування, підтвердіть прийняття партнерами.
12. Напишіть постмортем: що зламалося, що не виявилося, що автоматизувати.

Контрольний список жорсткості: зберігайте сумісність без безглуздя

• Увімкніть TLS 1.2 і TLS 1.3; вимкніть TLS 1.0/1.1 на інтернет-сервісах, якщо немає вузько-окреслених винятків.
• Віддавайте перевагу AEAD-шифрам; уникайте статичного RSA обміну ключами.
• Використовуйте сертифікат із SAN, що відповідає іменам MX. Не покладайтеся на CN лише.
• Подавайте повний ланцюг (leaf + проміжні). Тестуйте стримким валідатором.
• Автоматизуйте оновлення і перезавантаження, перевіряйте живу презентацію після деплою.
• Моніторте ззовні вашої мережі за допомогою STARTTLS-зондів, а не лише HTTPS-чеків.
• Документуйте, де завершується TLS (MTA vs балансувальник). Один пункт термінації на потік — ознака здорового розуму.

План управління змінами: робіть TLS-зміни без сюрпризів

1. Збирайте телеметрію: поточні погоджені протокол-версії і шифри (на submission і, якщо можливо, на inbound).
2. Стадійні зміни на одному вузлі (канарка MX), вимірюйте відтермінування і помилки рукопотискань.
3. Комунікуйте зміни, що впливають на партнерів, заздалегідь, якщо ви починаєте вимагати TLS.
4. Розгорніть по флоту з автоматичною валідацією: зондьте кожен вузол/IP і перевіряйте ланцюг і відповідність імені.
5. Зберігайте шлях екстреного відкату, який не передбачає глобального ввімкнення застарілих протоколів.

FAQ

1) Чому OpenSSL валідує OK, а Postfix (або партнер) все одно падає?

Різні сховища довіри, різні дефолти і іноді різна поведінка SNI. OpenSSL може використовувати OS CA-бандл; ваш MTA може використовувати кастомний CA-файл або суворі карти політик.

2) Чи варто включати кореневий CA в ланцюг, який я подаю?

Зазвичай ні. Подавайте leaf + проміжні. Корені належать у сховищі довіри клієнта. Додавання кореня рідко допомагає і іноді плутає зламаних клієнтів.

3) Яка найпоширеніша помилка з ланцюгом?

Розгортання лише leaf-сертифіката. SMTP-клієнти часто не добувають проміжні, тому валідація падає, навіть якщо «сертифікат валідний» у браузері.

4) Чи можу я виправити збої рукопотискання, дозволивши слабші шифри?

Іноді так, але це часто неправильний крок. Якщо пір підтримує лише слабкі шифри, маршрутизируйте цей трафік через контрольоване реле з локальною політикою. Не послабляйте головний MX для інтернету.

5) Чому деякі відправники відкладають замість доставляти без TLS?

Деякі відправники застосовують політики TLS (вимоги по домену, MTA-STS, DANE або внутрішню відповідність). Вони радше відкладуть, ніж ризикнуть доставити в plaintext.

6) Що зазвичай означає «no suitable signature algorithm»?

Не вдалося узгодити алгоритм підпису — часто тому, що пір дуже старий або ваш тип сертифіката/ключа (RSA-PSS/ECDSA) не відповідає тому, що пір може валідувати. Виправлення — політика сумісності або оновлення пірa, а не випадкові зміни шифрів.

7) Чи є порт 465 «неправильним» для SMTP?

Ні. Порт 465 часто використовується для неявного TLS submission. Для сервер-сервер транспорту порт 25 зі STARTTLS все ще норма. Використовуйте правильний режим для відповідної аудиторії.

8) Як зрозуміти, що проблема в SNI?

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

9) Якщо мій сертифікат покриває неправильне ім’я — чи можна просто змінити MX-запис?

Можна, але робіть це свідомо. Імена MX — частина вашої поштової ідентичності і репутації. Часто безпечніше переоформити сертифікат під існуючий MX і вирівняти DNS, банер і SAN.

Висновок: наступні кроки, що витримають аудит

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

Зробіть наступне:

1. Запустіть STARTTLS-зонд з -showcerts і зафіксуйте погоджений протокол/шифр та код валідації.
2. Повторіть без SNI і напряму проти кожного IP MX, щоб виявити сертифікат за замовчуванням і дрейф.
3. Виправте презентацію ланцюга (leaf + проміжні) і забезпечте, щоб SAN відповідав MX-іменам.
4. Тримайте TLS 1.2 + 1.3 увімкненими; уникайте глобальних понижень заради одного застарілого піра — використовуйте області реле або політики на рівні призначення.
5. Автоматизуйте валідацію: після кожного оновлення і після кожної TLS-зміни перевіряйте, що служба реально подає в мережі.

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