Клієнт пише: «сайт каже, що з’єднання не захищене». Відвідувачі бачать повноекранне попередження браузера, форми перестають конвертувати, пошукові роботи можуть не дістатися сторінок. Прострочений SSL-сертифікат — один із найпомітніших простоїв сайту і один із тих, яких найпростіше не допустити. Якщо вам потрібна робоча схема, як виправити прострочений SSL-сертифікат, почніть із дати notAfter, а не з перезапуску всього сервера навмання.
Далі — як підтвердити, що справа саме в даті, як поставити новий сертифікат і як зробити так, щоб наступний цикл не закінчився тим самим листом від клієнта.
Крок 1. Підтвердьте, що сертифікат справді прострочений
Браузери показують помилки на кшталт NET::ERR_CERT_DATE_INVALID у Chrome або «Warning: Potential Security Risk Ahead» у Firefox. Не вгадуйте за текстом сторінки. Перевірте дати безпосередньо:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -datesДивіться на notAfter. Якщо дата в минулому, сертифікат прострочений. Якщо дата в майбутньому, у вас інша проблема: ім’я, ланцюжок, чужий сертифікат на проксі або годинник. Лікувати її поновленням «про всяк випадок» можна, але причину це не назве.
Крок 2. Відсійте схожі помилки
Не кожна помилка сертифіката — це закінчення строку:
- Чуже ім’я хоста. Сертифікат покриває
example.com, аwww.example.comу ньому немає. Браузер показує попередження на одному з двох адрес. - Немає проміжного сертифіката. В одному браузері сайт відкривається, в іншому — ні. Ланцюжок обривається, і частина клієнтів не добудовує його сама.
- Віддається не той сертифікат. CDN, балансувальник або другий віртуальний хост відповідає старим сертифікатом, тоді як на диску вже лежить новий.
- Збитий системний годинник. Якщо помилку бачить лише один пристрій, перевірте на ньому дату й час. Сертифікат при цьому може бути дійсним.
Крок 3. Поновіть і встановіть сертифікат
Спосіб залежить від того, звідки сертифікат береться.
Let’s Encrypt / certbot. Спробуйте sudo certbot renew і прочитайте помилку до кінця. Найчастіше закритий порт 80, хибний webroot або протухлі ключі DNS-challenge. Розбір типових зривів — у матеріалі certbot renewal failed.
Панель хостингу (cPanel, FastPanel, Plesk). Перевипустіть сертифікат або примусово запустіть поновлення в розділі SSL. Якщо AutoSSL зірвався, панель зазвичай пише причину. Часто це DNS, який указує на інший сервер, і валідація йде не туди.
Платний сертифікат. За потреби згенеруйте новий CSR, пройдіть перевірку, потім встановіть новий сертифікат і ланцюжок. Поки центр сертифікації не завершив валідацію, «оновити файли» на сервері нічого не змінить.
CDN або проксі (Cloudflare і схожі). Перевірте обидва сертифікати: крайовий, який бачать відвідувачі, і сертифікат оригіналу між CDN і вашим сервером. Прострочитись може будь-який із них. Валідний origin при простроченому edge виглядає як «у нас на сервері все добре», а клієнт бачить попередження.
Крок 4. Перезавантажте конфігурацію вебсервера
Дуже часта пастка: файл сертифіката на диску вже новий, а сервер і далі віддає старий із пам’яті. Перечитайте конфіг:
sudo systemctl reload nginx # or apache2 / httpdПотім перевірте тим самим openssl, а не лише власним браузером. Браузер на офісній машині може тримати старий стан, внутрішній DNS може вести на інший хост, і «у нас відкрилось» ще не означає, що відкрилось у клієнта.
Крок 5. З’ясуйте, чому строк закінчився
Прибрати попередження — половина роботи. Типові корені:
- Автопродовження перестало працювати після переїзду сервера, і новий хост сертифікат не випускає.
- Cron або таймер systemd прибрали під час прибирання «незрозумілих завдань».
- DNS домену змінився, і перевірка Let’s Encrypt більше не потрапляє на цей сервер.
- Платний сертифікат купили один раз, дату ніхто не записав, лист від центру сертифікації пішов на стару скриньку.
- Сертифікат належить піддомену, про який ніхто не пам’ятав: пошта, API, стейджинг, адмінка.
Запишіть причину в тікет до того, як закриєте його. Якщо ви не знаєте, чому строк закінчився, він закінчиться знову на тому самому місці.
Як зробити закінчення строку видимим
Перевіряйте ззовні. Дивіться сертифікат так, як його бачить відвідувач: підключенням до живого домену. Перевірка файлу на сервері не бачить проблем на CDN і балансувальниках.
Сповіщайте рано і не одну людину. Пороги 30, 14 і 7 днів. Адреса — спільна скринька або канал, не особиста пошта одного розробника.
Ведіть кожен сертифікат. Стейджинг, клієнтські піддомени, поштові сервери. Прострочений сертифікат на пошті або API ламає речі тихо: сайт із замочком відкривається, а лист або інтеграція вже ні.
Не покладайтесь на листи провайдера. Let’s Encrypt припинив надсилати нагадування про закінчення строку у 2025 році. Зірване поновлення тепер не дає жодного зовнішнього сигналу, якщо ви не стежите самі.
Готуйтесь до коротших строків. CA/Browser Forum затвердив графік скорочення максимального строку дії сертифіката: спочатку до 200 днів (із березня 2026), потім 100 днів (2027) і 47 днів (2029). Ручне поновлення перестане бути робочим режимом. Випуск треба автоматизувати, а моніторинг залишити, щоб підтверджувати, що автоматика жива.
Короткий чекліст
- [ ] Підтвердити дату закінчення через
openssl - [ ] Відсіяти проблеми імені, ланцюжка і CDN
- [ ] Поновити і встановити сертифікат
- [ ] Перечитати конфіг вебсервера
- [ ] Перевірити з мережі поза офісом
- [ ] Додати моніторинг і сповіщення для цього домену
- [ ] Записати причину
Як виправити прострочений SSL-сертифікат до кінця, а не лише файл на диску
Поновлення сертифіката — середина роботи, не фінал. Перечитайте конфіг вебсервера, потім перевірте живий сертифікат ззовні машини. Файл на диску з новою датою нічого не дає, якщо nginx і далі віддає старий ланцюжок із пам’яті. Клієнт у цей момент бачить ту саму сторінку, з якої почався тікет.
Напишіть клієнту коротку нотатку: сертифікат прострочився, його поновлено, ось нова дата закінчення. Без есе про ACME і порти. Їм потрібно знати, що оформлення замовлення знову працює і що дата наступної перевірки відома.
Потім запишіть дату туди, де її видно без SSH. Панелі хостингу, Cloudflare і «коробка під столом» випускають сертифікати паралельно. Якщо єдиний запис — «certbot стоїть», наступний зрив виглядатиме так само, як цей: попередження в браузері і пошук, хто взагалі випускав сертифікат.
Поставте нагадування за 14 днів, не за 1 день. Зірваний HTTP-01 у п’ятницю вдень стає простоєм понеділка, якщо ви дивитеся сертифікат лише напередодні закінчення. Гід із моніторингу на власному сервері — запасний контур, коли завдання поновлення мовчить і листів від центру сертифікації більше немає.
Якщо попередження було NET::ERR_CERT_DATE_INVALID, перевірте годинник на сервері так само, як сертифікат. Хибний системний час дає ту саму сторінку браузера, що й справді прострочений сертифікат. Поновлення при збитому часі попередження не прибере.
Нотатки після виправлення
Запишіть, на яке ім’я скаржився браузер. www і апекс часто сидять на різних сертифікатах. Поновити один, перечитати nginx і залишити другий простроченим виглядає як «ми полагодили», поки клієнт не відкриє іншу адресу з закладки.
Перевірте ланцюжок, не лише дату листового сертифіката. Новий лист, підписаний простроченим проміжним, усе одно дає попередження. openssl s_client показує дати, якими користуватиметься браузер, включно з проміжними.
Якщо сайт стоїть за Cloudflare або іншим проксі, сертифікат, який бачать відвідувачі, може бути не тим, що на origin. Поновлюйте той, що спереду. Origin може бути валідним, поки прострочений саме крайовий сертифікат. Перевірка openssl проти внутрішньої IP це пропустить.
Після виправлення натисніть на замочок самі з телефона, який не в офісній мережі. Кеш помилки і внутрішній DNS роблять офіс здоровим, поки решта інтернету бачить попередження.
Потім покладіть нову дату в трекер до закриття тікета. Простій, який ви щойно закрили, повториться, якщо єдиний слід — тред у Slack. Через квартал той тред ніхто не знайде, а таймер certbot знову може мовчати.
Якщо поновлений сертифікат усе одно попереджає, порівняйте серійний номер у браузері із серійним номером на диску. Вони розходяться, коли відповів не той віртуальний хост або CDN віддав старе рукостискання з кешу. Скиньте цей кеш і перевірте ще раз із мережі поза офісом, перш ніж писати клієнту, що попередження знято.
Окремо пройдіться по іменах, які ділять один сертифікат. SAN на десять доменів означає, що зрив валідації одного імені може тримати старим весь набір. Після поновлення перевірте кожне ім’я ззовні, не лише те, з якого прийшла скарга. Клієнт рідко пише про піддомен API, поки інтеграція вже не відповідає.
Залишіть у тікеті команду, якою ви перевірили дату, і вивід notAfter. Наступній людині на зміні не доведеться відновлювати діагностику з пам’яті. Якщо причина була в таймері, посиланні на webroot або в крайовому сертифікаті Cloudflare, напишіть це одним реченням. Інакше через дев’яносто днів черговий поновить файл і знову забуде перечитати nginx.
Запитання
Скільки часу займає виправлення простроченого сертифіката?
З робочим Let’s Encrypt або автоматикою панелі — хвилини, якщо порт і DNS у порядку. З платним сертифікатом, якому потрібна перевірка організації або розширена валідація, від хвилин до дня і довше: ви чекаєте центр сертифікації, а не лише сервер.
Чи б’є прострочений сертифікат по SEO?
Відвідувачів зупиняє сторінка попередження, роботи можуть не забрати сторінки, поки вона висить. Короткий простій рідко лишає довгий слід у позиціях, але конверсія падає одразу: люди не обходять попередження браузера, щоб залишити заявку.
Чи можна уникнути закінчення SSL самим лише автопродовженням?
Автопродовження знімає ручну роботу в штатному циклі. Воно вміє зриватися без листа. Поруч із ним потрібен окремий моніторинг живого сертифіката, який не залежить від того, чи запустився cron.
*Duvento стежить за закінченням SSL разом із доменами, хостингом і ліцензіями і попереджає команду заздалегідь. Спробувати.*
