Wêrom cryptoapicert mislearret yn OpenVPN 3 en Connect op Windows
De rjochtline heart by ien Windows-klant, net by it protokol. De kearnbibleteek biedt callbacks foar ûndertekenjen oan, en de frontend hat syn eigen ymportwurkstream.
Jo kopiearje in wurkjend OpenVPN 2-profil yn in nijere Windows-klant, en it sertifikaat dat de âlde klant sels fûn, wurdt net mear oanbean. De rigel dy’t dat mooglik makke, is in Windows-spesifike selektor dy’t by de Community 2-klant heart, en de nijere applikaasje is in oar programma mei in oar paad foar oanmeldgegevens. It profyl is ûnferoare útsein dy iene rigel, en dat is krekt wat it ferskil dreech te sjen makket.
Trije lagen wurde yn dat ferslach trochinoar helle: de Community-klant, de kearnbibleteek en de frontend dy’t immen ynstallearre hat. Mar ien fan harren hat ea de rjochtline begrepen.
Wat de opsje betsjut dêr’t er bestiet
Yn de Community OpenVPN 2-klant op Windows neamt cryptoapicert in sertifikaat dat de klant fine moat yn ’e Windows-sertifikaatopslach ynstee fan yn in bestân. It is in Windows-spesifike noflikens, en it wurket om’t dy klant wit hoe’t er de opslach opneame moat en de resultearjende kaai oan syn eigen TLS-stapel jaan moat. De rjochtline is dêrom part fan ’e konfiguraasjetaal fan dy klant, net in eigenskip fan it OpenVPN-protokol. Neat yn it oerdrachtsformaat draacht it.
Kopiearje deselde rigel yn in oare applikaasje en jo hawwe in wurd kopiearre dat it nije programma miskien parset, negearret of wegere. In rjochtline is gjin protokoleigenskip, en dizze is sels gjin eigenskip fan elke klant dy’t OpenVPN.
Wat de kearnbibleteek ynstee eksposearret
OpenVPN 3 Core is in bibleteek dy’t oare applikaasjes ynbêde, en hy behannelet eksterne oanmeldgegevens fia in API ynstee fan in syktocht yn ’e opslach. De ynbêdende applikaasje leveret in sertifikaatkeatling en freget letter de bibleteek om mei in eksterne kaai te ûndertekenjen, en de bibleteek ropt werom nei de applikaasje om dat te dwaan. Dat is in algemiener ûntwerp, en it betsjut dat de frontend beslút hokker oanbieders der binne. Yn ’e eigen opsjebehanneling fan ’e bibleteek ferskynt cryptoapicert ûnder de rjochtlinen dy’t net ymplemintearre binne, wat oerienkomt mei dy ferdieling fan ferantwurdlikheid.
It bestean fan dy callbacks betsjut net dat in beskaat pakket applikaasje de persoanlike opslach fan ’e hjoeddeiske brûker opneamt, in beskate kaai-oanbieder stipet of in smartkaart-fraach foltôgje kin. Dat binne frontend-eigenskippen, en elk dêrfan moat troch de frontend dokumintearre wurde.
Wat de Windows-frontend ynstee docht
OpenVPN Connect folget in oare rûte: de operator ymportearret in PKCS#12-bestân dat it sertifikaat en syn priveekaai befettet yn in OpenVPN Certificate Store dat foar dat doel makke is, en wiist dan it eksterne sertifikaat oan it profyl ta. Dat is in bewuste ymportstap, net in automatyske ûntdekking fan wat der tafallich yn ’e persoanlike opslach sit. It ûnderskie is wichtich as immen oannimt dat in sertifikaat dat foar in oar doel ynstallearre is, gewoan yn ’e list fan ’e klant ferskine sil.
De ymport hat ek gefolgen foar it kaaibelied, want in kaai nei in P12-bestân eksportearje is krekt wat in net-eksportearbere kaai ûntwurpen is om te foarkommen. Dat is in kwestje fan belied en net fan konfiguraasje, en it fertsjinnet in antwurd foardat immen de ymport besiket.
Kies in paad dat by it belied fan ’e kaai past
As de oanmeldgegevens eksportearber binne en it belied de dokumintearre ymport tastiet, brûk dan it beskerme registraasjeproses fan ’e organisaasje en hâld de tydlike P12 en syn wachtwurd bûten logboeken en skripts. As de kaai nea in smartkaart of in beskerme oanbieder ferlitte mei, kies dan in kombinaasje fan klant en oanbieder dy’t dy eask eksplisyt stipet, of krije befêstiging fan ’e leveransier foar de ferzje dy’t jo ynstallearre hawwe. Gjin fan beide tûken is in ferfanging foar de oare.
De rjochtline werom tafoegje oan it profyl kin gjin yntegraasje leverje dy’t de applikaasje net hat. In nijere klantferzje foeget it ek net needsaaklik ta, om’t de mooglikheid by it eigen ûntwerp fan ’e frontend heart.
As de lokale kaai wurket, kontrolearret de server noch altyd de sertifikaatidentiteit, de keatling en de autorisaasje. In brûkbere lokale kaai en in akseptearre VPN-identiteit binne aparte útkomsten, en se apart hâlden is wat foarkomt dat in frontend-beheining in ferswakke sertifikaatbelied wurdt.