# 1. Protejăm fișierul cu token-ul API
# /etc/letsencrypt/cloudflare.ini
# dns_cloudflare_api_token = 1234567890abcdefyourtokenhere
sudo chmod 600 /etc/letsencrypt/cloudflare.ini
# 2. Rulăm comanda inițială cu deploy-hook pentru Nginx
sudo 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"Dacă ai mai mult de 3-4 subdomenii dinamice, certificatele wildcard de la Let's Encrypt îți salvează mintea. Dar pentru wildcard ai nevoie obligatoriu de DNS-01 challenge, ceea ce înseamnă că nu mai merge simplul certbot --nginx. Am pățit-o acum un an la un proiect cu 12 subdomenii active, unde reînnoirea automată a crăpat silențios și ne-am trezit cu un downtime de 2 ore în producție chiar în mijlocul zilei.
Spre deosebire de HTTP-01 (unde Certbot pune un fișier temporar în folderul webroot), la DNS-01 Certbot trebuie să scrie un record TXT în DNS-ul tău pentru a dovedi că deții domeniul. Asta înseamnă că serverul tău are nevoie de acces API la providerul de DNS.
De ce crapă reînnoirea automată la DNS-01?
Din experiența mea, configurările de DNS-01 pică în producție din trei mari motive:
- Token-ul API expirat sau greșit configurat: Mulți folosesc token-ul global de la Cloudflare sau AWS. Pe lângă faptul că e o problemă uriașă de securitate, aceste chei se mai schimbă sau se blochează.
- Timpul de propagare (DNS propagation delay): Certbot adaugă recordul TXT și întreabă imediat serverele DNS dacă e acolo. Dacă DNS-ul tău e mai leneș, validarea eșuează. Am rezolvat asta setând manual un timp de propagare de 60 de secunde.
- Lipsa unui deploy-hook: Certificatul se reînnoiește pe disc, dar Nginx rulează în continuare cu cel vechi în memorie. Până nu dai un reload la Nginx, userii vor vedea în continuare eroarea de certificat expirat.
Cum securizăm și automatizăm procesul
Pentru a evita stocarea cheii master de Cloudflare pe server, mergi în dashboard-ul Cloudflare și creează un API Token specific. Pune-i permisiuni minime: Zone - DNS - Edit pentru zona ta specifică.
După ce ai token-ul, creezi un fișier de configurare pe server pe care îl protejezi imediat. Doar root ar trebui să aibă acces la el. Pasul următor este să rulezi comanda Certbot folosind pluginul dedicat de DNS. Evită să scrii scripturi custom de bash care apelează curl-uri în API-ul DNS-ului, pluginurile oficiale de Certbot gestionează mult mai bine curățarea recordurilor TXT după ce testul s-a terminat.
Trade-off-ul sincer: Securitate vs. Simplitate
Trebuie să fim realiști. DNS-01 are un avantaj uriaș: poți genera certificate pentru servere interne care nu sunt expuse deloc în internet public. E genial pentru medii de staging sau unelte interne de monitorizare.
Dar există și un dezavantaj major. Ții o cheie API cu drepturi de scriere în DNS direct pe un server expus. Dacă cineva îți sparge serverul web prin vreo vulnerabilitate din aplicația ta Node sau PHP, va pune mâna pe acea cheie și îți poate deturna întreg traficul DNS. De aceea, pentru infrastructuri mari, recomand să folosești un proxy dedicat (cum e Traefik sau un Nginx izolat) care doar gestionează certificatele și le distribuie securizat către celelalte mașini.
Pentru proiecte medii însă, un cronjob bine pus la punct pe o singură mașină își face treaba perfect. Certbot își instalează singur un timer de systemd sau un cron în /etc/cron.d/certbot care rulează de două ori pe zi. De fiecare dată când rulează, va vedea dacă certificatul mai are mai puțin de 30 de zile și va declanșa reînnoirea, apelând și hook-ul de reload pentru Nginx.
Tu cum îți gestionezi wildcard-urile? Mergi pe varianta asta direct din Certbot sau ai trecut deja totul în spatele unui reverse proxy care face asta automat?