# 1. Cream fisierul de credentiale (de ex: /etc/letsencrypt/cloudflare.ini)
# dns_cloudflare_api_token = 1234567890abcdef1234567890abcdef
# 2. Securizam fisierul cu permisiuni restrictive
chmod 600 /etc/letsencrypt/cloudflare.ini
# 3. Rulam comanda pentru generare si configurare auto-renew
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"Dacă ai obosit să îți pui reminder în calendar la fiecare trei luni ca să reînnoiești manual certificatele wildcard Let's Encrypt, ești în locul potrivit. Am trecut prin asta la un proiect cu vreo 15 subdomenii dinamice și am automatizat totul folosind DNS-01 challenge și API-ul de la Cloudflare, fără nicio secundă de downtime. Economisești timp și scapi de stresul că îți expiră SSL-ul în weekend.
De ce ne legăm la cap cu DNS-01?
Dacă vrei un certificat wildcard (de tipul *.domeniu.ro), metoda clasică HTTP-01 (cea cu fișierul temporar servit de serverul web) nu funcționează. Protocolul ACME te obligă să folosești validarea prin DNS. Asta înseamnă că Certbot trebuie să creeze temporar un record TXT în DNS-ul tău ca să dovedească faptul că deții domeniul.
Marele avantaj? Nu ai nevoie de portul 80 deschis și poți genera certificate inclusiv pentru servere din rețeaua locală sau de staging care nu sunt expuse direct în internet.
Trade-off-ul sincer: Ai nevoie de acces API la providerul tău de DNS (Cloudflare, Route53, DigitalOcean etc.). Dacă scriptul de reînnoire e compromis, cineva îți poate modifica intrările DNS. De aceea, e critic să folosești token-uri cu drepturi limitate, nu cheia globală de administrare a contului. De exemplu, în Cloudflare, creez un token care are exclusiv permisiuni de editare pentru zona DNS a domeniului respectiv.
Setup-ul meu care rulează de 2 ani fără intervenție
Am pățit-o acum ceva timp la un client cu 8k utilizatori activi. Certificatul a expirat pentru că cineva schimbase regulile de firewall, iar validarea HTTP-01 dădea eroare. Atunci am trecut totul pe DNS-01 cu Cloudflare și am rezolvat definitiv problema.
Folosesc certbot împreună cu pluginul certbot-dns-cloudflare. Procesul e curat: instalezi pluginul, pui token-ul API într-un fișier securizat cu permisiuni 600 și lași cron-ul să-și facă treaba.
Dar aici apare marea problemă de care se lovește multă lume: Certbot reînnoiește certificatul pe disc, dar Nginx continuă să folosească varianta veche din memorie până când îi dai un restart sau reload. Iar dacă dai restart în mijlocul zilei, le tai conexiunea celor care descarcă fișiere sau sunt în mijlocul unei tranzacții.
Secretul ca să nu pici în downtime: deploy-hook
Dacă dai systemctl restart nginx, o să ai o scurtă întrerupere a serviciului. Soluția corectă este systemctl reload nginx. Acesta reîncarcă configurația și noile certificate din mers, fără să închidă conexiunile active ale utilizatorilor.
În loc să pui un cron job separat care să dea reload la Nginx în fiecare noapte "just in case", folosești parametrul --deploy-hook din Certbot. Acesta rulează comanda de reload doar atunci când certificatul a fost reînnoit cu succes.
Am economisit cam 4 ore de mentenanță pe trimestru cu abordarea asta, plus că am scăpat de stresul alertelor din monitorizare. Totul se întâmplă complet silențios, de obicei pe la 3 dimineața.
Voi cum gestionați certificatele wildcard? Mergeți pe varianta clasică cu Certbot sau ați trecut deja pe Traefik / Caddy care se ocupă singure de tot flow-ul ăsta?