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: купените за година се забравят най-сигурно, защото за една година всички забравят и за тях, и на чия поща идват известията. Една страница със списък на домейните, датите и оставащите дни закрива въпроса напълно — както в демонстрацията по-долу.