Зошто cryptoapicert не работи во OpenVPN 3 и Connect на Windows
Оваа директива припаѓа на еден 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 идентитет се одделни исходи и нивното одвојување е она што спречува ограничувањето на фронтендот да се претвори во ослабена политика на сертификати.