Моніторинг SSL-сертифікатів: сповіщення про закінчення сертифікатів і доменів

Прострочений SSL-сертифікат - не єдиний дедлайн, який може вивести сайт офлайн: перевірка терміну дії домену HostTracker відстежує статус вашої реєстрації поряд із сертифікатами, без додаткової плати.

Монітор закінчення терміну дії SSL-сертифіката часто продають як нагадування в календарі, і закінчення терміну дії справді найпоширеніший спосіб, яким сертифікати ламаються. Але не єдиний. Кожен запуск HostTracker відкриває реальне TLS-з’єднання й оцінює сертифікат, який сервер справді видав, - і це виявляє збої, що трапляються без будь-якої зміни дати взагалі.

Під капотом монітор сертифіката - це TLS-з’єднання з хостом і портом. Порт за замовчуванням 443, і ви можете вказати інший - example.com:8443, - тож API-шлюз, альтернативний HTTPS-порт чи служба на порту з неявним TLS відстежуються точнісінько так само. Ім’я хоста надсилається через SNI, тож сервер, що хостить кілька сертифікатів на одній IP-адресі, повертає правильний.

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

• Попередження зроблено лякаючим. Повносторінкова заглушка про незахищене з’єднання - той самий екран, що браузер показує при атаці перехоплення. Відвідувачі читають це не як "їхній сертифікат закінчився", а як "цей сайт небезпечний".
• На сайті з увімкненим HSTS обійти це неможливо. Якщо ви коли-небудь надсилали заголовок Strict-Transport-Security - а мали б, - браузери повністю прибирають опцію "все одно перейти". Кожен відвідувач заблокований, доки сертифікат не замінять.
• Машини ламаються сильніше за людей. Ваш мобільний застосунок, ваші платіжні webhook-и, інтеграції ваших партнерів і кожен API-клієнт теж перевіряють сертифікат, і в жодного з них немає кнопки, щоб це обійти. Закінчення терміну дії - це повний збій інтеграції, а не лише сайту.
• Ваш власний моніторинг може показувати зелений статус. Перевірка, налаштована ігнорувати проблеми з сертифікатом, і далі звітує HTTP 200 із сервера, чий сертифікат закінчився годину тому. Застосунок цього ніколи не помітив. Саме цю прогалину й покликаний закривати монітор сертифіката.

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

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

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

HostTracker надсилає нагадування за 30 днів, 7 днів і 1 день до дати закінчення терміну дії - однаково для SSL/TLS-сертифікатів і для реєстрацій доменів. Три сходинки, а не одна, бо кожна ловить свій тип упущення: 30 днів достатньо, щоб оформити закупівлю чи полагодити зламане завдання продовження, 7 днів ловить тікет, який ніхто не підхопив, а 1 день - останній шанс до того, як браузери почнуть попереджати ваших відвідувачів.

Нагадування - це не сповіщення про збій, і HostTracker тримає їх окремо. Якщо сертифікат прямо зараз справді недійсний - прострочений, відкликаний, веде до недовіреного кореня чи виданий для іншого імені хоста, - це провалена перевірка, і вона ескалюється через ваші звичайні контакти сповіщень про збій із затримкою, яку обрав кожен з них: одразу, або через 3, 5, 15, 30 чи 60 хвилин, або через 3, 6, 12 чи 24 години.

Сповіщення надсилаються дев’ятьма каналами, які підтримує HostTracker, - електронна пошта, SMS, голосовий дзвінок, webhook, Slack, веб-пуш і месенджери Telegram, Discord та Viber. Продовженнями сертифіката й продовженнями домену зазвичай опікуються різні люди, тож додайте до списку контактів обох: нагадування, яке доходить лише до скриньки того, хто налаштував монітор, - це нагадування, яке пропустять.

Драбина вище — це і є відстеження строку дії SSL-сертифіката на практиці. Кожні шість годин HostTracker наново читає сертифікат, який ваш сервер справді віддав, і перераховує дні, що лишилися; до трьох із цих чисел прив'язане нагадування.

Три щаблі зафіксовані на 30, 7 і 1 дні, і та сама драбина працює для реєстрацій доменів, а не лише для сертифікатів. Нагадування інформаційне й саме собою ніколи не переводить монітор у недоступний стан; сертифікат, який справді недійсний — сплив, відкликаний, виданий на інше ім'я хоста або прив'язаний до недовіреного кореня, — це провалена перевірка, і вона ескалюється як будь-який інший збій.

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

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

• Вимагати дійсний ланцюжок сертифіката. За замовчуванням вимкнено, тож самопідписаний сертифікат на внутрішньому хості не провалює перевірку аптайму. Вмикайте для всього публічного.
• Вимагати надійний протокол TLS. Провалює перевірку, коли сервер погоджує щось нижче за TLS 1.2 - корисний перемикач після проєкту з посилення безпеки, щоб відкочена конфігурація не могла тихо повернути застарілий протокол.
• Блокувати слабкі шифри. Провалює перевірку, коли погоджений шифр слабший за 128 біт.
• Перевіряти відкликання сертифіката. Додає перевірку OCSP/CRL безпосередньо в перевірку доступності.

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

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

Збої, про які нам повідомляють, виглядають так:

• Cron-завдання продовження померло кілька місяців тому. Сертифікат, який воно продовжило востаннє, був дійсний 90 днів, тож збій став видимим лише на 91-й день.
• Продовження пройшло успішно, але нічого не перезавантажилося. Новий сертифікат лежить на диску, поки вебсервер, балансувальник навантаження чи контейнер продовжує обслуговувати старий з пам’яті. Кожен лог продовження звітує успіх.
• Один вузол з кількох пропустили. За балансувальником навантаження більшість запитів отримують новий сертифікат, а частина - прострочений, і саме тому уривчаста, "у мене все працює" помилка сертифіката майже завжди виявляється проблемою узгодженості флоту.
• Периметр у порядку, джерело - ні. Ваш CDN подає власний дійсний сертифікат, тоді як сертифікат джерела закінчився під ним. Усе, що звертається безпосередньо до джерела, ламається.
• Метод валідації перестав працювати. DNS-запис прибрали, шлях /.well-known/ почав перенаправляти, змінилося правило файрвола - і продовження, що на це покладалося, тихо перестало проходити.
• Wildcard-сертифікат не покрив новий піддомен. Wildcard-сертифікат покриває один рівень, тож хост, доданий на глибшому рівні, ним взагалі не покритий.

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

Доменна частина звертається до реєстру, а не до сервера. HostTracker шукає домен через RDAP - сучасного, структурованого наступника WHOIS, - визначаючи, який реєстр відповідає за ваш TLD, з власного опублікованого каталогу IANA, і повертається до класичного запиту WHOIS на порту 43 для TLD, які ще не публікують службу RDAP. Пошук виконується з фіксованою шестигодинною періодичністю, і перевірка звітує:

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

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

Потрібен повний реєстровий запис - реєстратор, сервери імен, дата створення - прямо зараз, а не як монітор? Запустіть безкоштовний пошук WHOIS і терміну дії домену; без входу в акаунт. Регулярний монітор навмисно звітує менше, бо саме термін дії та статус - те, що змінюється.

1. Спершу перевірте домен за допомогою безкоштовної миттєвої перевірки, щоб знати сьогоднішні дати закінчення терміну дії, перш ніж щось автоматизувати.
2. Якщо ви вже відстежуєте аптайм сайту, відкрийте цей монітор і увімкніть відстеження сертифіката та закінчення терміну дії домену. Жодного нового монітора, жодного додаткового запиту.
3. Для всього, аптайм чого ви не відстежуєте, - поштового хоста, внутрішнього шлюзу, альтернативного порту, - додайте окремий монітор Закінчення терміну дії сертифіката і вкажіть хост:порт. Порт 443 передбачається, якщо ви не вкажете порт.
4. Додайте монітор Закінчення терміну дії домену для кожного зареєстрованого домену, яким ви володієте, включно з захисними реєстраціями та доменами-переспрямуваннями. Саме вони спливають найчастіше, бо ніхто не стежить за доменом, на якому немає сайту.
5. Додайте до списку контактів більше однієї людини. Сертифікатами й доменами зазвичай опікуються різні команди, і нагадування, яке доходить лише до того, хто налаштував монітор, - те, що лишиться непрочитаним, коли ця людина змінить роботу.
6. Зверніть увагу на драбину нагадувань - 30, 7 і 1 день - і переконайтесь, що ваш процес продовження вкладається в 30 днів. Якщо оформлення закупівлі займає шість тижнів, обмеження не в драбині - обмеження в процесі.

Безкоштовні інструменти перевірки SSL - включно з власним інструментом HostTracker - справді корисні й відповідають на інше питання. Інструмент перевірки повідомляє стан сертифіката в момент, коли ви запитали. Моніторинг повідомляє, коли цей стан змінюється, поки ви не дивитесь, - а це єдиний момент, коли це справді має значення.

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

• Без STARTTLS. Перевірка з’єднується і одразу починає TLS-рукостискання, тож працює на будь-якому порту, що веде TLS одразу. Протоколи, що починаються у відкритому тексті й підвищуються посеред сеансу, - SMTP на 587, IMAP на 143, explicit-TLS FTP, - потребують узгодження, якого перевірка не виконує. Спрямовуйте її на порт із неявним TLS натомість.
• Дні нагадувань фіксовані на 30, 7 і 1. Наразі це не налаштування на рівні монітора.
• Недоступний сервіс відкликання фіксується, а не провалює перевірку. Це навмисно - збій OCSP центру сертифікації не є збоєм вашого сайту, - але це означає, що покриття відкликання залежить від доступності стороннього сервісу.
• Журнали Certificate Transparency не відстежуються. HostTracker повідомляє про сертифікат, який видається; він не стежить за публічними CT-журналами на предмет сертифікатів, виданих для вашого домену кимось іншим.
• Клієнтські сертифікати не задіяні. Перевірка валідовує сертифікат, який подає сервер, а не взаємне TLS-рукостискання.
• Покриття доменів залежить від реєстрів. RDAP використовується там, де TLD його публікує, і класичний WHOIS - там, де ні; невелика кількість малопоширених TLD не публікують добре ні те, ні інше, і перевірка звітує про збій пошуку, а не вдає, що знає дату.