Let's Encrypt wildcard cu DNS-01: automatizare curată fără downtime

Ioan Manole · 2026-07-25T18:45:39.285Z

Wildcard-urile cer DNS-01 challenge. Dacă le configurezi greșit, te trezești cu cert-ul expirat duminică noaptea. Vezi cum faci renewal automat cu Certbot și Nginx.

Postat 25 iul. 2026

bash

# 1. Permisiuni pe fisierul cu token-ul Cloudflare
chmod 600 /etc/letsencrypt/cloudflare.ini

# 2. Comanda de generare initiala cu reload hook automatizat
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d "example.com" \
  -d "*.example.com" \
  --deploy-hook "systemctl reload nginx" \
  --dry-run

Am preluat anul trecut un proiect cu vreo 18 subdomenii unde certificatele SSL erau reînnoite manual o dată la două luni. Evident că duminică la 3 dimineața a expirat cert-ul wildcard, fiindcă devops-ul care se ocupa de asta era în concediu pe o insulă fără semnal. Dacă ai wildcard (*.domeniu.ro), provocarea clasică HTTP-01 nu funcționează. Ești obligat să folosești DNS-01 challenge.

De ce pică renewal-ul automat la DNS-01?

Spre deosebire de HTTP-01, unde Certbot doar scrie un fișier temporar în .well-known/acme-challenge/, la DNS-01 serverul Let's Encrypt verifică existența unui record TXT numit _acme-challenge.domeniu.ro.

Dacă rulezi certbot --manual, prima dată merge perfect. Problema e că peste 60 de zile, cron-ul va eșua tăcut pentru că Certbot așteaptă ca un om să bage de mână recordul TXT în DNS. Luni dimineața te trezești cu tichete de la clienți că browserul le blochează accesul.

A doua cauză stupidă de downtime: Certbot își face update cu succes pe disk, dar Nginx (sau Apache) nu știe că fișierele din /etc/letsencrypt/live/ s-au schimbat. Nginx încarcă certurile în memorie la pornire/reload. Va continua să servească cert-ul vechi până pica procesul sau dai tu reload manual. Am văzut cazuri unde cert-ul era generat nou pe disk de 20 de zile, dar site-ul era jos în browser.

Setup-ul curat cu Cloudflare și Certbot

Presupunem că folosești Cloudflare pe DNS. Regula de aur: nu folosi niciodată Global API Key-ul. Dacă îți compromite cineva serverul web, îți preia tot contul de Cloudflare. Creează un API Token dedicat cu permisiune strictă Zone - DNS - Edit doar pe domeniul respectiv.

Instalezi pluginul python3-certbot-dns-cloudflare și pui tokenul într-un fișier securizat /etc/letsencrypt/cloudflare.ini. Permisiunile sunt critice: rulează chmod 600 /etc/letsencrypt/cloudflare.ini. Dacă fișierul poate fi citit de alți useri, Certbot refuză să ruleze.

Hook-ul care te salvează de downtime

Secretul automatizării stă în flag-ul --deploy-hook. Acesta salvează comanda în configurarea domeniului (/etc/letsencrypt/renewal/domeniu.ro.conf). La fiecare rulare de cron sau systemd timer (certbot renew), hook-ul se execută doar dacă certificatului i s-a emis o versiune nouă.

Trade-off-uri și la ce să fii atent

Rate limits agresive: Let's Encrypt permite doar 5 eșecuri pe oră pe cont/domeniu. Când scrii scriptul sau testezi token-ul DNS, folosește mereu --dry-run sau mediul de staging. Altfel te trezești blocat o săptămână întreagă în producție.
Propagarea DNS (Propagation Delay): Uneori Cloudflare confirmă schimbarea prin API instant, dar serverele autoritative Let's Encrypt încă văd versiunea veche din cache. Setează --dns-cloudflare-propagation-seconds 60 ca să îi dai timp recordului TXT să devină vizibil global.
Dependența de furnizorul DNS: Dacă schimbi mâine DNS-ul de pe Cloudflare pe Hetzner sau AWS Route53, scriptul de renewal va eșua tăcut. Trebuie să schimbi și pluginul de certbot corespunzător.

Voi ce soluții folosiți când aveți zone DNS la provideri mai mici sau locali care nu au un plugin oficial de Certbot? Mutați NS-urile în Cloudflare/Route53 sau scrieți hook-uri custom cu acme.sh?