Зашто cryptoapicert не ради у OpenVPN 3 и Connect-у на Windows-у

Копирате радни OpenVPN 2 профил у новији Windows клијент, а сертификат који је стари клијент сам проналазио више се не нуди. Линија која је то омогућила је селектор специфичан за Windows који припада клијенту Community 2, а новија апликација је други програм са другим путем акредитива. Профил је непромењен осим те једне линије, и управо то чини разлику тешко видљивом.

У том извештају се мешају три слоја: клијент 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 идентитет су одвојени исходи, а њихово раздвајање је оно што спречава да се ограничење фронтенда претвори у ослабљену политику сертификата.