# /etc/cron.d/certbot-wildcard
0 3 * * 1 root certbot renew \
--dns-cloudflare \
--dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
--dns-cloudflare-propagation-seconds 90 \
--deploy-hook "nginx -t && systemctl reload nginx" \
--quietAm pățit acum vreo doi ani o chestie stupidă pe un setup cu vreo 40 de subdomenii dinamice (tenants pentru un SaaS). Foloseam HTTP-01 challenge cu clasicul certbot, dar la wildcard n-ai de ales: ești obligat să mergi pe DNS-01. Partea proastă e că dacă lași reînnoirea pe pilot automat fără să înțelegi cum funcționează TTL-ul și propagarea, o să te trezești la 3 dimineața cu alerte că Nginx dă erori de certificat expirat.
Problema principală cu DNS-01 nu e generarea inițială, ci hook-ul de automatizare. Let's Encrypt verifică recordul _acme-challenge.domeniu.ro direct la name serverele tale autoritative. Dacă API-ul de la registrar (Cloudflare, Hetzner, Route53 etc.) zice „gata, am pus TXT record-ul”, dar zonele secundare încă nu l-au replicat, Certbot încearcă validarea, pică, iar după 5 încercări ești în rate-limit pe o săptămână.
Cum configurezi scriptul de cleanup și sleep
Secretul ca să nu ai downtime la renewal constă în două lucruri: propagare garantată și reload grațios de webserver (niciodată systemctl restart nginx, mereu reload).
Folosesc plugin-ul dedicat de DNS pentru furnizorul pe care am domeniul. Dacă ești pe Cloudflare, certbot-dns-cloudflare este tăticul lor, dar are o chichiță: parametrul de propagare implicit (10 secunde) e uneori prea optimist. Eu îl forțez mereu la minimum 60-90 de secunde ca să fiu sigur că a ajuns în tot clusterul lor anycast.
Un alt pont: nu rula comanda direct în crontab fără verificare de sintaxă. Dacă Nginx primește un certificat bușit sau corupt dintr-o eroare de disc, un restart dă fail și serverul rămâne jos complet. Folosește deploy-hook cu test prealabil:
--deploy-hook "nginx -t && systemctl reload nginx"
Trade-off-ul securității: API Token cu permisiuni minime
Partea nasolă la DNS-01 este că trebuie să ții pe server un token de API care are drepturi de scriere în DNS. Dacă îți sparge cineva mașina aia, îți poate deturna traficul întregului domeniu schimbând recordurile A.
Soluția decentă este un token scoped extrem de strict:
- Permisiune doar pe
Zone:DNS:Edit - Restricționat strict pe zona domeniului respectiv, nu global pe tot contul
- Dacă providerul permite (AWS Route53 o face excelent), dai acces doar pe subdomeniul
_acme-challenge.exemplu.ro, lăsând restul neatins.
După ce am pus sleep-ul de 90s și am separat credențialele cu chmod 600, n-am mai avut niciun fail de reînnoire în ultimele 18 luni pe o flotă de 3 noduri de reverse proxy. Voi cum rezolvați recordurile dinamice — mergeți pe plugin-uri native de Certbot sau rulați scripturi custom de bash cu acme.sh?