Чаму cryptoapicert не працуе ў OpenVPN 3 і Connect на Windows

Вы капіруеце працоўны профіль OpenVPN 2 у больш новы кліент Windows, і сертыфікат, які стары кліент знаходзіў сам, болей не прапануецца. Радок, які рабіў гэта магчымым, — гэта селектар, што належыць кліенту Community 2 і існуе толькі ў Windows, а больш новае прыкладанне — іншая праграма з іншым шляхам уліковых даных. Профіль не змяніўся, акрамя гэтага аднаго радка, і менавіта таму розніцу цяжка заўважыць.

У гэтай справаздачы змешваюцца тры ўзроўні: кліент Community, базавая бібліятэка і франтэнд, які нехта ўсталяваў. Толькі адзін з іх калі-небудзь разумеў гэтую дырэктыву.

Што азначае гэтая опцыя там, дзе яна існуе

У кліенце Community OpenVPN 2 на Windows cryptoapicert пазначае сертыфікат, які кліент павінен знайсці ў сховішчы сертыфікатаў Windows, а не ў файле. Гэта зручнасць, спецыфічная для Windows, і яна працуе, бо гэты кліент умее пералічыць сховішча і перадаць атрыманы ключ свайму стэку TLS. Такім чынам, дырэктыва — частка мовы канфігурацыі гэтага кліента, а не ўласцівасць пратаколу OpenVPN. Нішто ў фармаце перадачы яе не нясе.

Скапіруйце той жа радок у іншую праграму — і вы скапіравалі слова, якое новая праграма можа разабраць, праігнараваць або адхіліць. Дырэктыва не з'яўляецца функцыяй пратаколу, і гэтая нават не функцыя кожнага кліента, які размаўляе на OpenVPN.

Што замест гэтага прапануе базавая бібліятэка

OpenVPN 3 Core — гэта бібліятэка, якую ўбудоўваюць іншыя праграмы, і яна працуе са знешнімі ўліковымі данымі праз API, а не праз пошук у сховішчы. Прыкладанне, што ўбудоўвае, падае ланцуг сертыфікатаў і пазней просіць бібліятэку падпісаць знешнім ключом, а бібліятэка вяртаецца да прыкладання, каб гэта зрабіць. Гэта больш агульны дызайн, і ён азначае, што менавіта франтэнд вырашае, якія пастаўшчыкі існуюць. У апрацоўцы опцый самой бібліятэкі cryptoapicert паяўляецца сярод дырэктыў, якія не рэалізаваныя, што ўзгоднена з такім падзелам адказнасці.

Існаванне гэтых зваротных выклікаў не азначае, што пэўнае спакаванае прыкладанне пералічвае асабістае сховішча бягучага карыстальніка, падтрымлівае пэўнага пастаўшчыка ключоў або можа завяршыць запыт смарт-карты. Гэта ўласцівасці франтэнда, і кожную з іх павінен дакументаваць франтэнд.

Што замест гэтага робіць франтэнд Windows

OpenVPN Connect ідзе іншым шляхам: аператар імпартуе файл PKCS#12, які змяшчае сертыфікат і яго прыватны ключ, у OpenVPN Certificate Store, створанае для гэтай мэты, а затым прызначае знешні сертыфікат профілю. Гэта свядома выкананы крок імпарту, а не аўтаматычнае выяўленне таго, што выпадкова апынулася ў асабістым сховішчы. Розніца важная, калі нехта мяркуе, што сертыфікат, усталяваны для іншай мэты, проста з'явіцца ў спісе кліента.

Імпарт мае наступствы і для палітыкі ключоў, бо экспарт ключа ў файл P12 — гэта менавіта тое, што прызначаны прадухіляць неэкспартуемы ключ. Гэта пытанне палітыкі, а не канфігурацыі, і яно заслугоўвае адказу перш чым хто-небудзь паспрабуе імпарт.

Выберыце шлях, які адпавядае палітыцы ключа

Калі ўліковыя даныя можна экспартаваць і палітыка дазваляе апісаны імпарт, выкарыстайце абаронены працэс рэгістрацыі арганізацыі і трымайце часовы P12 і яго пароль па-за журналамі і скрыптамі. Калі ключ ніколі не павінен пакідаць смарт-карту або абароненага пастаўшчыка, выберыце камбінацыю кліента і пастаўшчыка, якая яўна падтрымлівае гэтае патрабаванне, або атрымайце пацвярджэнне ад пастаўшчыка для ўсталяванай версіі. Ні адна з галін не з'яўляецца абыходам для другой.

Вяртанне дырэктывы ў профіль не можа даць інтэграцыю, якой праграма не мае. І больш новая версія кліента не абавязкова яе дадасць, бо гэтая магчымасць належыць уласнаму дызайну франтэнда.

Калі лакальны ключ працуе, сервер усё яшчэ правярае ідэнтычнасць сертыфіката, ланцуг і аўтарызацыю. Прыдатны лакальны ключ і прынятая ідэнтычнасць VPN — гэта асобныя вынікі, і менавіта іх падзел не дае абмежаванню франтэнда ператварыцца ў аслабленую палітыку сертыфікатаў.