# Solicitare certificat wildcard cu validare DNS Cloudflare și reload automat de Nginx
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--agree-tos \
-m admin@domeniu.ro \
--no-eff-email \
--deploy-hook "systemctl reload nginx"Am văzut săptămâna trecută un coleg de breaslă care se chinuia să reînnoiască manual un certificat wildcard, copiind TXT record-uri în Cloudflare ca în 2015. E o pierdere stupidă de vreme și, mai devreme sau mai târziu, o să uiți de el și te trezești cu producția picată. Am trecut și eu prin asta la un proiect mai vechi cu vreo 50 de subdomenii active și de atunci am jurat că nu mai fac nimic manual.
De ce DNS-01 și care e capcana de securitate
Dacă vrei un certificat wildcard (*.domeniu.ro), Let's Encrypt te obligă să folosești validarea prin DNS (DNS-01 challenge). Nu merge cu clasicul fișier pus în /var/www/html pe care îl folosește HTTP-01. Certbot trebuie să poată scrie temporar o înregistrare de tip TXT în zona ta DNS, să aștepte propagarea, iar apoi Let's Encrypt verifică acea cheie.
Sună simplu, dar vine cu un trade-off destul de periculos. Ca să automatizezi procesul, serverul tău de web are nevoie de credențiale de acces la providerul tău de DNS (Cloudflare, Route53, DigitalOcean etc.). Dacă cineva îți sparge serverul de Nginx și găsește cheia API globală de Cloudflare, îți poate fura instant toate domeniile.
Soluția? Nu folosi niciodată cheia master. În Cloudflare, de exemplu, generează un API Token specific, cu drepturi minime: doar "Zone:DNS:Edit" pentru zona specifică pe care o validezi.
Configurarea pas cu pas
Eu folosesc Debian/Ubuntu, așa că povestesc de pe stack-ul ăsta, dar logica e identică peste tot. Primul pas e să nu instalezi certbot prin apt-get direct dacă vrei plugin-uri DNS actualizate. Folosește snap sau instalează-l în venv ca să ai ultima versiune de certbot-dns-cloudflare (sau ce provider folosești).
După ce ai instalat plugin-ul, creează un fișier de configurare securizat, să zicem în /etc/letsencrypt/cloudflare.ini cu tokenul tău limitat. Asigură-te că fișierul e citit doar de root: chmod 600 /etc/letsencrypt/cloudflare.ini. Altfel, certbot va refuza să ruleze sau te va avertiza că ești expus.
Cum evităm downtime-ul (Deploy Hooks)
Aici e marea greșeală pe care o văd la mulți juniori. Rulează comanda, certificatul se reînnoiește pe disc în /etc/letsencrypt/live/, dar Nginx-ul continuă să servească certificatul vechi care e încă încărcat în memorie. Peste 30 de zile, site-ul dă eroare de securitate, deși pe server fișierele .pem sunt proaspete.
Nu pune cronjob-uri cretine care dau systemctl restart nginx în fiecare noapte. Nu vrei să tai conexiunile active ale utilizatorilor. Folosim --deploy-hook cu un simplu systemctl reload nginx. Un reload (SIGHUP) citește noile certificate de pe disc fără să piardă conexiunile active, obținând zero downtime.
La un proiect cu 15k useri pe oră, am redus erorile de conexiune la zero folosind exact această abordare. Certbot e destul de deștept: deploy hook-ul se execută doar dacă certificatul a fost reînnoit cu succes, nu la fiecare rulare zilnică a cronjob-ului.
Voi ce folosiți pentru wildcard-uri în producție? Mergeți pe clasicul Certbot cu scripturi, sau ați trecut deja la Traefik / Caddy care se ocupă intern de tot flow-ul de DNS-01?