# 1. Instalează plugin-ul de Cloudflare pentru Certbot
sudo apt install python3-certbot-dns-cloudflare
# 2. Conținutul fișierului /etc/letsencrypt/cloudflare.ini:
# dns_cloudflare_api_token = 1234567890abcdef1234567890abcdef
# 3. Rulează comanda de generare cu deploy-hook pentru Nginx
sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--preferred-challenges dns-01 \
--deploy-hook "systemctl reload nginx"Am pățit-o acum vreo trei ani la un proiect cu vreo 12.000 de useri activi pe zi. Wildcard-ul de la Let's Encrypt a expirat duminică noaptea pentru că îl generasem manual prin DNS-01 challenge și am uitat complet de el după 90 de zile. Luni dimineața a fost iad, evident.
Dacă ai nevoie de certificate wildcard (de tipul *.domeniu.ro), metoda clasică HTTP-01 (cea cu fișierul pus în .well-known/acme-challenge/) nu funcționează. Let's Encrypt are nevoie de validare prin DNS-01 ca să fie sigur că deții întreg domeniul, nu doar un server web. Asta înseamnă că trebuie să pui un record TXT în zona ta DNS. Mulți fac asta manual, dar e o capcană stupidă pe termen lung.
Setup-ul curat: Certbot + Cloudflare API
Ca să nu mai ai treabă cu reînnoirea manuală, trebuie să legi Certbot direct de API-ul providerului tău de DNS. Eu folosesc Cloudflare în 90% din cazuri, dar principiul e identic și pentru Route53 (AWS) sau DigitalOcean.
Primul pas este să nu folosești Global API Key de la Cloudflare. Este o greșeală uriașă de securitate pe care o văd la mulți juniori. Dacă îți sparge cineva serverul de Nginx, îți fură cheia globală și are acces la toate domeniile tale din cont.
Intră în Cloudflare, creează un API Token personalizat cu permisiunile:
Zone - DNS - EditZone - Zone - Read
Limitează token-ul doar la zona specifică a domeniului tău. Salvează token-ul pe server într-un fișier securizat (de exemplu, /etc/letsencrypt/cloudflare.ini) cu permisiuni stricte (chmod 600).
Trade-off-ul pe care trebuie să-l accepți
Deși am rezolvat problema reînnoirii automate, avem un compromis de securitate. Chiar și cu un token limitat, dacă serverul tău web este compromis, atacatorul poate modifica înregistrările DNS pentru acel domeniu. Poate să redirecționeze trafic sau să genereze alte certificate. Pentru proiecte critice, e mai sigur să folosești un server izolat doar pentru managementul certificatelor (un fel de bastion de CA) sau să treci pe soluții enterprise.
Pentru majoritatea proiectelor de talie medie însă, un token limitat la o singură zonă DNS este un risc acceptabil în comparație cu downtime-ul generat de un certificat expirat.
Nu uita de Nginx reload!
Certbot își va face treaba în cron, va schimba record-ul TXT prin API, va valida domeniul, va șterge record-ul TXT și va descărca noile certificate în /etc/letsencrypt/live/.
Dar Nginx nu știe că fișierele de pe disc s-au schimbat. El ține certificatele vechi în memorie. Dacă nu dai un reload la Nginx, după 90 de zile o să ai surpriza că site-ul dă eroare de conexiune securizată, deși pe disc ai noul certificat valid. Soluția este un deploy-hook simplu în comanda de Certbot sau în configurarea de renewal.
Voi cum gestionați certificatele wildcard? Mergeți pe clasicul Certbot cu cron-uri sau ați trecut deja pe Traefik / Caddy care fac totul nativ în memorie?