Налаштування Let's Encrypt з автоматичним оновленням SSL

Сертифікат Let's Encrypt прострочено вночі: що ламається

Прострочений сертифікат Let's Encrypt проявляється не поступово, а одразу: браузери перестають відкривати з'єднання й показують попередження про небезпечний сайт. Користувач не стане розбиратися, хто винен, — він іде.

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

Причина майже завжди одна: автопродовження не спрацювало, а дізналися про це з листа клієнта, а не з моніторингу. Let's Encrypt видає сертифікати на короткий строк і розрахований на автоматичне оновлення — ручний контроль тут не працює за визначенням.

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

Окремий випадок — ліміти на повторну видачу: після кількох невдалих спроб запит блокується на час, і «просто перезапустити» вже не допомагає.

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

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

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

Тоді сертифікат перестає бути точкою відмови, про яку згадують лише в момент аварії. Розбираємо, як це влаштувати.

Що дає автоматичне оновлення сертифікатів

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

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

З автоматичним продовженням термін перестає бути точкою ризику. Клієнт Let's Encrypt видає сертифікати на короткий період, тому оновлення запускається заздалегідь, до закінчення, і проходить без участі людини.

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

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

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

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

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

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

Тоді єдиний ризик, що залишився — зовнішній збій на стороні центру сертифікації, і на нього є зрозумілий план дій.

Способи випуску та перевірки: порівняння підходів

Вибір способу випуску та підтвердження домену визначає, наскільки автономно сертифікат буде продовжуватися далі. Помилка на цьому етапі проявляється не відразу, а через 60-90 днів, коли термін дії підходить до кінця і продовження падає мовчки. Нижче — робочі варіанти, між якими реально обирають на практиці.

Режими роботи

Ключова розвилка — де живе клієнт і як він отримує продовження. У режимі standalone клієнт піднімає свій порт на час перевірки, тому веб-сервер потрібно зупиняти — це допустимо на ізольованому вузлі, але ламає роботу при живому трафіку.

У режимі webroot перевірка йде через вже працюючий сервер, продовження не рве з'єднання, але вимагає, щоб шлях до кореня сайту був доступний процесу. У режимі DNS-01 порт взагалі не потрібен — це єдиний шлях для wildcard і для серверів за балансувальником.

Обмеження, які варто врахувати заздалегідь

У Let's Encrypt є ліміти на кількість випусків для одного домену за період і на повторні невдалі перевірки — при масовому розгортанні це впирається в квоту, якщо не кешувати проміжні результати.

Сертифікат живе 90 днів, продовження запускають за 30 днів до кінця: цього запасу вистачає, щоб зловити збій і не піти в прострочення. Для внутрішніх доменів без публічної зони DNS-01 залишається єдиним робочим варіантом.

Як ми впроваджуємо автоматизацію: етапи робіт

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

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

1. Аудит конфігурації. Збираємо поточні сертифікати, терміни їх дії та спосіб випуску. Перевіряємо, чи покриті всі імена, включно з тими, що додавали вручну й забули внести в автоматику.
2. Схема продовження. Визначаємо, де буде жити клієнт оновлення, як він отримує підтвердження володіння доменом і куди складає готові сертифікати. Фіксуємо єдину точку, щоб не було двох конкуруючих процесів.
3. Налаштування автоматичного оновлення. Прописуємо регулярну задачу із запасом за часом до закінчення терміну, додаємо перезавантаження сервісів, які тримають сертифікат у пам'яті, та повідомлення про невдалі спроби.
4. Перевірка. Проганяємо випуск на тестовому контурі, потім перевіряємо реальне продовження та відкат на попередній сертифікат. Дивимося, що ланцюжок довіри збирається коректно й старі браузери не відвалюються.
5. Моніторинг. Налаштовуємо контроль терміну дії та алерти за кілька днів до закінчення — щоб проблема випливла в нас, а не в відвідувачів.
6. Передача. Віддаємо конфігурації, схему розміщення та інструкцію з додавання нових доменів, щоб команда замовника могла розширювати список без нас.

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

Що замовник отримує на руки після робіт

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

• Конфігурації випуску та продовження — підсумкові файли веб-сервера та клієнта Let's Encrypt із випущеними сертифікатами, включно з параметрами перевірки домену та ланцюжком проміжних сертифікатів.
• Схема автоматичного оновлення — де живе завдання продовження, як воно запускається, що відбувається при невдачі та як надходить повідомлення про закінчення терміну дії.
• Схема маршрутизації трафіку — як запити перевірки домену доходять до потрібного сервісу, що налаштовано на балансувальнику та де закінчується захищена ділянка.
• Політики доступу — які облікові записи та ключі мають право випускати й відкликати сертифікати, хто і як отримує доступ до приватних ключів.
• Регламент обслуговування — періодичність перевірки термінів дії, порядок дій при збої продовження та при плановому переїзді на інший сервер.
• Інструкція з відновлення — покроковий сценарій: як заново випустити сертифікат, якщо конфігурацію втрачено або сервер перестворено з нуля.
• Журнал змін — які домени та піддомени покриті, коли змінювалися параметри, хто вносив правки.

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

Кейс: як ми прибрали нічні збої сертифікатів

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

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

Що було до

За пів року ми зафіксували три інциденти з простроченим сертифікатом, кожен — від 40 хвилин до кількох годин недоступності. Причина одна: продовження трималося на пам'яті людини, а не на процесі.

Моніторинг стежив за доступністю сайту, але не за терміном дії випуску — падіння помічали за дзвінками клієнтів, а не за алертом.

Що змінили

Налаштували автоматичне продовження через Let's Encrypt з перевіркою володіння доменом і перевипуском задовго до закінчення терміну. Додали окрему перевірку: якщо сертифікат не оновився або спливає раніше контрольного терміну — надходить повідомлення черговому, а не клієнту. Ручні операції з файлами та перезапуском сервера прибрали повністю.

Що стало

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

Чим відрізняється Let's Encrypt від платних сертифікатів?

З погляду браузера різниці немає: Let's Encrypt — звичайний DV-сертифікат від довіреного центру сертифікації, чий кореневий сертифікат попередньо встановлено в операційних системах і браузерах. З'єднання шифрується однаково, зелений замок і HTTPS відображаються так само.

Користувач не побачить, платний сертифікат чи автоматично випущений, — він побачить лише, що сайт захищено.

Ключова відмінність — термін дії та модель випуску. Платні сертифікати видають на рік і більше, Let's Encrypt — на короткий період, тому оновлення зобов'язане бути автоматичним.

Це не недолік, а дисципліна: короткий термін означає, що в разі компрометації ключа вікно ризику вимірюється днями, а не місяцями.

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

За рівнем довіри різниця проявляється у сценаріях. Безкоштовний DV-сертифікат підтверджує лише володіння доменом — цього достатньо для сайтів, інтернет-магазинів, особистих кабінетів і API.

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

Окремо — підтримка. У платного сертифіката є договір, гарантія та служба підтримки, у Let's Encrypt — спільнота й автоматизація.

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

Вибір визначається сценарієм: де потрібна перевірка організації — беруть платний, де важливі автоматизація та відсутність простоїв — Let's Encrypt. Ми налаштовуємо випуск і автооновлення так, щоб продовження йшло без втручання і без падіння доступності.

Часті технічні сумніви щодо налаштування SSL

Сумніви зазвичай ті самі: «у нас уже є сертифікати від іншого центру — доведеться все ламати?», «доменів десятками, це ручна робота?», «внутрішні сервіси взагалі не можна випускати назовні».

Розбираємо по порядку — це саме ті місця, де налаштування Let's Encrypt або проходить гладко, або перетворюється на простій.

Доменів кілька — це ручна робота для кожного?

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

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

Внутрішні сервіси не повинні бути доступні ззовні — як бути?

Для внутрішніх сервісів використовуємо підтвердження через DNS-запис: він доводить володіння доменом, не відкриваючи сервіс назовні. Так закриті панелі, тестові контури та службові адреси отримують валідний сертифікат, залишаючись недоступними з інтернету.

Перевірка володіння проходить на стороні DNS-провайдера, а сам сервіс продовжує жити у внутрішній мережі.

Сумісність зі старими клієнтами та мобільними застосунками

Сертифікати Let's Encrypt довірені для переважної більшості сучасних браузерів і мобільних платформ. Проблеми виникають лише на застарілих пристроях, де кореневий сертифікат не оновлювався роками.

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

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

Обговоримо ваше завдання і повернемося з оцінкою

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

За цими ввідними ми запропонуємо план робіт та оцінку — без зобов'язань з вашого боку і без «уточнимо пізніше».

Що описати в заявці, щоб розмова була предметною:

• Де зараз зберігаються сертифікати: на одному сервері, на балансувальнику, в зворотному проксі або роздаються по кількох вузлах.
• Як випускаються і продовжуються: вручну, за розкладом, через окремий сервіс управління сертифікатами.
• Скільки доменів і піддоменів у периметрі, включно зі службовими та staging-контурами.
• Що вже ламається: прострочені сертифікати, розсинхрон між вузлами, ручні нагадування, помилки при продовженні.
• Обмеження інфраструктури: закриті контури без зовнішнього доступу, власний центр сертифікації, вимоги щодо доступів.
• Хто відповідає за експлуатацію і які вікна для змін допустимі.

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

У плані буде послідовність кроків, зони відповідальності та точки відкату — щоб зміни не ронили робочий трафік.

Наступний крок простий: надішліть опис конфігурації у вільній формі або посилання на схему. Ми розберемо її, поставимо уточнювальні питання і повернемося з оцінкою та планом робіт з налаштування Let's Encrypt з автоматичним оновленням.