# /etc/letsencrypt/cloudflare.ini trebuie sa contina:
# dns_cloudflare_api_token = 1234567890abcdef...
# Rulam comanda pentru generare si configurare auto-renew cu deploy hook
certbot certonly \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 30 \
-d domeniu.ro \
-d '*.domeniu.ro' \
--preferred-challenges dns-01 \
--deploy-hook "systemctl reload nginx" \
--non-interactive \
--agree-tos \
-m admin@domeniu.roAm pățit-o acum vreo trei ani la un proiect cu vreo 12 subdomenii dinamice și în jur de 15.000 de utilizatori unici pe zi. S-a făcut dimineață, a expirat certificatul wildcard și clienții au început să urle pe chat că văd ecrane roșii de securitate în browser. Atunci mi-am dat seama că metoda clasică HTTP-01 challenge nu mă mai ajută și trebuie să trec definitiv pe DNS-01, complet automatizat.
Dacă ai un singur domeniu, HTTP-01 e sfânt: pui un fișier temporar în .well-known/acme-challenge/ și Let's Encrypt îl verifică prin portul 80. Dar când ai nevoie de un wildcard (*.domeniu.ro), Let's Encrypt te obligă să demonstrezi că deții controlul asupra întregii zone DNS prin adăugarea unui record de tip TXT (_acme-challenge). Aici începe distracția cu automatizarea.
Compromisul de securitate pe care trebuie să-l accepți
Hai să fim sinceri de la început. Ca să automatizezi adăugarea acelui record TXT, serverul tău web (unde rulează Certbot) trebuie să poată vorbi direct cu API-ul providerului tău de DNS. Asta înseamnă că vei stoca o cheie de acces pe server.
Dacă cineva îți sparge serverul web și găsește cheia API cu acces complet (Global API Key în cazul Cloudflare), îți poate fura sau șterge toate domeniile din cont. Soluția? Folosește exclusiv API Tokens cu permisiuni limitate. În Cloudflare, creează un token care are drepturi doar de Zone:DNS:Edit pentru un singur domeniu specific, nu pentru tot contul. E un extra-pas de securitate care te salvează de la dezastru.
Cum legi Certbot de Cloudflare
După ce ai instalat Certbot și pluginul de Cloudflare (pe Ubuntu e de obicei python3-certbot-dns-cloudflare), trebuie să configurezi fișierul de credențiale. Eu îl pun în /etc/letsencrypt/cloudflare.ini și îl blochez cu chmod 600 ca să-l poată citi doar root.
După ce ai fișierul gata, comanda de generare arată destul de simplu. Magia stă în parametrii pe care îi trimiți ca să nu provoci downtime în Nginx sau Apache atunci când se face reînnoirea peste 2-3 luni.
Capcana reînnoirii: Reload vs Restart
Aici greșesc mulți. Rulează Certbot în cron, certificatul se reînnoiește pe disc, dar serverul de Nginx continuă să ruleze cu vechiul certificat din memorie. Peste câteva zile, certificatul vechi expiră în memorie și site-ul pică, deși tu pe disc ai fișierele noi.
Dacă pui în cron un systemctl restart nginx, rezolvi problema, dar provoci un downtime de 1-2 secunde și închizi brutal toate conexiunile active ale utilizatorilor. Soluția elegantă este parametrul --deploy-hook. Acesta rulează doar atunci când certificatul chiar a fost reînnoit cu succes și execută un systemctl reload nginx. Un reload face un hot-swap de configurație în memorie fără să piardă nicio conexiune activă. Zero secunde de downtime.
Voi cum gestionați certificatele wildcard? Mergeți pe rețeta clasică cu Certbot și DNS-01 sau ați trecut deja pe soluții care se ocupă singure de tot flow-ul direct în memorie, cum e Caddy?