Conexiune criptată (SSL/TLS) la baza de date |
|
Începând cu versiunea 2026.0.57, WinArhi poate cripta comunicația dintre aplicație și serverul bazei de date (datele locale), astfel încât datele care circulă prin rețea (oferte, comenzi, prețuri etc.) să nu poată fi citite de terți.
Funcția este disponibilă pentru serverele PostgreSQL, MySQL și Microsoft SQL Server. Pentru varianta „Local” (SQLite) nu se aplică — baza de date este un fișier pe calculatorul propriu, deci nu există transmisie prin rețea.
Unde se găsesc setările
Setările se află în fereastra de Setări, în secțiunea de conectare la datele locale (acolo unde se aleg tipul de server, numele serverului, baza de date, utilizatorul și parola). La selectarea unui server (Server MySQL, Server Microsoft SQL Server sau Server PostgreSQL) apar opțiunile de criptare:
[Captură de ecran de adăugat: WinArhi_Setari_ConectareLaDate_SSL.png — opțiunile de criptare SSL din secțiunea de conectare la datele locale, cu bifa Transmisie criptată, lista Mod, câmpul Certificat CA și bifa Acceptă certificat neverificat]
Transmisie criptată (SSL/TLS) - activează criptarea comunicației cu serverul. Disponibilă pentru toate cele trei tipuri de server.
Mod - (doar PostgreSQL) nivelul de verificare: Criptat (Require), Verificare certificat CA (VerifyCA), Verificare CA + gazdă (VerifyFull).
Certificat CA... - (PostgreSQL și MySQL) încarcă certificatul serverului; butonul X din dreapta îl șterge.
Acceptă certificat neverificat (TrustServerCertificate) - (toate cele trei servere) criptează comunicația fără a verifica identitatea serverului.
Format acceptat pentru certificat: certificatul CA trebuie să fie un certificat X.509 în format PEM (text Base64, care începe cu „-----BEGIN CERTIFICATE-----”) sau DER (binar). Formatul este recunoscut automat, indiferent de extensia fișierului (uzual .pem, .crt sau .cer). Se încarcă doar certificatul (partea publică), nu și cheia privată.
Cum se folosește
Există două scenarii, în funcție de cât de strict trebuie să fie controlul.
Scenariul A — Doar criptare (cel mai simplu)
Traficul este criptat, dar identitatea serverului nu este verificată. Protejează împotriva „ascultării” traficului în rețea, dar nu împotriva unui atac de tip „man-in-the-middle”. Nu necesită niciun certificat în aplicație.
1. Bifați Transmisie criptată (SSL/TLS).
2. Bifați Acceptă certificat neverificat (TrustServerCertificate).
3. (Doar PostgreSQL) La Mod lăsați Criptat (Require).
4. Nu este nevoie de certificat — câmpul poate rămâne gol.
5. Apăsați OK pentru salvare și reconectați-vă.
Scenariul B — Criptare + verificarea serverului (recomandat)
Traficul este criptat și aplicația verifică faptul că se conectează la serverul corect (protecție împotriva „man-in-the-middle”). Necesită certificatul serverului încărcat în aplicație.
1. Bifați Transmisie criptată (SSL/TLS).
2. Apăsați Certificat CA... și selectați certificatul serverului (fișier .crt sau .pem). Fișierul este copiat automat în subfolderul SSL al aplicației, iar în câmp se afișează doar numele lui.
3. Debifați Acceptă certificat neverificat (altfel verificarea este ignorată).
4. (Doar PostgreSQL) La Mod alegeți Verificare certificat CA (VerifyCA) sau Verificare CA + gazdă (VerifyFull).
5. Apăsați OK pentru salvare și reconectați-vă.
Important: certificatul încărcat în WinArhi trebuie să fie exact certificatul pe care îl prezintă serverul.
Cum verificați că funcționează
După conectarea la un server, în eticheta paginii de liste (în partea de sus) apare, între paranteze, serverul și starea criptării:
(192.168.0.45 - TLSv1.3) — conexiune criptată (TLS 1.3).
(192.168.0.45) fără versiune TLS — conexiune necriptată (sau starea nu a putut fi determinată).
Diferențe între servere
PostgreSQL - are toate opțiunile: Mod (Require / VerifyCA / VerifyFull), Certificat CA, Acceptă certificat neverificat.
MySQL - Certificat CA + Acceptă certificat neverificat (nu are „Mod”; criptarea se activează doar prin bifă).
Microsoft SQL Server - doar Acceptă certificat neverificat. Când este debifat, verificarea folosește validarea nativă Windows (SChannel), nu un fișier CA încărcat în aplicație.
Configurarea serverului (pentru administrator)
Pentru ca funcția să meargă, SSL trebuie activat pe serverul bazei de date.
PostgreSQL
1. Serverul are nevoie de o pereche certificat + cheie (server.crt + server.key).
2. În fișierul postgresql.conf: ssl = on, ssl_cert_file = 'server.crt', ssl_key_file = 'server.key'.
3. Cheia privată (server.key) trebuie să fie accesibilă doar contului serviciului PostgreSQL.
4. Aplicați modificările cu SELECT pg_reload_conf(); sau reporniți serviciul PostgreSQL.
Pentru Scenariul B, distribuiți certificatul (server.crt) către stațiile care se conectează și încărcați-l cu Certificat CA...
Erori frecvente și rezolvare
„SSL connection is not allowed” - SSL nu este activat pe server. Activați ssl = on pe server (vezi secțiunea de configurare).
„The certificate is not trusted by the trust provider” - certificatul serverului este auto-semnat (self-signed) și nu este de încredere. Soluții: (Scenariul A) bifați Acceptă certificat neverificat; sau (Scenariul B) încărcați certificatul cu Certificat CA..., debifați Acceptă certificat neverificat și alegeți VerifyCA sau VerifyFull.
Conexiunea merge, dar eticheta nu arată „TLS...” - verificați că Transmisie criptată este bifată și că v-ați reconectat după salvare.
La VerifyFull apare eroare de nume/gazdă - certificatul nu are adresa serverului în câmpul corespunzător. Folosiți VerifyCA (verifică certificatul, fără verificarea numelui) sau refaceți certificatul cu adresa serverului inclusă.
Note de securitate
Acceptă certificat neverificat = criptare fără verificarea identității serverului. Potrivit pentru o rețea locală de încredere; nu protejează împotriva unui atac „man-in-the-middle”.
Pentru protecție completă folosiți Scenariul B (VerifyCA sau VerifyFull) cu certificatul serverului.
Certificatul CA (.crt) este public — poate fi distribuit către stații fără riscuri. Cheia privată (server.key) rămâne doar pe server.
Aceste opțiuni se activează pe fila Conectarea la date.