sudo certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 60 \
-d "domeniu.ro" \
-d "*.domeniu.ro" \
--agree-tos \
--email admin@domeniu.ro \
--non-interactive \
--deploy-hook "systemctl reload nginx"Am pățit-o acum vreo trei ani la un proiect cu peste 80 de subdomenii active de clienți. Uitasem complet că wildcard-urile de la Let's Encrypt (*.domeniu.ro) nu se pot reînnoi prin clasicul HTTP-01 challenge, ăla simplu unde pui un fișier temporar în .well-known/acme-challenge. Pentru wildcard, ești obligat prin specificația ACME să folosești DNS-01 challenge. Adică să demonstrezi că deții domeniul adăugând un record TXT în DNS.
Dacă faci asta manual la fiecare 90 de zile, ești sclavul propriei infrastructuri. O să uiți, o să prinzi un downtime de toată frumusețea într-o sâmbătă seară și o să-ți sară clienții în cap.
Sincer, care-i marele trade-off?
Ca să automatizezi DNS-01, clientul tău ACME (de obicei Certbot) are nevoie de acces API la registrarul tău de DNS (Cloudflare, AWS Route53, GoDaddy etc.).
Aici apare o problemă serioasă de securitate: dacă cineva îți sparge serverul web și găsește token-ul API de la Cloudflare cu drepturi depline, îți poate fura sau șterge toate domeniile din cont.
Soluția: Nu folosi niciodată cheia API globală. Creează un API Token în Cloudflare (sau ce provider ai) limitat strict la permisiuni de Zone.DNS:Edit pentru un singur domeniu specific. Dacă e compromis serverul, dauna e limitată doar la acea zonă DNS.
Cum am configurat noi flow-ul pe Nginx
Pe o distribuție de Ubuntu/Debian, instalăm mai întâi certbot și pluginul specific pentru providerul nostru. Luăm ca exemplu Cloudflare, fiind cel mai popular:
sudo apt update
sudo apt install certbot python3-certbot-cloudflare
Apoi, creăm fișierul de configurare unde stocăm token-ul securizat, de obicei în /etc/letsencrypt/cloudflare.ini:
dns_cloudflare_api_token = 1234567890abcdef_token_ul_tau_aici
Este extrem de important să restricționezi accesul la acest fișier. Dacă are drepturi de citire pentru oricine, certbot va refuza să ruleze din motive de securitate:
sudo chmod 600 /etc/letsencrypt/cloudflare.ini
Greșeala clasică: Cum eviți downtime-ul la reload
Cea mai mare greșeală pe care o văd la developeri este că dau restart la serverul web după ce se generează certificatul. Un systemctl restart nginx va închide brutal toate conexiunile active ale userilor preț de câteva secunde.
În schimb, trebuie să folosești opțiunea --deploy-hook. Aceasta îi spune lui Certbot să dea un simplu reload la Nginx doar atunci când certificatul chiar a fost reînnoit cu succes. Un reload reîncarcă configurația și noile certificate în memorie fără să piardă niciun pachet sau conexiune activă a utilizatorilor.
Verificarea automată este gestionată de un systemd timer instalat automat de certbot (certbot.timer), care rulează de două ori pe zi. El verifică dacă certificatul mai are mai puțin de 30 de zile valabilitate și, dacă da, declanșează scriptul de reînnoire folosind aceleași argumente cu care a fost creat inițial.
Dacă rulezi comanda din secțiunea de cod, ești asigurat. Totul se va întâmpla în fundal, iar tu nu va mai trebui să te atingi de configurare ani de zile.
Voi cum gestionați wildcard-urile în producție? Folosiți tot certbot cu DNS-01 sau ați trecut pe soluții ca Caddy sau Traefik care fac asta automat direct în procesul de reverse proxy?