# 1. Creăm fișierul de credențiale securizat
cat <<EOF > /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = abc123your_restricted_token_here
EOF
chmod 600 /etc/letsencrypt/cloudflare.ini
# 2. Generăm certificatul wildcard și setăm deploy-hook-ul
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 30 \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--deploy-hook "systemctl reload nginx" \
--non-interactive \
--agree-tos \
-m admin@domeniu.ro
# 3. Testăm că reînnoirea automată funcționează corect
certbot renew --dry-runDacă administrezi o aplicație SaaS sau o rețea de site-uri cu subdomenii dinamice, un certificat wildcard (*.domeniu.ro) îți economisește ore bune de configurare. Problema apare când trebuie să-l reînnoiești, pentru că mecanismul clasic HTTP-01 nu funcționează pe wildcard-uri — ești obligat să treci pe DNS-01 challenge. În postarea asta îți arăt cum am scăpat definitiv de frica expirării certificatelor pe un cluster cu 15 subdomenii, automatizând totul până la nivel de reload de Nginx.
Unde greșește lumea când trece pe DNS-01
Prima dată când am avut nevoie de wildcard, am rulat comanda clasică certbot certonly --manual --preferred-challenges dns. Certbot mi-a cerut să adaug manual un record TXT numit _acme-challenge în panoul de DNS. Am pus recordul, am dat Enter, certificatul s-a generat și m-am declarat mulțumit.
După 80 de zile, supriză: site-ul a intrat în atenționare de securitate. Reînnoirea automată prin certbot renew eșua tăcut în fundal. De ce? Pentru că modul --manual nu poate fi executat de un cronjob fără un script de hook care să adauge și să șteargă TXT-ul prin API-ul providerului tău de DNS.
Soluția curată: Certbot cu plugin dedicat de DNS
Ca să meargă totul pe autopilot, ai nevoie de un plugin certbot specific pentru furnizorul tău de DNS (Cloudflare, Hetzner, DigitalOcean, Route53 etc.). Eu folosesc Cloudflare în 90% din proiecte, dar logica e identică peste tot.
Pasul critic este crearea unui API Token restriționat. NU folosi API Key-ul global! Generează un token cu permisiuni de editare stricte doar pe zona DNS a domeniului respectiv (Zone.DNS - Edit). Dacă cineva îți compromite serverul web, măcar nu-ți poate fura tot contul de DNS.
Un mic trade-off de menționat: plugin-ul trebuie să aștepte propagarea recordului TXT înainte ca serverele Let's Encrypt să valideze cererea. Uneori durează 10 secunde, alteori 60. Parametrul --dns-cloudflare-propagation-seconds 30 previne rateurile cauzate de latența DNS-ului.
Reload fără downtime pe Nginx sau Apache
După ce certificatul este generat și salvat pe disc în /etc/letsencrypt/live/domeniu.ro/, procesul de web server trebuie să știe că fișierele s-au schimbat. Mulți juniori pun în cron systemctl restart nginx. Asta e o greșeală care taie conexiunile active pe loc.
La un proiect cu 8k utilizatori simultani, un restart în mijlocul zilei însemna deconectări de WebSocket-uri și request-uri de API picate. Folosește întotdeauna --deploy-hook "systemctl reload nginx". Comanda de reload face hot-swap pe procesele worker: cele vechi termină cererile existente, iar cele noi preiau traficul cu noul certificat SSL deja încărcat în memorie.
Cum testezi fără să atingi limita de rate-limit
Let's Encrypt are limite destul de drastice pentru eșecuri repetate (5 eșecuri pe oră pe domeniu). Când configurezi scriptul prima dată, adaugă mereu flag-ul --dry-run sau folosește mediul de staging (--dry-run simulează tot fluxul, inclusiv apelul de deploy hook).
Verifică și faptul că certbot.timer este activat în systemd. Pe distribuțiile moderne de Linux, pachetul certbot își instalează singur un timer care rulează de două ori pe zi și verifică dacă certificatele mai au mai puțin de 30 de zile de validitate.
Voi cum gestionați wildcard-urile în infrastructurile voastre? Folosiți Certbot cu plugin-uri de DNS sau ați trecut deja pe Cert-Manager în Kubernetes / Traefik cu ACME integrat?