Cum setezi Let's Encrypt wildcard prin DNS-01 fără să riști downtime la reînnoire

Generarea unui certificat wildcard cu Let's Encrypt e simplă la început, dar devine un coșmar când trebuie să-l reînnoiești automat fără să oprești serverul sau să riști downtime. Am pățit-o acum doi ani pe un proiect cu 24 de subdomenii active, când m-am trezit cu erori de SSL deși certificatul pe disc era proaspăt reînnoit. În ghidul ăsta îți arăt cum să configurezi corect DNS-01 challenge și hook-ul de reload ca să uiți definitiv de mentenanța asta.

De ce DNS-01 și care este compromisul?

Dacă pentru un domeniu simplu folosești HTTP-01 challenge (clasicul folder .well-known/acme-challenge), pentru wildcard (*.domeniu.ro) ești obligat să folosești DNS-01. Let's Encrypt vrea să demonstrezi că deții zona DNS adăugând un record TXT temporar numit _acme-challenge.domeniu.ro.

Trade-off-ul sincer: Metoda asta e genială pentru că nu trebuie să ai porturile 80 sau 443 deschise către internet pe serverul unde generezi certificatul (util pentru medii de staging sau servere interne). Însă vine cu un risc de securitate. Trebuie să stochezi un API token de la providerul tău de DNS (Cloudflare, Route53, DigitalOcean) direct pe serverul web. Dacă cineva îți compromite serverul de Nginx și găsește token-ul cu drepturi de scriere pe toată zona DNS, îți poate deturna domeniul imediat.

Sfatul meu? Nu folosi cheia API globală. Creează un token API limitat strict la permisiunea de Zone.DNS:Edit pentru domeniul respectiv.

Setup-ul curat cu Certbot și Cloudflare

La un proiect cu vreo 8k useri activi, am trecut totul pe Cloudflare și am folosit pluginul oficial de certbot. Nu face greșeala să scrii scripturi custom de bash cu curl care pun recordul în API și apoi dau sleep 5 minute. Certbot are pluginuri gata scrise care se ocupă singure de adăugarea recordului, așteaptă propagarea și apoi fac curățenie în DNS.

Pentru Debian/Ubuntu, instalezi pluginul rapid: sudo apt install python3-certbot-dns-cloudflare

Creezi un fișier de configurare securizat în /etc/letsencrypt/cloudflare.ini și îi dai neapărat chmod 600 ca să-l poată citi doar userul root.

Cum eviți downtime-ul: Găselnița cu --deploy-hook

Aici se strică treaba de obicei și apar tânguielile pe forumuri. Certbot are un cronjob automat (sau systemd timer) care rulează de două ori pe zi și reînnoiește certificatul când mai are sub 30 de zile de valabilitate.

Certificatul se descarcă frumos pe disc în /etc/letsencrypt/live/, dar Nginx sau Apache continuă să folosească vechiul certificat pe care îl au deja încărcat în memoria RAM. Peste 30 de zile, userii tăi vor vedea eroarea de conexiune nesigură, deși tu pe disc ai certificatul valid.

Am văzut mulți developeri care puneau cronjob-uri săptămânale care dădeau restart la Nginx. Este o abordare proastă. Un restart brutal întrerupe conexiunile HTTP active (de exemplu, descărcări mari de fișiere sau conexiuni de server-sent events).

Soluția elegantă este parametrul --deploy-hook "systemctl reload nginx". Acest hook rulează doar în momentul în care certificatul a fost într-adevăr reînnoit cu succes. Comanda de reload (nu restart) îi spune lui Nginx să citească noile fișiere de pe disc în mod "graceful": procesele vechi își termină treaba în liniște, iar noile conexiuni sunt preluate de procese noi care folosesc noul certificat. Zero secunde de downtime.

Dacă ai făcut configurarea inițială fără acest hook, poți rula din nou comanda de generare cu aceleași domenii, adăugând parametrul, iar Certbot va salva setarea în fișierul de reînnoire din /etc/letsencrypt/renewal/domeniu.conf.

Voi cum gestionați wildcard-urile în producție? Mergeți pe scripturi clasice cu Certbot sau ați trecut deja pe reverse proxy-uri moderne gen Traefik sau Caddy care fac tot dansul ăsta automat în memorie?