Upravljavec pošlje naslov in uporabniško ime, odjemalec pa zahteva datoteko CA, potrdilo in ključ. Ustvarjanje teh treh lokalno se zdi očiten naslednji korak. Nastane potrdilo, ki mu verjame samo vaš stroj. Zaupanje strežnika je zasidrano v CA, ki je ne nadzorujete, zato se rokovanje konča, preden se začne.

Zaupanje živi na strežniku, ne v vašem profilu

Preverjanje potrdila je primerjava. Odjemalec predloži potrdilo; prehod preveri, ali ga je podpisala ena od CA v njegovi konfiguraciji.

Vaš profil navaja datoteko CA, ki naj jo odjemalec uporabi za preverjanje strežnika. Ne more navesti CA, ki naj jo strežnik uporabi za preverjanje vas. Ta polovica konfiguracije ni vaša.

Sam izdelano potrdilo ne prestane te primerjave, tudi ko je tehnično brezhibno. Ima veljaven podpis, subjekt in datume, vendar je izdajatelj CA, za katero prehod še ni slišal. Napaka se pojavi med rokovanjem, potem ko je strežnik že zahteval potrdilo. Nič v odjemalčevem profilu ne more spremeniti odgovora.

Zakaj samopodpisano potrdilo ne more nadomestiti

Samopodpisano potrdilo je podpisano z lastnim ključem. Podpis se preverja glede na isto datoteko, kar ga naredi samoskladno in neuporabno kot poverilnico za tuj prehod.

Prehod ne sprašuje, ali je potrdilo notranje skladno. Sprašuje, ali ga je podpisal zaupanja vreden izdajatelj.

Zato so sporočila o napakah zmedena. Odjemalec lahko poroča o napaki preverjanja, ki zveni kot težava strežnika, medtem ko strežnik beleži neznanega izdajatelja. Oba opisujeta isto neskladje z nasprotnih koncev.

Pot prek CSR ohrani vaš zasebni ključ

Večino dela lahko še vedno opravite lokalno. Ustvarite par ključev, sestavite zahtevo za podpis potrdila okoli javne polovice in to zahtevo pošljete upravljavcu. Stroj zapusti samo zahteva. Zasebna polovica ostane tam, kjer ste jo ustvarili.

openssl req -new -newkey rsa:3072 -nodes -keyout client.key -out client.csr -subj "/CN=laptop-01"

Upravljavec zahtevo podpiše s svojo CA in vrne potrdilo. Vaš zasebni ključ ni nikoli potoval, rezultat pa se veriži do sidra, ki mu prehod zaupa.

Upravljane storitve pogosto preskočijo CSR in izdajo celoten paket. To je razumna menjava, ko isti ponudnik že zaključuje tunel in ima CA. Shranjevanje ključa se ne izboljša, če ga obdržite, ker lahko ponudnik kadar koli skuje novega.

Paketi se uvažajo, ne nameščajo

Dobaviteljski paketi z varnostno zvenečimi imeni so pogosto profili OpenVPN. Vsebujejo konfiguracijo in včasih potrdila ter ne namestijo ničesar. Uvozite datoteko v odjemalca, ki govori protokol, in povezava je konfigurirana.

Pravilo ravnanja izhaja iz vsebine. Če profil vsebuje zasebni ključ, je to poverilnica in si zasluži enako skrb kot geslo: brez e-pošte, brez shrambe, brez skupne mape za prenose. Ko upravljavec dostavi ca.crt, client.crt in client.key ločeno, jih shranite skupaj z omejevalnimi dovoljenji in profil usmerite nanje.

Dodajte preverjanja, ki jih je upravljavec morda izpustil

Profil, ki ga ustvari usmerjevalnik, včasih nima preverjanja partnerja. remote-cert-tls server zahteva, da potrdilo partnerja nosi namen preverjanja strežnika, tako da odjemalčevega potrdila ni mogoče predvajati kot strežnik. Ta ena vrstica je majhna sprememba z jasno utemeljitvijo.

verify-x509-name gre dlje, ko lahko upravljavec navede pričakovani subjekt ali SAN. Oboje so majhni dodatki k profilu in oboje je zagovorljivo. Preglejte, kaj ste prejeli, preden to uvozite.

openssl x509 -in client.crt -noout -issuer -subject -dates
openssl verify -CAfile ca.crt client.crt

Nastavitve preverjanja niso popravilo pretrgane verige. Če je izdajatelj napačen, je odgovor potrdilo prave CA, ne zastavica, ki izklopi preverjanje. Izklop preverjanja spremeni neuspeh preverjanja v neodkritega.

Zahtevajte en paket: potrdilo organa v obliki PEM, odjemalčevo potrdilo, ki ga je podpisal ta organ, ključ, ki ste ga ustvarili ali je prispel po kanalu, ki mu zaupate, in točno ime strežnika, ki naj ga potrdilo predstavi. Zapišite datum poteka v istem sporočilu, ker je poteklo potrdilo mesece pozneje videti kot omrežna okvara.

Sorodni članki