Термін дії SSL: як не пропустити продовження

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

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

Чому продовження збоїть

Сертифікати Let’s Encrypt діють 90 днів, а галузь поетапно переходить на коротші строки до 2029 року. Коротші строки означають більше продовжень, а кожне продовження — шанс, що з минулого разу щось змінилося. Звичайні причини:

1. На виклик неможливо відповісти. HTTP-01 потребує доступного порту 80. Зміна в брандмауері, нове правило перенаправлення або CDN попереду це ламає.
2. DNS переїхав. Ім’я тепер вказує на інший хост, а certbot на старому сервері продовжує сертифікат, якого ніхто не бачить.
3. Таймер зник. Перебудова сервера, міграція або зміна пакета видалили запис cron чи certbot.timer.
4. Продовжено, але не перезавантажено. Новий файл на диску; nginx, балансувальник чи поштовий сервер досі тримають старий у пам’яті.
5. Забутий хост. api., staging., mail. і shop. часто мають власний сертифікат, і ні за кого з них не відповідає жодна людина.
6. Комерційний сертифікат, лист про продовження якого надходить співробітникові, що вже звільнився.
7. Ліміти запитів. Збійний цикл повторів вичерпує тижневу квоту, і справжнє продовження відхиляється.

Крок 1: складіть перелік хостів

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

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

curl -s 'https://crt.sh/?q=%25.example.com&output=json' | jq -r '.[].name_value' | sort -u

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

Крок 2: перевіряйте термін дії самі, одним рядком

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Для скрипта -checkend перетворює це на «так» або «ні». Ця команда завершується з кодом 1, якщо сертифікат спливає протягом 30 днів (2 592 000 секунд):

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -checkend 2592000

Пройдіть цикл по своєму переліку:

for h in example.com www.example.com api.example.com; do
  echo | openssl s_client -servername "$h" -connect "$h:443" 2>/dev/null \
    | openssl x509 -noout -checkend 2592000 > /dev/null || echo "RENEW SOON: $h"
done

Пошта й інші сервіси TLS — це окремі сертифікати на окремих портах. Для SMTP-відправлення використовуйте -starttls smtp -connect mail.example.com:587, для IMAPS — -connect mail.example.com:993. Безкоштовна перевірка SSL показує видавця, дату закінчення та чинність ланцюжка для будь-якого хоста HTTPS без встановлення чого-небудь.

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

Крок 3: нехай хтось ззовні стежить за сертифікатом, який отримують відвідувачі

Зовнішній монітор підключається так, як відвідувач, з правильним іменем сервера, і читає сертифікат, який справді віддається. Це ловить випадок «продовжено на диску, але не перезавантажено», який перевірка файлу пропускає.

У Tenium монітори терміну дії SSL і домену доступні від тарифу Starter ($7 на місяць). Вони сповіщають за 30, 14 і 3 дні до закінчення, а також про сертифікат, що вже прострочений, не довіряється, самопідписаний або не збігається з іменем хоста. Кожна перевірка HTTPS також записує дату закінчення, яку бачить, тож дата є на сторінці монітора й у щомісячному звіті.

Вкажіть для сповіщення контакт, який хтось читає. E-mail працює на кожному тарифі; Telegram і Slack доступні від Starter. Для акаунта клієнта сповіщайте спершу себе, а клієнта пізніше, щоб полагодити до того, як він побачить.

Особливі випадки, на яких спотикаються

• Cloudflare та інші проксі. Відвідувачі бачать сертифікат проксі, який продовжується сам. Сервер-першоджерело має власний сертифікат, і саме він може непомітно спливти та спричинити помилки 525 чи 526. Стежте за публічним іменем і додайте перевірку першоджерела, якщо можете звернутися до нього напряму.
• Wildcard і сертифікати на кілька імен. Один сертифікат для *.example.com і самого домену — це одне продовження для багатьох хостів. Усе одно стежте за кожним важливим хостом, бо розгортання може залишити один із них на старій копії.
• Тестове середовище з самопідписаним сертифікатом. Не сповіщайте про нього так, ніби це робоче середовище. Тримайте монітори тестового середовища окремо або взагалі не додавайте їх.
• Внутрішній центр сертифікації. Публічний монітор не може перевірити приватний ланцюжок; очікуйте результат «не довіряється» й стежте за такими іменами зсередини мережі.
• Порти пошти й API. Сертифікат на порту 465 чи 993 спливає незалежно від сайту, а першою ознакою стає пошта, що перестала надходити. Додавайте такі порти до переліку хостів із самого початку, а не після першого інциденту.

Крок 4: не забудьте про домен

Сертифікат і домен — два різні годинники. Домен, що спливає, «кладе» сайт, пошту й сертифікат разом, а першою ознакою часто стає сторінка-паркувальник реєстратора. Перевіряйте дату інструментом перевірки терміну дії домену, який читає реєстр через RDAP, і стежте за нею так само, як за сертифікатами. Моніторинг домену у Tenium сповіщає з тими самими кроками: за 30, 14 і 3 дні.

Для кожного домену, яким ви керуєте:

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

Крок 5: внесіть дати у звіт для клієнта

Рядок у щомісячному звіті «Сертифікат SSL чинний, лишилося 61 день; домен продовжується через 212 днів» робить дві речі. Клієнт бачить щось конкретне за оплату плану супроводу, а ви раз на місяць переглядаєте дати. На тарифі Agency звіт формується для кожного клієнта; на Pro є один звіт під вашим брендом. Дивіться звіти для клієнтів.

Чек-лист продовження, яким можна користуватися знову

• Усі хости перелічено, зокрема пошту й тестові сайти
• Кожен хост має відповідальну особу та відомий спосіб продовження
• Автопродовження перевірено один раз за допомогою certbot renew --dry-run або аналога хостингу
• Хук перезавантаження, що перезапускає вебсервер після продовження
• Зовнішній монітор терміну дії на кожному робочому хості
• Автопродовження домену ввімкнено, спосіб оплати чинний, пошта реєстратора йде на спільну скриньку
• Дати закінчення у щомісячному звіті

Якщо ви порівнюєте інструменти моніторингу переважно за перевірками сертифікатів, порівняння Tenium з Oh Dear розповідає про інструмент, побудований навколо сертифікатів і пошуку битих посилань, і каже, де він сильніший.

Поширені запитання

Читайте також

Пов’язані сторінки Tenium

• Моніторинг SSL
• Безкоштовний SSL-чекер
• Tenium проти Oh Dear
• Усі матеріали блогу
• Тарифи