# 1. Instalează pluginul de Cloudflare pentru certbot
sudo apt install python3-certbot-dns-cloudflare
# 2. Generează certificatul wildcard cu deploy-hook pentru Nginx
sudo 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. Testează uscat (dry-run) că fluxul de renewal funcționează
sudo certbot renew --dry-runDacă ai mai multe subdomenii și vrei un singur certificat wildcard *.domeniu.ro, HTTP-01 challenge nu te mai ajută. Trebuie să treci pe DNS-01 challenge, iar dacă nu automatizezi corect reînnoirea, te trezești cu alerte în uptime monitor la 3 dimineața. Am pățit-o acum 2 ani pe un cluster cu 12 microservicii și de atunci folosesc un setup bulletproof.
Unde se rupe filmul la renewal?
Problema clasică când treci de la HTTP-01 (unde certbot punea un fișier în .well-known) la DNS-01 este că trebuie să modifici TXT record-ul _acme-challenge.domeniu.ro prin API-ul providerului tău de DNS.
Sunt două greșeli mari pe care le văd des în producție:
- Certbot reînnoiește cert-ul pe disc, dar Nginx sau Apache continuă să ruleze cu vechile chei din memorie pentru că nimeni nu a dat reload la serverul web.
- API key-ul de la furnizorul DNS expiră sau este modificat, reînnoirea eșuează silențios săptămâni la rând, iar tu afli doar când expiră certificatul definitiv.
Setup-ul curat: API Token restrâns și Certbot Plugin
Eu folosesc Cloudflare pentru DNS pe majoritatea proiectelor, dar principiul e identic și pentru AWS Route53 sau DigitalOcean. Primul pas greșit pe care îl fac mulți e să folosească Global API Key. Nu face asta! Creează un API Token cu permisiuni minime: doar Zone - DNS - Edit pe zona respectivă.
Salvezi credențialele în /etc/letsencrypt/cloudflare.ini și izolezi fișierul imediat cu chmod 600 /etc/letsencrypt/cloudflare.ini. Dacă citește altcineva fișierul ăla, îți poate prelua tot DNS-ul.
Magia din --deploy-hook
Ca să nu pici în downtime, Nginx trebuie să reîncarce certificatele imediat după ce certbot a salvat fișierele noi. Nu pune systemctl reload nginx într-un cron separat la nimereală, la ore fixe.
Când folosești opțiunea --deploy-hook "systemctl reload nginx", comanda se execută strict după ce un renewal s-a finalizat cu succes. În plus, reload trimite semnalul SIGHUP procesului master Nginx, care deschide noile fișiere .pem fără să închidă conexiunile HTTP active ale clienților. Ai practic zero drop la pachete și zero milisecunde de downtime.
Trade-off sincer: Ce faci dacă registrarul nu are API?
Aici e durerea mare. Dacă ai domeniul la un registrar local vechi care nu oferă un API pentru DNS (sau are un panou din 2008 fără integrări), automatizarea pură devine un chin.
În cazul ăsta, cea mai bună soluție tehnică pe care am aplicat-o la un client a fost să delegăm doar subdomeniul _acme-challenge.domeniu.ro prin NS record către Cloudflare (pe planul gratuit) sau AWS Route53. Mânăria asta îți permite să menții zona principală la furnizorul vechi, dar lași certbot să-și facă validarea automată prin API-ul extern fără intervenție manuală.
Voi ce API-uri DNS folosiți pentru automatizări de genul ăsta și cum vă asigurați că aveți alerte înainte să expire SSL-ul?