Пошта: оновлення TLS-сертифіката — як зберегти SMTP/IMAP працездатними в день оновлення

January 26, 2026 • February 3, 2026 • Читання: 7 хв • Views: 8

Було корисно?

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

Хороша новина: збереження стабільності SMTP/IMAP під час оновлення TLS-сертифіката — це здебільшого нудна механіка. Погана новина:
вона працює лише якщо ви навмисно виконали нудні кроки і протестували саме ті речі, які насправді ламаються.

Продуктивна модель: що може зламатися, де і чому

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

SMTP — це не один протокол, а три режими розгортання

Більшість операторів пошти запускають усі ці режими одночасно:

SMTP з STARTTLS (порт 25) для доставки сервер‑сервер. Опортуністичний TLS, але залежно від політики все одно прискіпливий щодо ланцюжків і імен хостів.
Submission з STARTTLS (порт 587) для користувачів/клієнтів. Зазвичай сувора валідація, особливо у сучасних мобільних/десктопних клієнтів.
SMTPS (порт 465) явний TLS. Досі поширений; клієнти очікують коректного рукопотискання одразу.

Ви можете оновити сертифікат і «потестувати порт 25», але зламати половину користувачів на 587.
Або навпаки. Питайте, як я це знаю. Хоча не питайте; це загартовує характер, і, ймовірно, у вас уже достатньо характеру.

IMAP/POP — це територія «довготривалих з’єднань»

Dovecot (або ваш IMAP/POP демон) часто тримає багато TLS-сесій відкритими.
Заміна сертифіката не змушує їх автоматично переговорюватися. Деякі клієнти продовжать працювати до повторного підключення; інші
агресивно перепідключаться і почнуть падати групами. Це виглядає як «періодичні мережеві проблеми», поки ви не зіставите це
з подією оновлення.

Заміна файлу — це не розгортання

Це найпоширеніша концептуальна помилка: «certbot оновив — значить все готово».
Certbot (або будь‑який ACME-клієнт) просто пише файли. Ваші демони не читають їх заново, поки ви не перезавантажите/не перелоадите,
а навіть тоді — лише якщо конфіг вказує на потрібні шляхи. Додайте символьні посилання та маунти контейнерів — отримайте класичну ситуацію:
«сертифікат на диску новий, але сервіс все ще подає старий».

Як виглядає «поломка» насправді

Ви побачите одне з наступного:

Збої рукопотискання (не той ключ, пошкоджений ланцюг, непідтримуваний протокол/шифри або погані права доступу).
Невідповідність імені хоста (неправильний CN/SAN, хибне відображення віртуальних хостів, помилковий SNI або клієнти звертаються до іншого імені, ніж ви тестували).
Політичні/політичні відмови (MTA-STS застосовано, DANE не сходиться, зафіксовані сертифікати у клієнтів, корпоративні проксі роблять «інспекцію»).
Операційні збої (перезавантаження не відбулося, дрейф конфігу, погане володіння файлами, SELinux/AppArmor блокує читання).

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

Одна цитата, яка досі актуальна в опсах: «Надія — це не план.» — Джин Кранц

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

Поведінка TLS у пошті — результат десятиліть допрацьовування. Трохи історії пояснює, чому ваша «проста» зміна може викликати
20 різних реакцій клієнтів.

STARTTLS додали пізніше. SMTP старіший за TLS; STARTTLS — це розширення, прилаштоване до старого протоколу, тому «опортуністичність» стала за замовчуванням.
Порт 465 був «заперечений», а потім повернувся. SMTPS колись був неофіційним, потім преферувалася submission на 587, а тепер 465 знову часто рекомендують для явного TLS.
Ланцюжки сертифікатів стали коротшими з часом. Багато середовищ перейшли від довгих cross-signed ланцюжків до чистіших коренів/проміжних; старі клієнти іноді вимагають «правильний» проміжний.
Let’s Encrypt прискорив цикли оновлення. Короткоживучі сертифікати нормалізували автоматизацію, але також нормалізували «ой, ми забули хук перезавантаження».
IMAP IDLE робить помилки випадковими. Довготривалі з’єднання означають, що проблеми з сертифікатами з’являються під час штормів перепідключень, а не в точний момент оновлення.
Вилучення TLS 1.0/1.1 стало ламкою зміною. Посилення версій протоколів покращило безпеку, але старі клієнти (і апаратура) відреагували болісно.
MTA-STS і TLS-RPT змінили стимули. TLS сервер‑сервер перестав бути «приємною опцією»: деякі домени відмовлятимуться, якщо ви не пройдете політику.
DANE існує, але використовується мало. Він може примусити TLS на SMTP рівні через DNSSEC, але також робить помилки при оновленні одразу очевидними для строгих пірів.

Жарт №1: оновлення TLS — це як міняти шину під час руху машини — тільки машина ще й надсилає листи керівництву й мовчки вас судить.

Плейбук швидкої діагностики (перші/другі/третьі перевірки)

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

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

Який протокол? SMTP вхідний (25), submission (587), SMTPS (465), IMAPS (993), POP3S (995).
Який хостнейм? mail.example.com проти smtp.example.com чи апекс домену.
Який тип клієнта? Сервери Gmail, Outlook на робочому столі, iOS Mail, принтер, SIEM‑пристрій.

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

Друге: витягніть сертифікат, який реально подається в мережі

Не довіряйте тому, що лежить на диску. Довіряйте тому, що реально подається.

Рішення: якщо поданий сертифікат старий — ваш reload не застосувався. Якщо він новий, але невірний — проблема в ланцюгу/імені/ключі.

Третє: підтвердіть пару ланцюга і ключа локально

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

Рішення: невідповідність означає, що файли підключені неправильно; проблеми з ланцюгом — потрібен правильний intermediate/fullchain файл у конфігу.

Четверте: читайте логи демонів із ціллю

Postfix і Dovecot зазвичай прямо кажуть, що не можуть завантажити. Люди просто не читають рядки, які мають значення.
Шукайте «cannot load», «no start line», «permission denied», «key values mismatch».

П’яте: перевірте шар політики (MTA-STS/DANE), якщо тільки певні домени відмовляють

Якщо більшість доставок проходить, але деякі домени повертають «TLS required», то це не «TLS впав»,
це «відмова відповідності політиці TLS». Інша проблема — інше рішення.

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

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

Завдання 1: Підтвердіть термін дії та SAN на диску

cr0x@server:~$ openssl x509 -in /etc/letsencrypt/live/mail.example.com/fullchain.pem -noout -dates -subject -ext subjectAltName
notBefore=Jan  1 00:12:03 2026 GMT
notAfter=Apr  1 00:12:02 2026 GMT
subject=CN = mail.example.com
X509v3 Subject Alternative Name:
    DNS:mail.example.com, DNS:smtp.example.com, DNS:imap.example.com

Значення: Цей сертифікат наразі дійсний і покриває кілька імен хостів.

Рішення: Якщо проблемний хостнейм відсутній у SAN — зупиніться. Випустіть правильний сертифікат (або додайте ім’я),
не намагайтеся «вимикати» перевірку імен.

Завдання 2: Перевірте, що приватний ключ відповідає сертифікату (modulus check)

cr0x@server:~$ openssl x509 -noout -modulus -in /etc/letsencrypt/live/mail.example.com/cert.pem | openssl md5
MD5(stdin)= 9c0a0c7d5d0f4f1d0c1b1c1f3b7a2a7e
cr0x@server:~$ openssl rsa -noout -modulus -in /etc/letsencrypt/live/mail.example.com/privkey.pem | openssl md5
MD5(stdin)= 9c0a0c7d5d0f4f1d0c1b1c1f3b7a2a7e

Значення: Сертифікат і ключ відповідають один одному.

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

Завдання 3: Перевірте, які TLS-файли бачить Postfix

cr0x@server:~$ postconf -n | egrep 'smtpd_tls_cert_file|smtpd_tls_key_file|smtpd_tls_CAfile|smtpd_tls_chain_files|smtp_tls_security_level'
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem

Значення: Postfix налаштовано подавати fullchain.pem.

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

Завдання 4: Перевірте шляхи TLS у Dovecot

cr0x@server:~$ doveconf -n | egrep 'ssl =|ssl_cert|ssl_key|ssl_min_protocol|ssl_cipher_list'
ssl = required
ssl_cert = </etc/letsencrypt/live/mail.example.com/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.example.com/privkey.pem
ssl_min_protocol = TLSv1.2

Значення: Dovecot читає повний ланцюг і вимагає TLS.

Рішення: Якщо Dovecot вказує на cert.pem замість fullchain.pem, ви часто зламаєте клієнтів, які не добувають проміжні сертифікати. Використовуйте повний ланцюг, якщо немає перевіреної причини не робити цього.

Завдання 5: Протестуйте STARTTLS на порту 25 з боку клієнта

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -showcerts -verify_return_error </dev/null
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mail.example.com
verify return:1
250 SMTPUTF8

Значення: TLS перевіряється чисто, і можливості SMTP рекламуються після STARTTLS.

Рішення: Якщо валідація не проходить, читайте перший рядок “verify error”. Якщо це «unable to get local issuer» — ваш ланцюг неправильний. Якщо «hostname mismatch» — SAN неправильний або SNI маршрутизується неправильно.

Завдання 6: Протестуйте порт submission 587 з STARTTLS і рекламою AUTH

cr0x@server:~$ openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -crlf -quiet </dev/null | head -n 12
depth=0 CN = mail.example.com
verify return:1
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250 8BITMIME

Значення: Сертифікат перевіряється і сервер рекламує AUTH (типово для submission).

Рішення: Якщо 25 працює, а 587 — ні, ймовірно у вас окремий слухач, окремий конфіг або інший процес/контейнер обслуговує 587.

Завдання 7: Протестуйте явний TLS на порту 465

cr0x@server:~$ openssl s_client -connect mail.example.com:465 -servername mail.example.com -verify_return_error </dev/null | egrep 'subject=|issuer=|Verify return code'
subject=CN = mail.example.com
issuer=C = US, O = Let's Encrypt, CN = R3
Verify return code: 0 (ok)

Значення: SMTPS‑рукопотискання чисте.

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

Завдання 8: Протестуйте IMAPS (993) і перевірте поданий сертифікат

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -verify_return_error </dev/null | egrep 'subject=|issuer=|Verify return code'
subject=CN = mail.example.com
issuer=C = US, O = Let's Encrypt, CN = R3
Verify return code: 0 (ok)

Значення: IMAPS подає очікуваний сертифікат і ланцюг.

Рішення: Якщо IMAPS падає, а SMTP працює — фокусуйтеся на Dovecot: права доступу до файлів, перезавантаження або окремий шлях ssl_cert.

Завдання 9: Підтвердіть, який сертифікат Postfix реально завантажив (через логи)

cr0x@server:~$ sudo journalctl -u postfix -n 200 --no-pager | egrep -i 'tls|certificate|key|error' | tail -n 12
Jan 04 10:21:18 mail postfix/smtpd[21456]: warning: TLS library problem: error:0A00018F:SSL routines::ee key too small
Jan 04 10:21:18 mail postfix/smtpd[21456]: fatal: TLS library initialization failed
Jan 04 10:21:19 mail postfix/master[1023]: warning: process /usr/lib/postfix/sbin/smtpd pid 21456 exit status 1
Jan 04 10:21:19 mail postfix/master[1023]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

Значення: TLS‑бібліотека відкинула розмір ключа (поширено після посилення політик безпеки або коли встановлено неправильний ключ).

Рішення: Перевидайте пару сертифікат/ключ, що відповідає політиці OpenSSL (зазвичай RSA 2048+ або ECDSA). Не послаблюйте рівні безпеки OpenSSL лише щоб «запрацювало».

Завдання 10: Переконайтеся, що Dovecot може читати файли (права та SELinux‑реальність)

cr0x@server:~$ sudo -u dovecot test -r /etc/letsencrypt/live/mail.example.com/privkey.pem && echo OK || echo NO
OK
cr0x@server:~$ sudo -u dovecot test -r /etc/letsencrypt/live/mail.example.com/fullchain.pem && echo OK || echo NO
OK

Значення: Користувач dovecot може читати обидва файли.

Рішення: Якщо ви отримуєте NO — виправте права/власність файлів або використайте крок копіювання у директорію, яку читає сервіс. Також врахуйте MAC‑системи (SELinux/AppArmor): «читабельність» за Unix‑правами не гарантує дозволу на доступ.

Завдання 11: Безпечно перезавантажте демони і перевірте, що вони залишилися в роботі

cr0x@server:~$ sudo systemctl reload postfix
cr0x@server:~$ sudo systemctl reload dovecot
cr0x@server:~$ systemctl is-active postfix dovecot
active
active

Значення: Обидві служби прийняли reload і залишилися активними.

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

Завдання 12: Перевірте зсередини мережевого неймспейсу хоста (думайте про контейнери/LB)

cr0x@server:~$ openssl s_client -starttls smtp -connect 127.0.0.1:587 -servername mail.example.com -verify_return_error </dev/null | egrep 'subject=|Verify return code'
subject=CN = mail.example.com
Verify return code: 0 (ok)

Значення: Локально сервіс коректний. Якщо зовнішні тести падають — підозрюйте балансувальники, проксі, NAT або інший вузол, що обслуговує трафік.

Рішення: Порівняйте локальні й зовнішні відбитки сертифіката; якщо вони різні — у вас split‑brain між інстансами.

Завдання 13: Підтвердіть відбиток поданого сертифіката (зручно для порівняння вузлів)

cr0x@server:~$ echo | openssl s_client -connect mail.example.com:993 -servername mail.example.com 2>/dev/null | openssl x509 -noout -fingerprint -sha256
sha256 Fingerprint=6B:12:8E:3B:40:65:8D:29:42:0E:AD:AF:47:3F:9A:5C:0C:52:6A:0F:84:62:26:25:13:73:4C:CA:19:1C:0E:8A

Значення: Це фактичний сертифікат, який подається на цьому кінці прямо зараз.

Рішення: Запустіть ту саму команду проти кожного вузла або VIP‑цілі. Якщо відбитки відрізняються — виправте пайплайни розгортання або налаштування пулу LB перед будь‑якими діями.

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

cr0x@server:~$ awk 'BEGIN{c=0} /BEGIN CERTIFICATE/{c++} END{print c}' /etc/letsencrypt/live/mail.example.com/fullchain.pem
2

Значення: fullchain.pem містить два сертифікати (leaf + intermediate), що типово.

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

Завдання 15: Перевірте майбутнє закінчення дії для всіх обслуговуваних імен (дешевий страховий крок)

cr0x@server:~$ for host in mail.example.com smtp.example.com imap.example.com; do
> echo -n "$host 587: "
> echo | openssl s_client -starttls smtp -connect $host:587 -servername $host 2>/dev/null \
> | openssl x509 -noout -enddate
> done
mail.example.com 587: notAfter=Apr  1 00:12:02 2026 GMT
smtp.example.com 587: notAfter=Apr  1 00:12:02 2026 GMT
imap.example.com 587: notAfter=Apr  1 00:12:02 2026 GMT

Значення: Всі імена подають послідовний сертифікат з однаковим терміном дії.

Рішення: Якщо одне ім’я показує іншу дату — у вас розбіжність маршрутів/vhost або застарілий вузол.

Три корпоративні міні‑історії (анонімізовано, болісно правдоподібні)

Міні‑історія 1: Аутедж через хибне припущення (міф «fullchain необов’язковий»)

Компанія середнього розміру працювала з Postfix + Dovecot на парі ВМ за TCP‑LB. Вони оновили через ACME,
і в акуратному коміті інженер «спростив» конфіг, вказавши і для Postfix, і для Dovecot cert.pem
замість fullchain.pem. Припущення здавалося розумним: «клієнти самі добудують проміжні».

Перший симптом не був тотальною відмовою. Це були звернення в підтримку: «Outlook каже, що сертифікат недовірений».
Потім торговий представник не зміг підключитися через Wi‑Fi в готелі. Розрив прийшов і від on‑prem шлюзу партнера,
який відмовив у доставці через помилку валідації TLS. Більшість інших клієнтів продовжували працювати, бо сучасні стеки часто добирають
відсутні проміжні з кешу.

Ops провели години, ганяючись за «мережевою нестабільністю», бо симптоми відрізнялися залежно від клієнта й локації. Хелс‑чеки LB були зелені (він перевіряв лише TCP). Черги пошти повільно росли, потім різко підскочили через накопичення повторних спроб. Ніхто не зв’язував це з оновленням, бо «сертифікат дійсний» і дата закінчення в майбутньому.

Виправлення було одним рядком: подавати fullchain.pem. Та урок залишився: припущення про поведінку клієнтів не місце в продукції пошти. Ланцюг, який ви подаєте — це ланцюг, за який ви відповідаєте.

Міні‑історія 2: Оптимізація, що відвернулась (уникнення reload як «стабільність»)

Команда IT в ентерпрайзі мала строгий change‑control і їх «спалили» перезапусками.
Тому вони задекларували новий стандарт: сертифікати автоматично оновлюються, але поштові демони ніколи автоматично не перезавантажуються.
«Ми зробимо це в місячному вікні», — звучало гідно.

Тижнями все здавалося в порядку. Сертифікати оновлювалися на диску. Дашборди були зелені, бо моніторили дати закінчення, читаючи локальні файли. Потім одного дня сертифікат таки прострочився, бо місячне вікно змістилось через бізнес‑подію, і ніхто не перезавантажив демони.

Демони продовжували подавати старий, тепер вже прострочений сертифікат. Деякі клієнти тимчасово це ігнорували; інші відмовлялися одразу.
Західні помилки submission (587/465) з’явилися першими. Користувачі могли отримувати пошту (IMAP сесії стояли), але не могли відправляти.
Це саме та відмова, що породжує ескалації в керівництві: «Я не можу написати правлінню».

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

Міні‑історія 3: Нудна, але правильна практика, що врятувала день (стейджинг, канарки та відбитки)

Платіжна компанія вела пошту як «необхідне зло», але ставилась до неї як до продукції. У них були три звички:
(1) завжди тестувати те, що подається зовні, (2) розгортати сертифікати через контрольовану копію у директорію, що належить сервісу,
і (3) перезавантажувати в робочі години з канарською перевіркою, бо саме тоді люди уважні.

Одного циклу оновлення їх ACME‑клієнт видав дійсний сертифікат, але проміжний ланцюг змінився (далі дійсний, просто інший).
Невелика група старих сканерів на складі відкинула новий ланцюг. Нікому не було до цих сканерів — поки не стало, бо вони надсилали винятки з відправок.

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

Нудна практика знову перемогла. Вони не мали аутеджу; у них було контрольоване сумісне виправлення. Ось різниця між «днем оновлення» і просто вівторком.

Контрольні списки / покроковий план на день оновлення

Принципи (частина з думкою)

Ніколи не розгортайте сертифікат, який не перевірили з мережі. Перевірки на диску необхідні, але недостатні.
Подавайте повний ланцюг. Використовуйте fullchain.pem, якщо ви не робите щось навмисно дивне.
Автоматизуйте перезавантаження, але загейте його. Хук перезавантаження, який виконує handshake‑тест до й після — не «небезпечна автоматизація», це безпечніше за людей.
Не «виправляйте» проблеми сертифіката послабленням TLS. Ви не налагоджуєте — ви створюєте майбутній інцидент.
Припускайте split‑brain, поки не доведете протилежне. Багатовузлові пошти + LB + оновлення = несумісність за замовчуванням.

Покроковий план: безпечний pipeline оновлення (один вузол)

Оновіть у staging‑директорію.
Зберігайте живу директорію сертифікатів стабільною, поки не перевірите пару ключ/сертифікат і SAN.
Підтвердіть пару сертифікат/ключ локально (Завдання 2). Якщо не збігаються — зупиніться.
Перевірте структуру ланцюга (Завдання 14). Якщо лише leaf — зупиніться.
Скопіюйте файли у директорію, що належить сервісу зі стабільними правами.
Уникайте вказування демонів безпосередньо на ACME‑директорії, якщо ваша модель безпеки робить це крихким.
Перезавантажте Dovecot і Postfix (Завдання 11).
Зробіть зовнішні handshake‑тести для 25/587/465/993 (Завдання 5–8). Підтвердіть SAN і Verify return code.
Підтвердіть відбитки для аудиту (Завдання 13). Запишіть їх у нотатку до зміни.
Спостерігайте логи та черги 15–30 хвилин. Пошта іноді ламається повільно.

Покроковий план: багатовузлове середовище з балансувальником

Виберіть канарковий вузол. Віддренуйте його з пулу LB (або зменшіть вагу), але тримайте доступним для тестів.
Розгорніть сертифікат на канарковому вузлі (стейджована копія), перезавантажте служби.
Протестуйте канарку безпосередньо по IP/DNS вузла використовуючи SNI і очікуване ім’я (Завдання 5–8 плюс Завдання 13).
Поверніть канарку в пул LB і моніторьте рівень помилок та логи. Якщо чисто — продовжуйте по вузлах.
Після розгортання протестуйте VIP балансувальника і також кожен бекенд, щоб упевнитися, що відбитки співпадають (Завдання 13).

Приклад renew‑хуку: перевірити до перезавантаження і після

Це не «урок зі скрипта», це шаблон: подія оновлення викликає тести, потім reload, потім повторні тести.
Тести мають виходити з кодом помилки, якщо валідація не проходить.

cr0x@server:~$ sudo bash -lc 'cat >/usr/local/sbin/mail-tls-postrenew.sh <<'"'"'EOF'"'"'
#!/usr/bin/env bash
set -euo pipefail

HOST="mail.example.com"

precheck() {
  echo | openssl s_client -starttls smtp -connect 127.0.0.1:587 -servername "$HOST" 2>/dev/null \
    | openssl x509 -noout -enddate >/dev/null
}

postcheck() {
  echo | openssl s_client -starttls smtp -connect "$HOST:587" -servername "$HOST" -verify_return_error 2>/dev/null \
    | openssl x509 -noout -enddate
  echo | openssl s_client -connect "$HOST:993" -servername "$HOST" -verify_return_error 2>/dev/null \
    | openssl x509 -noout -enddate
}

precheck
systemctl reload postfix
systemctl reload dovecot
postcheck
EOF
chmod 0755 /usr/local/sbin/mail-tls-postrenew.sh
/usr/local/sbin/mail-tls-postrenew.sh'
notAfter=Apr  1 00:12:02 2026 GMT
notAfter=Apr  1 00:12:02 2026 GMT

Значення: До й після перевірки пройшли; перезавантаження не зламало зовнішню валідацію.

Рішення: Якщо цей скрипт падає — розглядайте це як провал деплою: відкотіться або зупиніться з rollout. Не запускайте безкінечні цикли перезавантажень.

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

Це не теоретично. Це те, що з’являється о 02:00 з дуже пильним on‑call.

1) «Він оновився, але клієнти все ще бачать старий сертифікат»

Симптоми: На диску сертифікат новий; ззовні відбиток сертифіката незмінний.
Клієнти продовжують попереджати про прострочення чи недовіру.

Корінна причина: Службу не перезавантажили, або служба вказує на інші шляхи, ніж ті, які ви оновили.
У кластерах — один вузол не отримав оновлення.

Виправлення: Перевірте поданий сертифікат командою Завдання 13. Перезавантажте демони (Завдання 11). Підтвердіть шляхи конфігу (Завдання 3–4).
Для багатовузлових розгортань: перевірте відбитки кожного вузла і виправте невідповідність.

2) «Помилка рукопотискання: невідповідність значень ключа / неправильний ключ»

Симптоми: Логи Postfix/Dovecot показують невідповідність ключів; TLS не ініціалізується; сервіс може відмовити у TLS.

Корінна причина: Сертифікат і приватний ключ не збігаються, зазвичай через копіювання лише частини файлів, змішування ECDSA і RSA,
або вказівку неправильного privkey.pem.

Виправлення: Запустіть modulus check (Завдання 2). Виправте шляхи файлів і розгорніть правильну пару.
Якщо ви одночасно змінюєте ключі — робіть це атомарно для сертифіката й ключа.

3) «Деякі клієнти працюють, деякі ні (особливо Outlook або вбудовані пристрої)»

Симптоми: Сучасні клієнти підключаються нормально; старі пристрої відмовляють з помилкою «недовіра» або «не вдається перевірити».

Корінна причина: Ви подаєте лише leaf‑сертифікат (без проміжних) або ланцюг, який ці клієнти не можуть зібрати.

Виправлення: Подавайте fullchain.pem (Завдання 3–4, 14). Якщо у вас справді є застарілі залежності,
можливо потрібно реалізувати стратегію сумісного ланцюга (але не копіюйте рішення без тестування на реальних пристроях).

4) «Невідповідність імені хоста після оновлення»

Симптоми: Помилка на кшталт «certificate subject name does not match target host name».
Відбувається на деяких портах/хостнеймах, але не на інших.

Корінна причина: Відсутні SAN‑записи, неправильне ім’я, яке використовують клієнти, або різний vhost‑конфіг на портах.
Іноді SNI‑маршрутизація неправильна (LB повертає невірний сертифікат для імені).

Виправлення: Перевірте SAN (Завдання 1). Валідовуйте з SNI за допомогою -servername (Завдання 5–8).
Випустіть сертифікат, що включає всі використовувані імена, і узгодьте DNS/клієнти, якщо є дрейф.

5) «Лише певні зовнішні домени повертають відмову з TLS required»

Симптоми: Пошта до більшості доменів проходить. Деякі домени повертають bounce з «TLS required but handshake failed».

Корінна причина: На приймальній стороні застосовано політику через MTA-STS або DANE; ваша TLS‑пропозиція чи валідація не витримує суворих правил.

Виправлення: Відтворіть з суворою валідацією (Завдання 5 з -verify_return_error).
Переконайтеся в правильності ланцюга, імені та версій протоколів. Не вимикайте TLS; виправте відповідність політиці.

6) «Перезавантаження спрацювало, а через кілька годин почалися скарги по IMAP»

Симптоми: Повільно розвиваючі збої, особливо на IMAP; не прив’язані до моменту перезавантаження.

Корінна причина: Шторм перепідключень клієнтів виявляє проблеми ланцюга або сертифіката поступово; деякі клієнти раніше кешували проміжні сертифікати і пізніше втрачають кеш.

Виправлення: Проведіть зовнішню валідацію IMAPS (Завдання 8) і підтвердіть повний ланцюг.
Моніторте логи на TLS‑попередження після оновлення. Розгляньте контрольоване вікно перепідключень, якщо потрібно скидати старі сесії.

Моніторинг і оповіщення, що ловлять це раніше за користувачів

Звичайна помилка моніторингу — перевіряти дату закінчення на файловій системі. Це показує, що є доступний,
а не те, що подано. Моніторьте з мережі, по порту, по хостнейму, з принаймні двох локацій.

Що мінімально моніторити

Термін дії поданого сертифіката на 25 (STARTTLS), 587 (STARTTLS), 465 (явний), 993 (явний) і будь‑яких POP‑портах.
Рівень успішності рукопотискань (бінарно). Або ви встановлюєте TLS і валідуєте ланцюг, або ні.
Дрейф відбитків сертифікатів між вузлами і VIP (необов’язково, але золото для діагностики split‑brain).
Глибина черги і рівень defer для Postfix. Помилки сертифікатів часто проявляються як відкладання і повтори.
Рівень TLS‑помилок у логах для Postfix і Dovecot.

Приклад: швидка перевірка терміну дії з мережі (підходить для cron)

cr0x@server:~$ bash -lc 'host=mail.example.com
for p in 465 993; do
  echo -n "$host:$p "
  echo | openssl s_client -connect $host:$p -servername $host 2>/dev/null | openssl x509 -noout -enddate
done'
mail.example.com:465 notAfter=Apr  1 00:12:02 2026 GMT
mail.example.com:993 notAfter=Apr  1 00:12:02 2026 GMT

Значення: Термін дії поданого сертифіката видно і він послідовний на портах явного TLS.

Рішення: Оповістіть, якщо термін дії в межах вашого порога (наприклад, 14 днів) або якщо команда падає (зазвичай відсутність виводу означає помилку рукопотискання).

Сигнал з логів: знаходьте TLS‑збої швидко

cr0x@server:~$ sudo journalctl -u postfix -S "1 hour ago" --no-pager | egrep -i 'tls|handshake|SSL|certificate|verify|alert' | tail -n 20
Jan 04 11:02:07 mail postfix/smtpd[22911]: warning: TLS library problem: error:0A000086:SSL routines::certificate verify failed
Jan 04 11:02:07 mail postfix/smtpd[22911]: warning: TLS library problem: error:0A000418:SSL routines::tlsv1 alert unknown ca

Значення: Є активні TLS‑помилки. «unknown ca» часто вказує на проблему з ланцюгом або довірою клієнта.

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

Жарт №2: Єдина річ, що оновлюється швидше за сертифікат Let’s Encrypt — це чутка про відмову електронної пошти в корпоративному чаті.

Загартовування: ланцюжки, шифри, SNI, DANE, MTA-STS і реальність

За замовчуванням використовуйте fullchain, але розумійте, що це таке

fullchain.pem — це ваш leaf‑сертифікат плюс проміжні(ні), потрібні для побудови до довіреного кореня.
Більшість клієнтів не хочуть бігати шукати проміжні посеред рукопотискання.

Ваш поштовий демон зазвичай має подавати:

Leaf‑сертифікат (для mail.example.com)
Проміжний(ні) CA‑сертифікат(и)
Не кореневий CA‑сертифікат (клієнти вже мають корені; його включення може збити з пантелику деякі стеки)

SNI: мовчазна пастка в мультидоменних налаштуваннях

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

Оперативні поради:

Тестуйте завжди з -servername (Завдання 5–8). Це наближує поведінку реальних клієнтів.
Іноді тестуйте без SNI. Якщо ваш «дефолтний» сертифікат неправильний, старі клієнти можуть отримати саме його.

Версії протоколу і набори шифрів: будьте суворі, але не демонстративні

Для пошти TLS 1.2 як мінімум — розумна відправна точка. TLS 1.3 чудовий, але не варто робити з цього рису характеру.
Більша пастка — зробити полiтики надто строгими, не перевіривши наявність застарілих клієнтів.

Якщо хочете знати, що саме ви пропонуєте, перевірте напряму:

cr0x@server:~$ openssl s_client -connect mail.example.com:993 -servername mail.example.com -tls1_2 </dev/null | egrep 'Protocol|Cipher|Verify return code'
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-GCM-SHA384
Verify return code: 0 (ok)

Значення: TLS 1.2 працює і валідація проходить.

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

DANE: потужно, але змушує бути точним

DANE для SMTP використовує DNSSEC‑підписані TLSA записи, щоб сказати відправникам, який сертифікат/ключ очікувати.
Це чудово для безпеки і жахливо для недбалих оновлень.

Якщо ви використовуєте DANE, будь‑яка зміна ключа потребує оновлення TLSA. Якщо ви зафіксували SPKI leaf і міняєте ключ, не оновивши DNS,
суворі відправники вважатимуть вас недружнім.

MTA-STS: політика робить ваше «майже працює» неприйнятним

MTA-STS не зробить TLS ідеальним, але вона робить провали дієвими: якщо ви рекламуватимете політику «enforce»,
приймачі почнуть вимагати дійсне рукопотискання до правильного хостнейму.

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

Атомарність: розгортавайте як одиницю, а не окремі файли

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

Це особливо важливо на завантажених серверах, де reload може відбутися під час копіювання, створивши перехідні помилки, що
зникають «коли ви спробуєте ще раз». Саме такі інциденти найгірші: вони газлайть on‑call.

Питання та відповіді

1) Чи потрібно перезапускати Postfix/Dovecot, щоб підхопити оновлений сертифікат?

Зазвичай достатньо systemctl reload, але лише якщо демон дійсно перечитує сертифікат при reload. Підтвердіть, перевіривши поданий відбиток (Завдання 13). Якщо він не змінився — потрібен перезапуск або ваш hook перезавантаження не підключений.

2) Куди вказувати конфіги — на `cert.pem` чи на `fullchain.pem`?

Для поштових сервісів використовуйте fullchain.pem, якщо у вас немає перевіреної причини інакше. Leaf‑only часто ламає старі або суворі клієнти.

3) Чому порт 25 працює, а 587 падає (або навпаки)?

Різні слухачі, різні блоки конфігу, різні процеси або різні точки термінації (LB/проксі).
Розглядайте кожен порт як окремий продукт і тестуйте його явно (Завдання 5–7).

4) Як дізнатися, який сертифікат клієнти реально бачать?

Використовуйте openssl s_client ззовні вашої мережі і зафіксуйте відбиток (Завдання 13). Не покладайтеся на локальні файли.

5) Який найшвидший спосіб виявити split‑brain між поштовими вузлами?

Порівняйте відбитки на кожному вузлі і на VIP. Якщо два вузли подають різні сертифікати — ваш розгортання неконсистентне.
Відбитки роблять це очевидним за секунди.

6) Чи можна уникнути reload, покладаючись на hot‑reloading файлів сертифікатів?

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

7) Що щодо ECDSA‑сертифікатів — чи безпечні вони для поштових клієнтів?

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

8) Що якщо я використовую балансувальник, що термінує TLS?

Тоді оновлення — це насамперед проблема LB: оновіть сховище сертифікатів LB і валідовуйте по VIP.
Також переконайтесь, що бекенд‑TLS (якщо ви його використовуєте) правильний, але пам’ятайте, що клієнт бачить сертифікат LB.

9) Чому проблеми з IMAP з’являються пізніше, ніж з SMTP?

IMAP‑клієнти часто тримають довгі TLS‑сесії (особливо з IDLE). Клієнти submission перепідключаються частіше.
Тому submission ламається голосно й швидко; IMAP може ламатися повільно в міру оновлення сесій.

10) Чи нормально тимчасово вимкнути перевірку сертифікатів, щоб «запустити пошту»?

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

Наступні кроки (практичного плану)

Якщо хочете, щоб день оновлення проходив як буденність, зробіть наступне:

Додайте мережеві перевірки сертифікатів для 25/587/465/993 по кожному хостнейму і оповіщайте як про дату закінчення, так і про помилки рукопотискання.
Уніфікуйте розгортання повного ланцюга і перевіряйте покриття SAN перед перезавантаженням.
Реалізуйте загейчений post‑renew хук, що виконує handshake‑тести, перезавантажує служби і повторно тестує (шаблон вище).
Забезпечте атомарність і консистентність rollout по вузлах: стейджована копія, переключення сим‑лінку, перезавантаження, потім перевірка відбитків.
Запишіть ваші «швидкі діагностичні» кроки у runbook on‑call і включіть точні команди, які ви виконуватимете о 02:00.

Мета не зробити оновлення TLS захопливими. Мета — зробити їх нудними, а нудне — найбільша похвала, яку може заслужити продукційна система.