eduardweb.
Apache & NginxIntermediar#devops#nginx#letsencrypt#dns-01#ssl

Cum am automatizat wildcard SSL prin DNS-01 fără să-mi mai bat capul cu downtime-ul

De Marian Apostol, 26 iun. 2026 · 18 vizualizări · 2 like-uri

Postat 26 iun. 2026
bash
# Generare certificat wildcard cu validare DNS Cloudflare
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  -d "domain.com" \
  -d "*.domain.com" \
  --dns-cloudflare-propagation-seconds 20 \
  --deploy-hook "nginx -s reload"

Am pățit-o acum doi ani la un proiect cu vreo 12 subdomenii active: a expirat certificatul wildcard fix sâmbătă noaptea. Clientul urla, eu eram la o bere, iar HTTP-01 challenge-ul clasic nu mergea pentru că aveam jumătate din subdomenii izolate într-o rețea internă, fără expunere în internet. Atunci am trecut totul pe DNS-01 challenge și de atunci dorm liniștit.

Dacă rulezi aplicații SaaS sau ai multe microservicii pe subdomenii diferite (de genul app.domain.com, api.domain.com), un certificat wildcard (*.domain.com) este obligatoriu. Dar reînnoirea lui automată poate deveni rapid un coșmar dacă nu înțelegi cum funcționează validarea prin DNS.

De ce DNS-01 și care e compromisul?

Spre deosebire de clasicul HTTP-01, unde Certbot pune un fișier temporar în .well-known/acme-challenge/ și Let's Encrypt îl verifică pe portul 80, DNS-01 cere să creezi un record TXT temporar în zona ta DNS (_acme-challenge.domain.com).

Marele avantaj? Nu ai nevoie de porturi deschise către exterior. Poți genera certificate valide chiar și pentru servere din spatele unui firewall strict sau din rețeaua locală.

Dar există și un trade-off destul de serios. Ca să automatizezi procesul, Certbot are nevoie de acces API la registrarul tău de DNS (Cloudflare, Route53, DigitalOcean etc.) ca să poată scrie acel record TXT. Dacă cineva îți sparge serverul web și găsește token-ul de API, îți poate manipula toate recordurile DNS. De aceea, recomandarea mea e să folosești token-uri cu permisiuni extrem de limitate (doar editare DNS pentru zona respectivă, nu acces complet pe cont).

Cum am configurat reînnoirea automată cu Cloudflare

La majoritatea proiectelor folosesc Cloudflare pentru că API-ul lor e rapid și propagarea DNS durează câteva secunde, nu ore. Am instalat pluginul de certbot pentru Cloudflare și am creat un fișier de configurare securizat, restricționat doar pentru root (permisiuni chmod 600), unde am pus token-ul API limitat.

Comanda de generare pe care o folosesc include flagul --deploy-hook. Mulți fac greșeala să dea restart la Nginx printr-un cron job separat. Dacă restartul dă fail din cauza unei greșeli de sintaxă făcute între timp în alt fișier de config, site-ul pică. Cu un reload apelat doar după ce certificatul a fost reînnoit cu succes, riscul e zero. Nginx doar reîncarcă noile certificate în memorie fără să oprească procesele active.

Ce am învățat pe pielea mea

Dacă ai DNS-ul la un provider obscur care nu are plugin oficial de Certbot, ești cam blocat. Poți folosi acme.sh care are integrări cu mai mulți provideri mici, dar tot e o bătaie de cap în plus.

De asemenea, ai grijă la TTL-ul recordurilor DNS. Dacă providerul tău are un TTL minim de 10-15 minute, Certbot va trebui să aștepte mult timp înainte ca Let's Encrypt să poată valida modificarea. La Cloudflare, cu TTL setat pe "Auto", propagarea durează cam 10-20 de secunde, deci tot procesul e gata imediat.

Voi cum gestionați wildcard-urile? Mergeți pe DNS-01 sau preferați să generați certificate individuale pentru fiecare subdomeniu în parte?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.