# Rulează comanda de test (dry-run) pentru a valida configurarea
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" \
--dry-runDacă ai nevoie de certificate wildcard (*.domeniu.ro), metoda clasică cu HTTP-01 challenge nu funcționează și trebuie să treci pe DNS-01. Am trecut prin asta acum doi ani pe un proiect cu peste 40 de subdomenii active și am învățat pe pielea mea cum să automatizez totul corect. În postarea asta îți arăt cum setezi Certbot cu Cloudflare API ca să dormi liniștit noaptea.
De ce DNS-01 și care-i buba ascunsă
Pentru un certificat wildcard, Let's Encrypt trebuie să verifice că deții controlul întregului domeniu, nu doar al unui director web. Asta se face prin adăugarea unui record TXT (_acme-challenge.domeniu.ro) în zona ta DNS.
Trade-off-ul e destul de clar. Pe de o parte, e genial că poți genera certificate chiar și pentru servere din rețeaua internă care nu au portul 80 deschis către internet. Pe de altă parte, serverul tău web are nevoie de acces API la providerul de DNS ca să scrie acel record automat. Dacă cineva îți sparge serverul de Nginx, îți poate fura token-ul de Cloudflare sau AWS Route53 și îți poate modifica înregistrările DNS. Nu e de joacă.
Cum limităm riscul de securitate
Nu folosi niciodată token-ul master (Global API Key) de la Cloudflare. Am văzut asta la mulți juniori și mă ia capul când mă gândesc la riscuri.
Creează în schimb un token API limitat strict la permisiunea Zone:DNS:Edit pentru domeniul respectiv. Dacă acel token este vreodată compromis, atacatorul poate modifica doar DNS-ul pentru acel domeniu specific, nu îți poate fura contul cu totul.
Odată ce ai generat token-ul, salvează-l într-un fișier securizat pe server, de exemplu în /etc/letsencrypt/cloudflare.ini:
dns_cloudflare_api_token = 1234567890abcdef...
Și schimbă-i imediat permisiunile ca să fie lizibil doar de root:
chmod 600 /etc/letsencrypt/cloudflare.ini
Automatizarea și evitarea downtime-ului
Partea unde mulți o dau în bară este reîncărcarea serverului web. Certbot reînnoiește certificatul în spate, dar Nginx rulează în continuare cu cel vechi din memorie până când îi dai reload. Dacă uiți de asta, te trezești după 90 de zile că site-ul dă eroare de conexiune securizată, deși pe disc ai certificatul nou-nouț.
Soluția este să folosești opțiunea --deploy-hook. Aceasta rulează comanda de reload DOAR dacă reînnoirea a avut succes, prevenind restarturi inutile sau eșuate.
De asemenea, am setat --dns-cloudflare-propagation-seconds 60 pentru că unele servere DNS de la Cloudflare au nevoie de câteva secunde să propage recordul TXT. Dacă Certbot verifică prea repede, challenge-ul pică.
Cum testezi fără să fii blocat
Înainte de a lăsa cron-ul să ruleze, folosește mereu parametrul --dry-run. Let's Encrypt are limite stricte de request-uri eșuate pe oră și te poți trezi blocat chiar când ai mai mare nevoie să ridici producția.
După ce testul trece cu succes, Certbot își creează singur un serviciu de systemd sau un cron job în /etc/cron.d/certbot care rulează de două ori pe zi și verifică dacă certificatul mai are mai puțin de 30 de zile până la expirare. Dacă are, îl reînnoiește și rulează hook-ul de reload pentru Nginx.
Voi cum gestionați certificatele wildcard? Mergeți pe DNS-01 cu Certbot sau preferați un reverse proxy ca Traefik sau Caddy care face totul nativ în memorie?