Pse cryptoapicert dështon në OpenVPN 3 dhe Connect në Windows

Ju kopjoni një profil OpenVPN 2 që funksionon në një klient Windows më të ri, dhe certifikata që klienti i vjetër e gjente vetë nuk ofrohet më. Rreshti që e mundësonte është një zgjedhës specifik i Windows që i përket klientit Community 2, dhe aplikacioni më i ri është një program tjetër me një rrugë tjetër kredencialesh. Profili është i pandryshuar përveç atij rreshti, dhe pikërisht kjo e bën ndryshimin të vështirë për t’u parë.

Në atë raport përzihen tre shtresa: klienti Community, biblioteka bazë dhe frontend-i që dikush instaloi. Vetëm njëri prej tyre e ka kuptuar ndonjëherë direktivën.

Çfarë do të thotë opsioni aty ku ekziston

Në klientin Community OpenVPN 2 në Windows, cryptoapicert emërton një certifikatë që klienti duhet ta gjejë në depon e certifikatave të Windows dhe jo në një skedar. Është një lehtësi specifike e Windows, dhe funksionon sepse ai klient di të numërojë depon dhe ta japë çelësin që rezulton stack-ut të vet TLS. Prandaj direktiva është pjesë e gjuhës së konfigurimit të atij klienti, jo një veti e protokollit OpenVPN. Asgjë në formatin e transmetimit nuk e mbart atë.

Kopjoni të njëjtin rresht në një aplikacion tjetër dhe keni kopjuar një fjalë që programi i ri mund ta analizojë, injorojë ose refuzojë. Një direktivë nuk është veçori e protokollit, dhe kjo nuk është as veçori e çdo klienti që flet OpenVPN.

Çfarë ofron në vend të kësaj biblioteka bazë

OpenVPN 3 Core është një bibliotekë që aplikacionet e tjera e integrojnë, dhe i trajton kredencialet e jashtme përmes një API dhe jo me kërkim në depo. Aplikacioni që e integron furnizon një zinxhir certifikatash dhe më vonë i kërkon bibliotekës të nënshkruajë me një çelës të jashtëm, dhe biblioteka e thërret aplikacionin mbrapsht për ta bërë atë. Ky është një dizajn më i përgjithshëm, dhe do të thotë se frontend-i vendos cilët ofrues ekzistojnë. Në përpunimin e vet të opsioneve të bibliotekës, cryptoapicert shfaqet mes direktivave që nuk janë zbatuar, gjë që përputhet me atë ndarje të përgjegjësisë.

Ekzistenca e atyre kthimeve thirrjesh nuk do të thotë se një aplikacion i paketuar i caktuar numëron depon personale të përdoruesit aktual, mbështet një ofrues të caktuar çelësash ose mund të përfundojë një kërkesë karte inteligjente. Këto janë veti të frontend-it, dhe secila prej tyre duhet të dokumentohet nga frontend-i.

Çfarë bën në vend të kësaj frontend-i i Windows

OpenVPN Connect ndjek një rrugë tjetër: operatori importon një skedar PKCS#12 që përmban certifikatën dhe çelësin e saj privat në një OpenVPN Certificate Store të krijuar për këtë qëllim, dhe më pas ia cakton certifikatën e jashtme profilit. Ky është një hap i qëllimshëm importimi, jo një zbulim automatik i asaj që ndodhet në depon personale. Dallimi ka rëndësi kur dikush supozon se një certifikatë e instaluar për një qëllim tjetër do të shfaqet thjesht në listën e klientit.

Importimi ka edhe një pasojë për politikën e çelësave, sepse eksportimi i një çelësi në një skedar P12 është pikërisht ajo që një çelës i paeksportueshëm është krijuar të parandalojë. Kjo është çështje politike dhe jo konfigurimi, dhe meriton një përgjigje përpara se dikush të provojë importimin.

Zgjidhni një rrugë që përputhet me politikën e çelësit

Nëse kredenciali është i eksportueshëm dhe politika lejon importimin e dokumentuar, përdorni procesin e regjistrimit të mbrojtur të organizatës dhe mbajini P12 e përkohshme dhe fjalëkalimin e saj jashtë regjistrave dhe skripteve. Nëse çelësi nuk duhet të largohet kurrë nga një kartë inteligjente ose një ofrues i mbrojtur, zgjidhni një kombinim klienti dhe ofruesi që e mbështet shprehimisht atë kërkesë, ose merrni konfirmim nga furnizuesi për versionin që instaluat. Asnjëra nga dy degët nuk është zgjidhje alternative për tjetrën.

Shtimi përsëri i direktivës në profil nuk mund të ofrojë një integrim që aplikacioni nuk e ka. As një version më i ri i klientit nuk e shton domosdoshmërisht, sepse aftësia i përket dizajnit të vetë frontend-it.

Pasi çelësi lokal funksionon, serveri vazhdon të kontrollojë identitetin e certifikatës, zinxhirin dhe autorizimin. Një çelës lokal i përdorshëm dhe një identitet VPN i pranuar janë rezultate të veçanta, dhe mbajtja e tyre të veçanta është ajo që pengon një kufizim të frontend-it të kthehet në një politikë certifikatash të dobësuar.