Як перевірити, коли закінчується термін дії SSL-сертифіката

Швидкий спосіб: замочок і онлайн-перевірка

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

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

Ручний спосіб з openssl

Одна команда виводить вікно чинності:

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

Прапорець -servername надсилає SNI, і це важливо, бо більшість серверів хостять кілька сертифікатів на одній адресі й без нього видадуть вам не той. Вивід показує notBefore і notAfter в UTC, а також для кого виданий сертифікат і хто його видав.

Щоб побачити весь ланцюжок, який надсилає сервер, а не лише кінцевий сертифікат:

openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

Прочитайте блок "Certificate chain" зверху: там мають бути кінцевий сертифікат, а потім один чи кілька проміжних. Рядок "verify error: unable to get local issuer certificate" означає, що сервер не надсилає проміжний сертифікат, що багато браузерів згладжують, а багато API-клієнтів, мобільних застосунків і старіших систем - ні.

Кінцевий сертифікат, ланцюжок і що саме спливає

У звичайному HTTPS-з'єднанні задіяні три сертифікати, і кожен має власну дату закінчення терміну дії:

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

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

Чому закінчення терміну дії - найпоширеніший збій, якому можна запобігти

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

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

Як автопоновлення все одно дає збій

Автоматичний випуск усунув більшість прострочень, але приніс набір збоїв, які важче помітити:

• Поновлення відбулося, але нічого не перезавантажилося. Новий сертифікат лежить на диску, поки веб-сервер продовжує віддавати старий із пам'яті, поки його не перезавантажать.
• Зламалася перевірка валідації. Правило переспрямування, зміна брандмауера чи новий CDN перед origin-сервером блокує шлях HTTP-виклику, тож поновлення тижнями не вдається без жодного видимого симптому.
• DNS-валідація втратила облікові дані. API-токен було змінено чи він прострочився, і DNS-виклик більше не може створити свій запис.
• Таймер поновлення не запущений. Контейнер перезібрали без завдання cron чи таймера systemd, або машину мігрували, а розклад не переніс.
• Оновився лише один вузол. За балансувальником навантаження один сервер має новий сертифікат, а інший усе ще віддає старий, тож збої виглядають переривчастими.
• Листи про поновлення пішли людині, яка вже звільнилася. Та сама проблема, тільки для купленого сертифіката.
• Сертифікат поновився, але не для всіх імен. Субдомен, доданий пізніше, відсутній у новому сертифікаті, тож саме це ім'я хоста дає збій.

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

Автоматизація перевірки

Прочитана дата дає відповідь на сьогодні, а вся проблема прострочення в тому, що воно настає в день, який ніхто не обрав перевірити. Планова перевірка сертифікатів виконує справжнє рукостискання ззовні з певним інтервалом, попереджає за встановлену кількість днів до notAfter і ловить проблеми ланцюжка та імені хоста, яких ніколи не побачить нагадування в календарі. HostTracker сповіщає електронною поштою, SMS, голосовим дзвінком, у Slack, Telegram та іншими способами, тож попередження дійде до когось раніше за сам факт прострочення. Моніторинг домену і TLS виконує цю перевірку безперервно, інструмент SSL-перевірки робить разову, а посібник як перевірити, чи відкритий порт розбирає випадок, коли рукостискання не вдається ще до того, як запропоновано сам сертифікат.