Dacă folosiți domenii de tip .local sau .arpa pentru serviciile din rețeaua proprie, probabil v-ați lovit deja de avertismentele sâcâitoare ale browserelor. Dispozitivele mobile, în special cele cu iOS sau Android, tind să fie extrem de stricte: raportează erori de securitate sau pur și simplu blochează accesul. Safari, de exemplu, mi-a făcut zile fripte cu certificatele self-signed care nu erau instalate manual pe iPhone, transformând o simplă vizualizare a unui dashboard într-o mică aventură birocratică.
Soluția elegantă pentru această problemă este utilizarea unui domeniu sau subdomeniu și validarea acestuia prin DNS-01 challenge. De exemplu, dacă aveți un domeniu propriu și îl folosiți deja la un site, puteți crea un subdomeniu dedicat rețelei interne, cum ar fi *.lan.clsb.net. Această metodă permite obținerea de certificate SSL recunoscute oficial, fără a fi nevoie să deschidem vreun port în router către internetul public. Cum DNS-urile pentru clsb.net le gestionez prin Cloudflare, am ales să detaliez procesul folosind acest ecosistem, care este extrem de prietenos cu automatizarea.
În cazul în care nu dispuneți de un domeniu propriu, merită menționat că există opțiuni gratuite, cum sunt cele .tk, dar și variante foarte ieftine de cumpărat și reînnoit, precum .xyz sau .ovh. Personal, pentru experimente am optat pentru un domeniu .ovh pentru că mai am și alte servicii la OVH; îl folosesc în principal pentru dev și mă costă în jur de 2 euro pe an. Este o cheltuială infimă pentru confortul de a avea certificate valide pe toate dispozitivele fără nicio configurare manuală pe clienți.
1. Generarea API Token în Cloudflare
Pentru ca procesul să fie complet automat, Let’s Encrypt are nevoie de permisiunea de a scrie temporar o înregistrare TXT în DNS-ul domeniului. Aceasta este „proba de proprietate” prin care se demonstrează controlul asupra acestuia. Nu trebuie să facem asta manual de fiecare dată; generăm un token API care va permite aplicațiilor să gestioneze totul automat.
Dacă n-ați mai creat niciodată un token în Cloudflare, e foarte simplu: în contul de Cloudflare, navigați la My Profile > API Tokens și selectați Create Token. Recomand folosirea template-ului Edit zone DNS. La secțiunea de permisiuni, asigurați-vă că aveți Zone – DNS – Edit, iar la resurse selectați exact domeniul pe care vreți să-l folosiți (ex: clsb.net). Copiați token-ul afișat și păstrați-l într-un loc sigur, deoarece va fi afișat o singură dată.
2. Configurarea în Nginx Proxy Manager (NPM)
Nginx Proxy Manager este „creierul” care se ocupă de cererea și reînnoirea automată a certificatelor. În interfața NPM, mergeți la secțiunea SSL Certificates și alegeți Add SSL Certificate > Let’s Encrypt. Aici intervine magia certificatelor de tip Wildcard, care acoperă orice subdomeniu.
La Domain Names, introduceți *.lan.clsb.net. Bifați opțiunea Use a DNS Challenge și alegeți Cloudflare ca provider. În câmpul de text care apare, înlocuiți <YOUR_API_TOKEN> cu token-ul pe care l-ați generat la pasul anterior. După ce salvați, NPM va comunica cu Cloudflare și va obține un certificat valid, recunoscut instantaneu de orice dispozitiv conectat la rețea.
3. Redirecționarea DNS locală
Acum că avem certificatul, trebuie să ne asigurăm că atunci când tastăm serviciu.lan.clsb.net, traficul ajunge la serverul nostru local, nu pe internet. Pentru asta, folosim un serviciu de tip AdGuard Home sau Pi-hole. Astfel, traficul rămâne 100% în rețeaua locală, dar browserul va vedea un certificat SSL valid și acel „lăcățel verde” atât de liniștitor.
În AdGuard Home, de exemplu, mergeți la Filters > DNS Rewrites și adăugați o regulă simplă: *.lan.clsb.net să trimită către IP-ul local al serverului unde rulează Docker sau serviciul respectiv. Este cea mai curată metodă de a gestiona rutele interne fără a expune adresele IP private în înregistrările DNS publice de pe internet.
Apoi configurați serviciile să folosească respectivul certificat:
Pentru că am câteva zeci de servicii hostate local, am făcut modificarea prin SQLite:
-- 1. Pentru înlocuirea domeniului în lista de proxy-uri UPDATE proxy_host SET domain_names = replace(domain_names, 'home.arpa', 'lan.clsb.net'); -- Ieșiți din sqlite .exit
În schimb, dacă le puteți număra pe degete, nu vă recomand deranjul, fiind mai simplu direct din interfața NPM.
4. Probleme cu CSRF (Cazul Seafile)
Un aspect de care m-am lovit și care s-ar putea să vă dea bătăi de cap este eroarea 403 sau problemele de tip CSRF în anumite aplicații, cum este Seafile. După trecerea la HTTPS, aplicația trebuie să știe că noul domeniu este de încredere. Pentru Seafile, de exemplu, va trebui să editați fișierul seahub_settings.py:
CSRF_TRUSTED_ORIGINS = ["https://serviciu.lan.clsb.net"]
După modificare, respectivul fișier ar trebui să arate așa:
# -*- coding: utf-8 -*-
SECRET_KEY = "k434)w#@rp=j2x0vXXXXXXXXXXXXXXXXXXXXXXXXXXXXsxbc1"
SERVICE_URL = "https://sea.lan.clsb.net"
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.mysql',
'NAME': 'seahub_db',
'USER': 'seafile',
'PASSWORD': 'XXXXXXXXX-3875-47e0-XXXX-XXXXXXXXXX',
'HOST': 'seafile-db',
'PORT': '3306',
'OPTIONS': {'charset': 'utf8mb4'},
}
}
CACHES = {
'default': {
'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
'LOCATION': 'memcached:11211',
},
'locmem': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
},
}
COMPRESS_CACHE_BACKEND = 'locmem'
TIME_ZONE = 'Europe/Madrid'
FILE_SERVER_ROOT = "https://sea.lan.clsb.net/seafhttp"
CSRF_TRUSTED_ORIGINS = ["https://sea.lan.clsb.net"]
De asemenea, asigurați-vă că în configurația de proxy din Nginx Proxy Manager trimiteți header-ul corect pentru protocol, pentru a evita confuziile de comunicare între proxy și serviciul final:
proxy_set_header X-Forwarded-Proto https;
Concluzie
Beneficiile acestei configurări sunt clare și imediate. În primul rând, obținem zero configurare pe clienți: nu mai trebuie să instalezi manual certificatele pe fiecare tabletă sau telefon din casă. În al doilea rând, securitatea este maximă pentru că nu deschidem porturile 80 sau 443 în router, eliminând o poartă de intrare pentru eventualii atacatori.
Nu în ultimul rând, avem un plus de privacy. IP-urile locale rămân invizibile pentru oricine din exterior, deoarece tot procesul de validare se bazează pe DNS, nu pe accesarea directă a serverului. Este, probabil, cel mai profesionist mod de a gestiona accesul securizat în propriul home server.
