# /etc/letsencrypt/dnscloudflare.ini
# dns_cloudflare_api_token = TOKEN_CU_DREPTURI_RESTRICTIONATE_TXT
chmod 600 /etc/letsencrypt/dnscloudflare.ini
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/dnscloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--post-hook "systemctl reload nginx"Am pățit-o acum ceva timp pe un proiect cu 14 subdomenii dinamice când un certificat wildcard a expirat la ora 2 noaptea. Dacă folosești certificate wildcard (*.domeniu.ro) de la Let's Encrypt, știi deja că ești obligat să folosești DNS-01 challenge. Ideea e simplă, dar dacă automatizarea e făcută pe genunchi, te trezești cu downtime fix când ți-e lumea mai dragă.
De ce crapă automatizarea de DNS-01
La validarea clasică HTTP-01, certbot pune un fișier într-un folder local și serverul web îl servește. La DNS-01 e diferit: certbot trebuie să creeze o înregistrare TXT cu numele _acme-challenge în zona ta DNS, să aștepte să se propague, iar serverele Let's Encrypt o verifică.
Aici apar două mari probleme. Prima: timpul de propagare. Dacă serverele DNS ale providerului tău răspund greu și certbot verifică prea repede, validarea eșuează. A doua: reîncărcarea serverului web. Degeaba generezi certificatul nou pe disc dacă Nginx sau Apache rulează tot cu procesele vechi care au certificatul expirat în memorie.
Cum am configurat setup-ul să nu pice niciodată
La un client cu vreo 8k useri activi pe zi am trecut totul pe Certbot cu plugin-ul oficial de Cloudflare (se găsește similar și pentru Hetzner, AWS Route53 sau DigitalOcean). Trucul pe care mulți îl ignoră este parametrul de propagare. Dacă nu-i dai timp de așteptare, rata de eșec la cron job crește enorm.
În plus, hook-ul de --post-hook e sfânt. El se execută doar dacă certificatul a fost într-adevăr reînnoit cu succes, executând un reload fără să întrerupă conexiunile existente ale utilizatorilor.
Trade-off-ul sincer: Securitatea cheilor API
Automatizarea asta vine cu un risc real pe care mulți devops juniori îl ignoră. Ca certbot să poată crea înregistrări TXT, trebuie să-i dai un API Token de la providerul tău DNS. Dacă pui un token cu drepturi globale de admin și cineva îți compromite VM-ul de Nginx, ți-a luat tot DNS-ul. A doua zi îți mută domeniul pe alt IP.
Cum rezolvi asta? Nu folosi chei API master. În Cloudflare sau Route53, creezi un token restricționat strict pe zona respectivă și doar cu permisiunea DNS:Edit. E mai bine să pierzi 10 minute în dashboard-ul DNS setând permisiuni granulate decât să plângi mai târziu.
Totul merge brici de mai bine de un an pe 6 servere de producție, zero intervenție manuală, zero downtime.
Voi cum gestionați wildcard-urile în producție? Mergeți pe Certbot cu cron/systemd timers sau ați trecut toți pe acme.sh / Traefik cu cert-manager pe Kubernetes?