Bakit nabibigo ang cryptoapicert sa OpenVPN 3 at Connect sa Windows

Kinokopya mo ang gumaganang OpenVPN 2 profile sa mas bagong kliyenteng Windows, at ang sertipiko na dati ay siya mismong nakikita ng lumang kliyente ay hindi na inaalok. Ang linyang nagpapagana nito ay isang tagapili na para lang sa Windows na pag-aari ng kliyenteng Community 2, at ang mas bagong aplikasyon ay ibang programa na may ibang landas ng kredensyal. Ang profile ay hindi nagbago maliban sa linyang iyon, at iyon mismo ang dahilan kung bakit mahirap makita ang pagkakaiba.

Tatlong suson ang pinagsasama sa ulat na iyon: ang kliyenteng Community, ang pangunahing aklatan at ang frontend na inilagay ng isang tao. Isa lang sa kanila ang nakaintindi ng direktiba.

Ano ang ibig sabihin ng pagpipiliang ito kung saan ito umiiral

Sa kliyenteng Community OpenVPN 2 sa Windows, tinutukoy ng cryptoapicert ang sertipikong dapat hanapin ng kliyente sa imbakan ng sertipiko ng Windows sa halip na sa file. Ito ay kaginhawang para lang sa Windows, at gumagana ito dahil alam ng kliyenteng iyon kung paano ilista ang imbakan at ibigay ang resultang susi sa sarili nitong stack ng TLS. Kaya ang direktiba ay bahagi ng wikang pangkumpigurasyon ng kliyenteng iyon, hindi katangian ng protocol ng OpenVPN. Wala sa anyo ng paghahatid ang nagdadala nito.

Kopyahin ang parehong linya sa ibang aplikasyon at nakopya mo ang salitang maaaring suriin, huwag pansinin o tanggihan ng bagong programa. Ang direktiba ay hindi katangian ng protocol, at ito ay hindi rin katangian ng bawat kliyenteng nagsasalita ng OpenVPN.

Ano ang iniaalok ng pangunahing aklatan sa halip

Ang OpenVPN 3 Core ay aklatang isinasama ng ibang aplikasyon, at hinahawakan nito ang mga panlabas na kredensyal sa pamamagitan ng API sa halip na paghahanap sa imbakan. Ang aplikasyong nagsasama ay nagbibigay ng kadena ng sertipiko at pagkatapos ay hinihiling sa aklatan na pumirma gamit ang panlabas na susi, at ang aklatan ay tumatawag pabalik sa aplikasyon para gawin iyon. Ito ay mas pangkalahatang disenyo, at ibig sabihin ay ang frontend ang nagpapasya kung aling mga tagapagbigay ang umiiral. Sa sariling pagproseso ng mga opsiyon ng aklatan, lumilitaw ang cryptoapicert sa mga direktibang hindi ipinatupad, na umaayon sa paghahati ng responsibilidad na iyon.

Ang pagkakaroon ng mga callback na iyon ay hindi ibig sabihin na ang isang partikular na nakabalot na aplikasyon ay naglilista ng personal na imbakan ng kasalukuyang gumagamit, sumusuporta sa isang partikular na tagapagbigay ng susi o makakumpleto ng kahilingan sa smart card. Mga katangian iyon ng frontend, at bawat isa ay dapat idokumento ng frontend.

Ano ang ginagawa ng frontend ng Windows sa halip

Iba ang tinatahak ng OpenVPN Connect: ang operator ay nag-aangkat ng file na PKCS#12 na naglalaman ng sertipiko at ng pribadong susi nito sa isang OpenVPN Certificate Store na ginawa para sa layuning iyon, at pagkatapos ay itinatalaga ang panlabas na sertipiko sa profile. Ito ay sinadyang hakbang ng pag-aangkat, hindi kusang pagtuklas ng anumang nasa personal na imbakan. Mahalaga ang pagkakaiba kapag may nag-aakala na ang sertipikong inilagay para sa ibang layunin ay lilitaw lang sa listahan ng kliyente.

Ang pag-aangkat ay may bunga rin sa patakaran sa susi, dahil ang pag-export ng susi sa file na P12 ay siyang eksaktong pinipigilan ng susing hindi maaaring i-export. Ito ay usapin ng patakaran at hindi ng kumpigurasyon, at karapat-dapat itong sagutin bago may sumubok sa pag-aangkat.

Pumili ng landas na umaayon sa patakaran ng susi

Kung ang kredensyal ay maaaring i-export at pinapayagan ng patakaran ang dokumentadong pag-aangkat, gamitin ang protektadong proseso ng pagpapatala ng organisasyon at panatilihin ang pansamantalang P12 at ang password nito sa labas ng mga log at script. Kung ang susi ay hindi dapat kailanman umalis sa smart card o protektadong tagapagbigay, pumili ng kombinasyon ng kliyente at tagapagbigay na tahasang sumusuporta sa pangangailangang iyon, o kumuha ng kumpirmasyon mula sa vendor para sa bersyong inilagay mo. Wala sa dalawang sangay ang kapalit ng isa.

Ang muling pagdaragdag ng direktiba sa profile ay hindi makapagbibigay ng integrasyong wala sa aplikasyon. Ni hindi rin ito idinadagdag ng mas bagong bersyon ng kliyente, dahil ang kakayahan ay pag-aari ng sariling disenyo ng frontend.

Kapag gumana na ang lokal na susi, sinusuri pa rin ng server ang pagkakakilanlan ng sertipiko, ang kadena at ang awtorisasyon. Ang magagamit na lokal na susi at ang tinanggap na pagkakakilanlang VPN ay magkahiwalay na resulta, at ang paghihiwalay sa kanila ang pumipigil sa limitasyon ng frontend na maging mahinang patakaran sa sertipiko.