# 1. Securizăm fișierul de credențiale Cloudflare
cat <<EOF > /etc/letsencrypt/cloudflare.ini
dns_cloudflare_api_token = "cheia_ta_api_foarte_lunga_si_securizata"
EOF
chmod 600 /etc/letsencrypt/cloudflare.ini
# 2. Rulăm Certbot cu DNS-01 și reload automat la Nginx
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--agree-tos \
--email admin@domeniu.ro \
--non-interactive \
--deploy-hook "systemctl reload nginx"
# 3. Testăm dry-run-ul să fim siguri că va merge reînnoirea peste 60 de zile
certbot renew --dry-runSalutare. Am văzut destul de des problema asta pe forumuri și am pățit-o și eu acum vreo trei ani la un proiect cu peste 40 de subdomenii dinamice. Chestia cu certificatele wildcard (*.domeniu.ro) de la Let's Encrypt e că nu le poți genera prin HTTP-01 challenge (clasica validare cu fișier în .well-known). Ești obligat să folosești DNS-01 challenge. Asta înseamnă că Let's Encrypt îți cere să pui o înregistrare TXT în DNS ca să dovedești că deții domeniul.
Dacă faci asta manual, o dată la 90 de zile îți prinzi urechile. Ba uiți, ba ești în concediu, ba se propagă greu DNS-ul și îți pică site-ul în producție fix când ți-e lumea mai dragă. Am avut un client care a pierdut vreo 2000 de euro într-un weekend din cauza unui certificat expirat pe un subdomeniu de checkout. De atunci, regula mea e simplă: dacă nu e automatizat complet, nu există.
De ce DNS-01 și care e buba
La HTTP-01, Certbot pornește un server web temporar sau scrie un fișier în directorul tău web. E simplu. La wildcard-uri însă, Let's Encrypt vrea să fie sigur că controlezi întreaga zonă DNS, nu doar un server web. De asta cere acel record TXT numit _acme-challenge.domeniu.ro.
Trade-off-ul e destul de evident. Ca să automatizezi asta, Certbot are nevoie de acces API la registrarul tău de DNS (Cloudflare, Route53, DigitalOcean etc.). Dacă cineva îți sparge serverul web și îți fură cheia API de DNS, îți poate modifica toate înregistrările din domeniu. E un risc de securitate real, dar se rezolvă ușor dacă folosești token-uri cu permisiuni limitate (scrie doar în zona DNS respectivă, fără drepturi de ștergere sau modificare pe alte domenii).
Cum am configurat automatizarea cu Cloudflare
Eu folosesc Cloudflare pentru majoritatea proiectelor pentru că API-ul lor e rapid și propagarea durează câteva secunde, nu ore.
Primul pas e să nu folosești Global API Key. Mergi în Cloudflare -> My Profile -> API Tokens și creezi un token nou cu permisiunea Zone:DNS:Edit doar pentru domeniul tău.
Pe serverul cu Nginx/Apache, instalez certbot și pluginul de Cloudflare. Pe Debian/Ubuntu, de exemplu, folosesc direct python3-certbot-dns-cloudflare.
Creez un fișier de configurare securizat, să zicem /etc/letsencrypt/cloudflare.ini, unde pun token-ul. Atenție mare la permisiuni: chmod 600 pe fișierul ăla, să-l poată citi doar root.
Nginx reload fără downtime
După ce certificatul se reînnoiește în fundal, Nginx sau Apache încă folosesc în memorie vechiul certificat. Trebuie să le dai un reload. Nu restart! Restartul oprește conexiunile active, pe când reload-ul încarcă noua configurație și noile certificate asincron, fără să piardă vreun request.
În Certbot, rezolvăm asta elegant cu un deploy-hook. Adăugăm parametrul de reload direct în comanda de generare. Certbot e deștept: își face singur cronjob și va rula acel hook doar atunci când certificatul chiar a fost reînnoit cu succes, nu la fiecare rulare zilnică de verificare.
Voi cum gestionați wildcard-urile? Mergeți pe DNS-01 automatizat la nivel de sistem sau preferați reverse-proxy-uri gen Traefik sau Caddy care se ocupă singure de asta în spate?