Hoekom cryptoapicert in OpenVPN 3 en Connect op Windows misluk

Jy kopieer ’n werkende OpenVPN 2-profiel na ’n nuwer Windows-kliënt, en die sertifikaat wat die ou kliënt self gevind het, word nie meer aangebied nie. Die reël wat dit laat werk het, is ’n Windows-spesifieke kieser wat aan die Community 2-kliënt behoort, en die nuwer toepassing is ’n ander program met ’n ander geloofsbriewe-pad. Die profiel is onveranderd buiten daardie een reël, en dit is juis wat die verskil moeilik sigbaar maak.

Drie lae word in daardie verslag deurmekaar gegooi: die Community-kliënt, die kernbiblioteek en die front-end wat iemand geïnstalleer het. Net een van hulle het ooit die opdrag verstaan.

Wat die opsie beteken waar dit bestaan

In die Community OpenVPN 2-kliënt op Windows benoem cryptoapicert ’n sertifikaat wat die kliënt in die Windows-sertifikaatstoor moet vind eerder as in ’n lêer. Dit is ’n Windows-spesifieke gerief, en dit werk omdat daardie kliënt weet hoe om die stoor te lys en die resulterende sleutel aan sy eie TLS-stapel te gee. Die opdrag is dus deel van daardie kliënt se konfigurasietaal, nie ’n eienskap van die OpenVPN-protokol nie. Niks in die draadformaat dra dit nie.

Kopieer dieselfde reël na ’n ander toepassing en jy het ’n woord gekopieer wat die nuwe program dalk ontleed, ignoreer of verwerp. ’n Opdrag is nie ’n protokol-eienskap nie, en hierdie een is nie eers ’n eienskap van elke kliënt wat OpenVPN.

Wat die kernbiblioteek eerder blootstel

OpenVPN 3 Core is ’n biblioteek wat ander toepassings insluit, en dit hanteer eksterne geloofsbriewe deur ’n API eerder as ’n stoor-soektog. Die insluitende toepassing verskaf ’n sertifikaatketting en vra later die biblioteek om met ’n eksterne sleutel te onderteken, en die biblioteek roep terug na die toepassing om dit te doen. Dit is ’n meer algemene ontwerp, en dit beteken die front-end besluit watter verskaffers bestaan. In die kern se eie opsiehantering verskyn cryptoapicert onder die opdragte wat nie geïmplementeer is nie, wat ooreenstem met daardie verdeling van verantwoordelikheid.

Die bestaan van daardie terugroepe beteken nie dat ’n gegewe verpakte toepassing die huidige gebruiker se persoonlike stoor lys, ’n bepaalde sleutelverskaffer ondersteun of ’n slimkaart-vraag kan voltooi nie. Dit is front-end-eienskappe, en elkeen moet deur die front-end gedokumenteer word.

Wat die Windows-front-end eerder doen

OpenVPN Connect volg ’n ander roete: die operateur voer ’n PKCS#12-lêer in wat die sertifikaat en sy private sleutel bevat, in ’n OpenVPN Certificate Store wat vir daardie doel geskep is, en wys dan die eksterne sertifikaat aan die profiel toe. Dit is ’n doelbewuste invoerstap, nie ’n outomatiese ontdekking van wat ook al in die persoonlike stoor sit nie. Die onderskeid maak saak wanneer iemand aanneem dat ’n sertifikaat wat vir ’n ander doel geïnstalleer is, eenvoudig in die kliënt se lys sal verskyn.

Die invoer het ook gevolge vir sleutelbeleid, want die uitvoer van ’n sleutel na ’n P12-lêer is presies wat ’n nie-uitvoerbare sleutel bedoel is om te verhoed. Dit is ’n beleidsvraag eerder as ’n konfigurasievraag, en dit verdien ’n antwoord voordat iemand die invoer probeer.

Kies ’n pad wat by die sleutel se beleid pas

As die geloofsbrief uitvoerbaar is en die beleid die gedokumenteerde invoer toelaat, gebruik die organisasie se beskermde inskrywingsproses en hou die tydelike P12 en sy wagwoord uit logs en skripte. As die sleutel nooit ’n slimkaart of ’n beskermde verskaffer mag verlaat nie, kies ’n kombinasie van kliënt en verskaffer wat daardie vereiste uitdruklik ondersteun, of kry bevestiging van die verskaffer vir die weergawe wat jy geïnstalleer het. Nie een tak is ’n omweg vir die ander nie.

Om die opdrag terug by die profiel te voeg, kan nie ’n integrasie verskaf wat die toepassing nie het nie. ’n Nuwer kliëntweergawe voeg dit ook nie noodwendig by nie, want die vermoë hoort by die front-end se eie ontwerp.

Sodra die plaaslike sleutel werk, kontroleer die bediener steeds die sertifikaatidentiteit, die ketting en die magtiging. ’n Bruikbare plaaslike sleutel en ’n aanvaarde VPN-identiteit is aparte uitkomste, en om hulle apart te hou, is wat verhoed dat ’n front-end-beperking in ’n verswakte sertifikaatbeleid ontaard.