Let’s Encrypt emite certificate pe nouăzeci de zile și le reînnoiește automat, de aceea, la o săptămână după configurare, nimeni nu se mai gândește la ele. Necazul este că reînnoirea automată se strică în tăcere: erorile nu le vede nimeni, iar peste trei luni vizitatorii sunt întâmpinați de avertismentul browserului. Din 2025, Let’s Encrypt nu mai trimite notificări despre expirare, așa că a dispărut și ultima aducere-aminte din exterior.

Mai jos sunt motivele pentru care reînnoirea încetează să funcționeze, în ordinea descrescătoare a frecvenței.

1. Certificatul reînnoit, dar serviciul nu l-a încărcat

Cel mai frecvent. certbot renew a rulat, noul fișier este pe disc, dar nginx sau Apache țin în continuare în memorie versiunea veche — și o livrează vizitatorilor până la reîncărcarea configurației. Formal totul este în regulă, în fapt site-ul are un certificat expirat.

Se rezolvă cu un hook rulat după o reînnoire reușită:

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

Se scrie o singură dată în fișierul de reînnoire (/etc/letsencrypt/renewal/example.com.conf, secțiunea [renewalparams], linia renew_hook) și funcționează apoi singur.

2. S-a schimbat serverul web, dar validarea a rămas

Validarea HTTP-01 cere ca fișierul din /.well-known/acme-challenge/ să fie livrat prin HTTP obișnuit. De regulă se strică astfel:

  • în configurație s-a adăugat o redirecționare necondiționată de la HTTP la HTTPS — validarea intră în redirecționare și nu trece;
  • a apărut o regulă location ~ /\. cu deny all, care închide toate directoarele cu punct, inclusiv .well-known;
  • s-a schimbat directorul rădăcină al site-ului, în timp ce în setările certbot a rămas vechiul --webroot-path;
  • s-a activat blocarea pe țări sau autentificarea de bază, sub care a intrat și serverul de validare.

Ordinea corectă în configurație: mai întâi un location separat pentru /.well-known/acme-challenge/ și abia apoi redirecționarea generală.

3. Cronometrul este dezactivat

Reînnoirea este pornită de un cronometru systemd sau de o sarcină cron, iar ambele pot fi dezactivate din greșeală la depanare sau pierdute la mutarea serverului.

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

A doua comandă parcurge întregul ciclu de reînnoire în mod de probă, fără să consume cotele. Este singura verificare care răspunde la întrebarea „se va reînnoi peste o lună” din timp, nu după fapt.

4. Domeniul nu mai indică aici

Certificatul acoperă cinci domenii, unul dintre ele s-a mutat pe altă găzduire, DNS-ul s-a schimbat. Validarea acelui domeniu încetează să treacă, iar certbot nu reînnoiește întregul certificat — împreună cu cele patru domenii funcționale. Domeniile de prisos trebuie eliminate din certificat, nu ignorat mesajul.

5. Au fost atinse limitele

Let’s Encrypt limitează numărul de certificate per domeniu pe săptămână. De obicei este urmarea buclei „nu a mers, mai încerc o dată” din timpul depanării. Pentru experimente există un server de test (--dry-run sau --test-cert) și trebuie folosit înainte de epuizarea cotei, nu după.

Verifică ceea ce se livrează

Orice verificare bazată pe fișiere are un neajuns: fișierul poate fi proaspăt, iar vizitatorul să primească totuși certificatul vechi. Trebuie privit din partea clientului:

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

Opțiunea -servername este obligatorie: fără ea, pe un server cu mai multe site-uri primești certificatul primei gazde virtuale, nu al celei despre care era vorba. În ieșire, notAfter este data reală de expirare.

Cu aceeași ocazie verifică lanțul:

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

Dacă certificatul este unul singur, cel intermediar nu este livrat. Browserele iartă de obicei această configurație — își completează singure lanțul — în timp ce curl, aplicațiile mobile și clienții Java aruncă o eroare de validare. Acesta este clasicul „la mine se deschide totul, la client nu funcționează”.

Cu câte zile înainte să avertizezi

Treizeci de zile este un prim prag rezonabil: exact atât mai rămâne până la expirare în momentul în care certbot începe încercările de reînnoire, deci dacă până atunci nu s-a întâmplat nimic, mecanismul este stricat. Paisprezece zile este al doilea semnal și cere acțiune chiar azi. Șapte este de urgență.

Important este să urmărești toate certificatele deodată, inclusiv pe cele din afara Let’s Encrypt: cele cumpărate pe un an se uită cel mai sigur, pentru că într-un an toată lumea uită și de ele, și pe adresa cui vin notificările. O singură pagină cu lista domeniilor, datele și numărul de zile rămase închide complet subiectul — ca în demonstrația de mai jos.