Varför cryptoapicert misslyckas i OpenVPN 3 och Connect på Windows

Du kopierar en fungerande OpenVPN 2-profil till en nyare Windows-klient, och det certifikat som den gamla klienten hittade själv erbjuds inte längre. Raden som gjorde det möjligt är en Windows-specifik väljare som tillhör Community 2-klienten, och den nyare applikationen är ett annat program med en annan väg för autentiseringsuppgifter. Profilen är oförändrad bortsett från den enda raden, och det är just det som gör skillnaden svår att se.

Tre lager blandas ihop i den rapporten: Community-klienten, kärnbiblioteket och frontend som någon installerade. Bara en av dem har någonsin förstått direktivet.

Vad inställningen betyder där den finns

I Community OpenVPN 2-klienten på Windows anger cryptoapicert ett certifikat som klienten ska hitta i Windows certifikatarkiv i stället för i en fil. Det är en Windows-specifik bekvämlighet, och den fungerar eftersom klienten vet hur arkivet räknas upp och hur den resulterande nyckeln ges till dess egen TLS-stack. Direktivet är därför en del av den klientens konfigurationsspråk, inte en egenskap hos OpenVPN-protokollet. Inget i överföringsformatet bär det.

Kopiera samma rad till ett annat program och du har kopierat ett ord som det nya programmet kan tolka, ignorera eller avvisa. Ett direktiv är inte en protokollfunktion, och det här är inte ens en funktion hos varje klient som talar OpenVPN.

Vad kärnbiblioteket erbjuder i stället

OpenVPN 3 Core är ett bibliotek som andra program bäddar in, och det hanterar externa autentiseringsuppgifter via ett API i stället för en arkivsökning. Programmet som bäddar in det levererar en certifikatkedja och ber senare biblioteket signera med en extern nyckel, och biblioteket anropar tillbaka till programmet för att göra det. Det är en mer allmän design, och det innebär att frontend bestämmer vilka leverantörer som finns. I kärnans egen inställningshantering förekommer cryptoapicert bland de direktiv som inte är implementerade, vilket stämmer med den ansvarsfördelningen.

Att dessa callbacks finns betyder inte att ett visst paketerat program räknar upp den aktuella användarens personliga arkiv, stöder en viss nyckelleverantör eller kan slutföra en smartkortsförfrågan. Det är frontend-egenskaper, och var och en måste dokumenteras av frontend.

Vad Windows-frontend gör i stället

OpenVPN Connect tar en annan väg: operatören importerar en PKCS#12-fil med certifikatet och dess privata nyckel till ett OpenVPN Certificate Store som skapats för ändamålet, och tilldelar sedan det externa certifikatet till profilen. Det är ett avsiktligt importsteg, inte en automatisk upptäckt av vad som råkar ligga i det personliga arkivet. Skillnaden spelar roll när någon antar att ett certifikat som installerats för ett annat ändamål bara dyker upp i klientens lista.

Importen har också en följd för nyckelpolicyn, eftersom export av en nyckel till en P12-fil är precis vad en icke-exporterbar nyckel är avsedd att förhindra. Det är en policyfråga snarare än en konfigurationsfråga, och den förtjänar ett svar innan någon försöker importera.

Välj en väg som passar nyckelns policy

Om autentiseringsuppgiften är exporterbar och policyn tillåter den dokumenterade importen, använd organisationens skyddade registreringsprocess och håll den tillfälliga P12-filen och dess lösenord utanför loggar och skript. Om nyckeln aldrig får lämna ett smartkort eller en skyddad leverantör, välj en kombination av klient och leverantör som uttryckligen stöder det kravet, eller få bekräftelse från leverantören för den version du installerade. Ingen av grenarna är en genväg för den andra.

Att lägga tillbaka direktivet i profilen kan inte ge en integration som programmet inte har. En nyare klientversion lägger inte heller nödvändigtvis till det, eftersom förmågan hör till frontendens egen design.

När den lokala nyckeln fungerar kontrollerar servern fortfarande certifikatets identitet, kedjan och auktoriseringen. En användbar lokal nyckel och en accepterad VPN-identitet är separata utfall, och att hålla dem åtskilda är det som hindrar att en frontendbegränsning blir en försvagad certifikatpolicy.