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

Нижче — причини, з яких продовження перестає працювати, за спаданням частоти.

1. Сертифікат продовжено, а служба його так і не перечитала

Найчастіша. certbot renew відпрацював, новий файл на диску, а nginx чи Apache тримають у пам’яті старий — і віддають його відвідувачам, доки конфігурацію не перезавантажать. Формально все добре; насправді на сайті прострочений сертифікат.

Лікування — хук, що виконується після успішного продовження:

sudo certbot renew --deploy-hook "systemctl reload nginx"

Це один раз прописується у файл продовження (/etc/letsencrypt/renewal/example.com.conf, розділ [renewalparams], рядок renew_hook) і далі працює саме.

2. Вебсервер змінився, а перевірка — ні

Перевірка HTTP-01 вимагає, щоб файл із /.well-known/acme-challenge/ віддавався звичайним HTTP. Ламається це зазвичай так:

  • у конфігурацію додали безумовне перенаправлення з HTTP на HTTPS — перевірка йде за перенаправленням і не проходить;
  • з’явилося правило location ~ /\. із deny all, що закрило всі каталоги з крапкою, включно з .well-known;
  • корінь сайту переїхав, а в налаштуваннях certbot лишився старий --webroot-path;
  • увімкнули блокування за країнами чи базову автентифікацію — і разом з усіма зачепили сервер перевірки.

Правильний порядок у конфігурації: спершу окремий location для /.well-known/acme-challenge/ і лише потім загальне перенаправлення.

3. Таймер вимкнено

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

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

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

4. Домен більше не вказує сюди

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

5. Ви досягли обмежень частоти

Let’s Encrypt обмежує кількість сертифікатів на домен за тиждень. Зазвичай це результат циклу «не вийшло, спробую ще раз» під час налагодження. Для експериментів є тестовий сервер (--dry-run або --test-cert), і користуватися ним треба до вичерпання ліміту, а не після.

Перевіряйте те, що віддається, а не те, що лежить

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

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

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

Заразом перевірте ланцюжок:

echo | openssl s_client -connect example.com:443 -servername example.com -showcerts 2>/dev/null | grep -c 'BEGIN CERTIFICATE'

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

За скільки днів попереджати

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

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