Cum automatizezi certurile SSL Wildcard cu DNS-01 fără să pici producția la renewal

Corina Dobre · 2026-07-26T21:48:30.601Z

Când ai zeci de subdomenii, certificatele wildcard sunt binecuvântare, dar înnoirea lor pe DNS-01 e un minier. Află cum am configurat auto-renewal curat fără downtime.

Postat 27 iul. 2026

bash

# 1. Generare inițială wildcard + deploy hook securizat
certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d "domeniu.ro" \
  -d "*.domeniu.ro" \
  --deploy-hook "systemctl reload nginx" \
  --non-interactive \
  --agree-tos \
  -m devops@domeniu.ro

# 2. Testare dry-run pentru auto-renewal (fără downtime)
certbot renew --dry-run

M-am lovit acum vreo doi ani de problema asta când aveam de gestionat o aplicație SaaS cu peste 20 de subdomenii dinamice pe un singur cluster de Nginx. HTTP-01 challenge nu merge pentru wildcard (*.domeniu.ro), așa că Let's Encrypt te obligă să mergi pe DNS-01.

Prima dată am făcut-o ca amatorii: generat certificat manual, adăugat TXT record în DNS, copiat certificatele, dat reload la Nginx. Toate bune timp de 89 de zile, până când duminică noaptea la ora 2 s-a înroșit Slack-ul că au expirat certurile. Am economisit 3 ore de muncă viitoare automatizând totul din prima de atunci încolo.

De ce crapă renewal-ul automat la DNS-01

Spre deosebire de HTTP-01 unde Certbot pune un fișier temporar în /var/www/html și serverul de ACME îl citește instant, la DNS-01 trebuie pus un TXT record sub forma _acme-challenge.domeniu.ro.

Problema apare din două cauze:

Propagarea DNS durativă: Dacă Certbot verifică recordul înainte ca nameserverele tale să-l propage global, renewal-ul eșuează.
Lipsea automatizării cu API: Fără un plugin dedicat pentru providerul tău de DNS (Cloudflare, Route53, DigitalOcean etc.), Certbot nu are cum să scrie singur TXT record-ul.

Cum am rezolvat cu Cloudflare și Certbot Plugin

Soluția curată necesită un API Token limitat strict la zona ta DNS și pachetul python3-certbot-dns-cloudflare.

Am creat un fișier securizat la /etc/letsencrypt/cloudflare.ini cu permisiuni 600 (să nu-l citească orice proces compromised de pe server). În el pui doar token-ul cu drepturi de Zone.DNS - Edit pentru domeniul respectiv.

Comanda inițială pentru obținerea certificatului trebuie să includă --dns-cloudflare-propagation-seconds 60 ca să-i dai timp de propagare, plus un --deploy-hook care reîncarcă Nginx doar dacă certificatul s-a reînnoit cu succes.

Un trade-off sincer pe securitate

Automatizarea asta înseamnă că lași o cheie de API pe serverul de web/proxy. Dacă serverul e compromis complet, atacatorul poate modifica recordurile DNS pentru domeniul tău.

Totuși, dacă folosești Scoped Tokens (doar editare DNS pe o singură zonă, fără acces la Account/Billing/Workers), riscul e minim comparat cu beneficiul de a nu avea downtime o dată la 3 luni. Pentru infrastructuri mari (peste 50k useri), folosesc instanțe izolate doar pentru procesul ăsta de issuance, dar la un setup mediu e mai mult decât suficient.

Secretul fără downtime: Reload, nu Restart

Nu folosi niciodată systemctl restart nginx în hook-uri! restart taie conexiunile active ale utilizatorilor. Folosește nginx -s reload sau systemctl reload nginx — Nginx va spawna worker-i noi cu noile certificate, lăsând worker-ii vechi să termine request-urile în curs. Zero pachete dropate, zero erori 502.

Voi cum gestionați wildcard-urile în producție? Mergeți pe DNS API automation sau aveți un proxy centralizat Gen Traefik/Caddy care face asta out of the box?