# Generarea inițială a certificatului wildcard cu deploy-hook
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "exemplu.ro" \
-d "*.exemplu.ro" \
--deploy-hook "systemctl reload nginx"Am pățit-o acum doi ani la un proiect cu vreo 14k useri activi: certificatul s-a reînnoit pe disc, dar site-ul a început să dea erori de SSL. Atunci m-am prins că o configurare superficială de cron te lasă în aer exact când ți-e lumea mai dragă. Dacă vrei certificate wildcard (*.domeniu.ro), challenge-ul DNS-01 e singura cale, dar vine la pachet cu câteva capcane destul de enervante.
Spre deosebire de HTTP-01 (unde certbot pune un fișier temporar în folderul webroot), DNS-01 cere crearea unui record TXT în DNS-ul tău pentru a demonstra că deții domeniul. E mult mai sigur și singurul mod în care Let's Encrypt îți dă wildcard. Dar cum automatizezi asta fără să adaugi manual recorduri de fiecare dată?
Problema cu propagarea și capcana reîncărcării
Cea mai mare greșeală pe care o văd în tutorialele rapide e lipsa unui deploy hook. Oamenii pun în cron un simplu certbot renew și cred că au rezolvat problema.
Ce se întâmplă de fapt? Certbot rulează, își face treaba prin API-ul providerului de DNS (Cloudflare, AWS Route53, DigitalOcean), descarcă noile certificate pe disc în /etc/letsencrypt/live/ și se oprește. Nginx sau Apache rulează în continuare în memorie cu vechile certificate, care erau deja încărcate la pornire. Rezultatul? Peste 30 de zile, când expiră vechiul certificat, te trezești cu site-ul jos, deși pe disc ai fișierele noi-nouțe.
În plus, propagarea DNS nu e instantanee. Dacă scriptul verifică recordul TXT prea repede, validarea va eșua. Ai nevoie de un delay configurat corect (de obicei între 10 și 60 de secunde, în funcție de provider).
Cum se face corect: Token limitat și Deploy Hook
Mergem pe exemplul cu Cloudflare, fiind cel mai popular. Primul pas greșit pe care îl fac mulți e să folosească Global API Key. E un risc uriaș de securitate. Dacă îți sparge cineva serverul de web, îți fură cheia globală și îți poate fura sau șterge toate domeniile din cont.
Soluția? Generează un API Token cu permisiuni extrem de stricte: doar Zone:DNS:Edit pentru domeniul respectiv. Atât.
Pui token-ul într-un fișier securizat (de exemplu, /etc/letsencrypt/cloudflare.ini cu permisiuni 600), iar apoi rulezi comanda de generare.
Secretul pentru zero downtime stă în parametrul --deploy-hook. Acesta îi spune lui certbot să execute o comandă doar dacă certificatul a fost într-adevăr reînnoit cu succes. Folosim systemctl reload nginx în loc de restart. Reload-ul citește noile certificate din mers, fără să închidă conexiunile active ale userilor.
Trade-off-ul sincer
DNS-01 cu wildcard e excelent pentru că poți genera certificate pentru subdomenii interne (care nu sunt expuse în internetul public, cum ar fi un mediu de staging accesibil doar prin VPN).
Totuși, marele minus e dependența de API-ul providerului tău de DNS. Dacă API-ul Cloudflare pică exact în cele câteva zile în care certbot încearcă reînnoirea (sau schimbă structura token-urilor), procesul va eșua. De aceea, e critic să ai monitorizare externă pe data de expirare a certificatului, nu doar să te bazezi pe cron.
Voi cum gestionați reînnoirea certificatelor wildcard? Folosiți certbot cu hooks sau ați trecut deja pe soluții care fac asta nativ, cum e Caddy sau Traefik?