Autosemnat sau CA publică pentru un VPN: ce se schimbă de fapt

Ajungeți la pagina de certificate a unei configurații VPN, vedeți o opțiune autosemnată gratuită lângă o CA publică plătită, iar întrebarea sună ca o alegere de securitate. De fapt este o alegere de public. Ambele opțiuni criptează tunelul cu aceleași primitive, iar ambele devin inutile dacă cheia privată se scurge. Ce le separă este cine face afirmația despre identitatea serverului și cine este în poziția de a verifica acea afirmație.

Un certificat face două lucruri care se confundă

Un certificat leagă o cheie publică de un nume, iar cheia face munca de criptare și semnare. Semnătura de pe certificat este o declarație separată: o autoritate a verificat că numele aparține acestui deținător al cheii. Un certificat autosemnat face acea declarație despre sine, ceea ce nu este deloc o afirmație a unei terțe părți.

Site-urile publice au nevoie de versiunea cu terță parte, pentru că vizitatorii sosesc fără nicio relație prealabilă și se bazează pe depozitul de încredere al browserului. Un client VPN nu este un străin. Îi dați certificatul CA, sau fixați certificatul serverului, în profilul pe care îl instalează, astfel încât verificarea rulează exact împotriva autorității pe care ați ales-o. Nicio CA comercială nu trebuie implicată pentru ca acea verificare să însemne ceva.

Puterea sesiunii rezultate vine din dimensiunea cheii și din suita de criptare, nu de la semnatar. De aceea a numi un certificat autosemnat "mai puțin criptat" este pur și simplu greșit; el este mai puțin garantat pe scară largă, ceea ce este o altă proprietate.

Unde o CA publică își câștigă taxa

Cel mai clar caz este pagina de administrare. Dacă colegii, contractorii sau oricine altcineva fără un profil pregătit trebuie să deschidă interfața web a serverului VPN fără un avertisment al browserului, un certificat de încredere publică elimină acea frecare. Browserul se încrede deja în semnatar, așa că nu este nimic de importat și nimic de explicat.

Acea comoditate are costuri care merită numite înainte de cumpărare. Reînnoirea trebuie automatizată, altfel site-ul se strică după un calendar, certificatele publice expun numele gazdă în jurnalele de transparență a certificatelor, iar limitele de rată la emitere pedepsesc un script care reîncearcă prea zelos. Niciuna dintre acestea nu este un motiv să evitați o CA publică, dar este muncă operațională pe care o CA privată o mută în altă parte.

Ce nu face un certificat public este să vă autentifice utilizatorii. Identitatea clientului este o decizie separată, luată cu certificate de client, parole sau un al doilea factor, iar CA care semnează serverul nu spune nimic despre cine are voie să se conecteze la el.

Unde o CA privată se potrivește unui VPN

Pentru un VPN privat cu un set cunoscut de clienți, rularea propriei CA este alegerea convențională. Creați CA o dată, semnați certificatul serverului cu un nume pe care clienții îl vor folosi și distribuiți certificatul CA în fiecare profil. Fiecare client verifică apoi serverul față de autoritatea dumneavoastră, iar nicio parte externă nu află numele gazdă.

Costurile sunt reale, dar limitate. Browserele vor avertiza când cineva deschide pagina de administrare direct, pentru că browserul nu are niciun motiv să aibă încredere în CA dumneavoastră. Distribuția profilelor devine parte din onboarding, iar rotirea CA înseamnă să atingeți fiecare client. Sunt prețuri acceptabile pentru un serviciu cu zece sau cincizeci de utilizatori cunoscuți și dureroase pentru un punct final public cu mii.

O singură condiție face întregul aranjament valid: verificarea trebuie să aibă loc. Un client configurat să ignore erorile de certificat acceptă orice server care prezintă orice certificat, astfel încât garanția identității dispare în timp ce criptarea rămâne. Acea setare este adevărata slăbiciune în majoritatea poveștilor de tipul "autosemnat este nesigur".

Cheia privată a CA decide ce puteți face mai târziu

Surpriza vine de obicei luni mai târziu, când vreți să adăugați un dispozitiv. Emiterea unui certificat de client necesită cheia privată a CA, la fel și producerea unei liste de revocare. Dacă ați moștenit un server care are fișierele de certificat și cheie, dar nu cheia CA, nu puteți semna nimic nou. Opțiunile dumneavoastră sunt să reconstruiți PKI-ul și să dați fiecărui client un certificat CA nou, sau să treceți la autentificarea prin parolă, care este un model de securitate diferit și nu restaurează ce s-a pierdut.

Două capcane mai mici trăiesc în același teritoriu. Scripturile easy-rsa presupun că stați în directorul care le conține, așa că o eroare de fișier lipsă înseamnă de obicei locația greșită, nu o instalare deteriorată. Și un design doar cu certificate este perfect legitim: puteți cere certificate de client fără o cheie partajată în prealabil, cu condiția ca fiecare client să aibă unul și serverul să verifice lanțul.

Emiteți un certificat per dispozitiv în loc de un certificat de client partajat pentru întreaga echipă. Un laptop pierdut vă costă atunci o singură revocare în loc de o reemitere pentru toată lumea.

Verificați ce ați moștenit

Înainte de a planifica orice schimbare, citiți certificatul pe care îl aveți deja:

$ openssl x509 -in server.crt -noout -subject -issuer -dates
subject=CN = vpn.example.net
issuer=CN = vpn.example.net
notAfter=Nov  3 09:00:00 2027 GMT
$ openssl verify -CAfile ca.crt server.crt
server.crt: OK

Dacă emitentul este egal cu subiectul, certificatul este autosemnat, ceea ce este o alegere de design, nu un defect. Datele vă spun când reînnoirea devine problema cuiva, iar o verificare reușită față de CA pe care intenționați să o livrați confirmă că lanțul funcționează înainte ca un singur client să îl încerce.

Apoi alegeți după public și distribuție: CA publică atunci când browsere necunoscute trebuie să aibă încredere în pagina de administrare, CA privată atunci când fiecare client primește un profil pe care îl controlați. Niciunul dintre răspunsuri nu este mai criptat decât celălalt.