# 1. Restricționează fișierul cu token-ul DNS
chmod 600 /etc/letsencrypt/cloudflare.ini
# 2. Comanda de emitere cu propagation delay și deploy hook
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--deploy-hook "systemctl reload nginx" \
--agree-tos \
-m admin@domeniu.ro \
--non-interactive
# 3. Testează procesul de auto-renewal
certbot renew --dry-runDacă ai un SaaS multi-tenant sau o aplicație unde generezi subdomenii on-the-fly, certificarea clasică HTTP-01 devine un calvar. Am avut un proiect cu peste 60 de subdomenii unde ne loveam constant de limita Let's Encrypt de 50 de certificate per domeniu pe săptămână. Singura soluție curată a fost un certificat wildcard (*.domeniu.ro), dar pentru asta ești obligat să folosești validarea DNS-01.
Provocarea cu DNS-01 este că nu mai e suficient ca Nginx să servească un fișier static din .well-known. Certbot trebuie să vorbească direct cu API-ul providerului tău de DNS ca să creeze un record temporar de tip TXT.
Capcana API Token-ului pe serverul web
Prima greșeală pe care o văd des: devs care pun un API Key global de Cloudflare sau AWS Route53 pe serverul de producție. Dacă îți compromite cineva Nginx-ul, are acces la toată infrastructura ta DNS.
Soluția e să generezi un token cu permisiuni minime (scoped API token). În Cloudflare, de exemplu, setezi permisiune strict de Zone - DNS - Edit doar pentru zona respectivă, nimic altceva. Salvezi credențialele într-un fișier securizat (chmod 600) și gata.
De ce crapă reînnoirea automată (și cum previi)
La DNS-01 ai două puncte mari unde lucrurile se pot strica fără să știi:
- Propagarea DNS lentă: Let's Encrypt verifică TXT record-ul imediat ce providerul zice că l-a scris, dar unele nameservere au întârzieri de 30-60 de secunde. Dacă nu configurezi un propagation delay în plugin, validarea va eșua aleatoriu.
- Reload-ul de Nginx care nu se execută: Certbot reînnoiește fișierele
.pempe disc, dar Nginx continuă să țină în memorie certificatul vechi până la primul reload. Dacă timer-ul de systemd nu apelează explicit un--deploy-hook, o să te trezești cu certificat expirat deși pe disc fișierul e nou.
Trade-off sincer: Wildcard vs Certificate individuale
Un certificat wildcard simplifică masiv configurarea de Nginx: ai un singur bloc ssl_certificate comun pentru toate vhost-urile. Nu mai stai să faci reload la webserver de fiecare dată când se înregistrează un client nou pe un subdomeniu nou.
Partea proastă? Dacă dintr-o eroare de card sau schimbare de API token reînnoirea wildcard-ului pică, îți pică absolut toate subdomeniile în același minut. La certificate individuale, picau eșalonat. De aceea e critic să testezi comanda cu --dry-run și să ai alerte pe expirarea SSL (un simplu uptime monitor care verifică TLS cu 14 zile înainte de expirare).
Voi cum gestionați wildcard-urile în producție: scripturi custom de Certbot, Caddy integrat, sau delegați totul la nivel de Cloudflare Proxy?