Kāpēc cryptoapicert neizdodas OpenVPN 3 un Connect programmās uz Windows

Jūs kopējat strādājošu OpenVPN 2 profilu jaunākā Windows klientā, un sertifikāts, ko vecais klients atrada pats, vairs netiek piedāvāts. Rinda, kas to ļāva, ir Windows raksturīgs atlasītājs, kas pieder Community 2 klientam, un jaunākā lietojumprogramma ir cita programma ar citu akreditācijas datu ceļu. Profils nav mainījies, izņemot šo vienu rindu, un tieši tas padara atšķirību grūti saskatāmu.

Šajā ziņojumā tiek sajaukti trīs slāņi: Community klients, pamatbibliotēka un priekšgals, ko kāds instalēja. Tikai viens no tiem jebkad saprata direktīvu.

Ko opcija nozīmē tur, kur tā pastāv

Community OpenVPN 2 klientā uz Windows cryptoapicert nosauc sertifikātu, kas klientam jāatrod Windows sertifikātu krātuvē, nevis failā. Tas ir Windows raksturīgs ērtums, un tas darbojas, jo šis klients prot uzskaitīt krātuvi un nodot iegūto atslēgu savai TLS stekai. Tāpēc direktīva ir šī klienta konfigurācijas valodas daļa, nevis OpenVPN protokola īpašība. Pārraides formātā nekas to nenesa.

Nokopējiet to pašu rindu citā lietojumprogrammā, un jūs esat nokopējis vārdu, ko jaunā programma var parsēt, ignorēt vai noraidīt. Direktīva nav protokola iezīme, un šī pat nav OpenVPN runājoša katra klienta iezīme.

Ko tā vietā nodrošina pamatbibliotēka

OpenVPN 3 Core ir bibliotēka, ko iestrādā citas lietojumprogrammas, un tā apstrādā ārējos akreditācijas datus ar API, nevis krātuves meklēšanu. Iestrādājošā lietojumprogramma nodrošina sertifikātu ķēdi un vēlāk lūdz bibliotēku parakstīt ar ārēju atslēgu, un bibliotēka tam atsaucas atpakaļ lietojumprogrammā. Tas ir vispārīgāks dizains, un tas nozīmē, ka priekšgals izlemj, kuri pakalpojumu sniedzēji pastāv. Pašas bibliotēkas opciju apstrādē cryptoapicert parādās starp direktīvām, kas nav ieviestas, un tas saskan ar šo atbildības sadalījumu.

Šo atzvānu esamība nenozīmē, ka konkrēta iepakota lietojumprogramma uzskaita pašreizējā lietotāja personīgo krātuvi, atbalsta konkrētu atslēgu pakalpojumu sniedzēju vai var pabeigt viedkaršu uzvedni. Tie ir priekšgala rekvizīti, un katrs no tiem priekšgalam ir jādokumentē.

Ko tā vietā dara Windows priekšgals

OpenVPN Connect iet citu ceļu: operators importē PKCS#12 failu, kurā ir sertifikāts un tā privātā atslēga, šim nolūkam izveidotā OpenVPN Certificate Store, un pēc tam piešķir ārējo sertifikātu profilam. Tas ir apzināts importēšanas solis, nevis automātiska tā atklāšana, kas nejauši atrodas personīgajā krātuvē. Atšķirība ir svarīga, kad kāds pieņem, ka citam nolūkam instalēts sertifikāts vienkārši parādīsies klienta sarakstā.

Importam ir sekas arī atslēgu politikā, jo atslēgas eksportēšana uz P12 failu ir tieši tas, ko neeksportējama atslēga ir paredzēta novērst. Tas ir politikas, nevis konfigurācijas jautājums, un tas ir pelnījis atbildi pirms kāds mēģina importēt.

Izvēlieties ceļu, kas atbilst atslēgas politikai

Ja akreditācijas datus var eksportēt un politika atļauj dokumentēto importu, izmantojiet organizācijas aizsargāto reģistrācijas procesu un turiet pagaidu P12 un tā paroli ārpus žurnāliem un skriptiem. Ja atslēga nekad nedrīkst atstāt viedkarti vai aizsargātu pakalpojumu sniedzēju, izvēlieties klienta un pakalpojumu sniedzēja kombināciju, kas skaidri atbalsta šo prasību, vai saņemiet piegādātāja apstiprinājumu par instalēto versiju. Neviens no abiem zariem nav otra aizstājējs.

Direktīvas atgriešana profilā nevar nodrošināt integrāciju, kuras lietojumprogrammai nav. Arī jaunāka klienta versija to ne vienmēr pievieno, jo spēja pieder paša priekšgala dizainam.

Kad vietējā atslēga darbojas, serveris joprojām pārbauda sertifikāta identitāti, ķēdi un autorizāciju. Izmantojama vietējā atslēga un pieņemta VPN identitāte ir atsevišķi rezultāti, un to atdalīšana ir tas, kas neļauj priekšgala ierobežojumam pārvērsties vājinātā sertifikātu politikā.