Kvifor cryptoapicert mislukkast i OpenVPN 3 og Connect på Windows

Du kopierer ein fungerande OpenVPN 2-profil til ein nyare Windows-klient, og sertifikatet som den gamle klienten fann sjølv, blir ikkje tilbode lenger. Linja som gjorde det mogleg, er ein Windows-spesifikk veljar som høyrer til Community 2-klienten, og den nyare applikasjonen er eit anna program med ein annan legitimasjonsveg. Profilen er uendra bortsett frå den eine linja, og det er nettopp det som gjer skilnaden vanskeleg å sjå.

Tre lag blir blanda saman i den rapporten: Community-klienten, kjerneliblioteket og frontenden nokon installerte. Berre éin av dei har nokon gong forstått direktivet.

Kva innstillinga tyder der ho finst

I Community OpenVPN 2-klienten på Windows nemner cryptoapicert eit sertifikat som klienten skal finne i Windows-sertifikatarkivet i staden for i ei fil. Det er ei Windows-spesifikk lettvintheit, og ho verkar fordi klienten veit korleis arkivet skal listast opp og den resulterande nøkkelen skal givast til sin eigen TLS-stakk. Direktivet er difor ein del av konfigurasjonsspråket til den klienten, ikkje ein eigenskap ved OpenVPN-protokollen. Ingenting i overføringsformatet ber det.

Kopier den same linja til eit anna program, og du har kopiert eit ord som det nye programmet kanskje parsar, ignorerer eller avviser. Eit direktiv er ikkje ein protokollfunksjon, og dette er ikkje ein gong ein funksjon i kvar klient som snakkar OpenVPN.

Kva kjerneliblioteket tilbyr i staden

OpenVPN 3 Core er eit bibliotek som andre program byggjer inn, og det handterer eksterne legitimasjonar gjennom eit API i staden for oppslag i arkivet. Programmet som byggjer det inn, leverer ein sertifikatkjede og ber seinare biblioteket signere med ein ekstern nøkkel, og biblioteket kallar tilbake til programmet for å gjere det. Det er ein meir generell design, og det tyder at frontenden avgjer kva tilbydarar som finst. I kjernen sin eigen innstillinghandtering opptrer cryptoapicert blant direktiva som ikkje er implementerte, noko som stemmer med den ansvarsfordelinga.

At desse callbackane finst, tyder ikkje at ein gitt pakka applikasjon listar opp den personlege arkivet til den gjeldande brukaren, støttar ein bestemd nøkkelleverandør eller kan fullføre ein smartkortforespurnad. Det er frontend-eigenskapar, og kvar av dei må dokumenterast av frontenden.

Kva Windows-frontenden gjer i staden

OpenVPN Connect tek ein annan veg: operatøren importerer ei PKCS#12-fil med sertifikatet og den private nøkkelen sin inn i eit OpenVPN Certificate Store som er oppretta for føremålet, og tildeler deretter det eksterne sertifikatet til profilen. Det er eit medvite importsteg, ikkje ei automatisk oppdaging av det som tilfeldigvis ligg i det personlege arkivet. Skilnaden har noko å seie når nokon trur at eit sertifikat installert for eit anna føremål berre vil dukke opp i lista til klienten.

Importen har også ei følgje for nøkkelpolitikken, fordi eksport av ein nøkkel til ei P12-fil er nettopp det ein ikkje-eksporterbar nøkkel er laga for å hindre. Det er eit politikk-spørsmål snarare enn eit konfigurasjonsspørsmål, og det fortener eit svar før nokon prøver importen.

Vel ein veg som passar til politikken til nøkkelen

Viss legitimasjonen er eksporterbar og politikken tillèt den dokumenterte importen, bruk den beskytta registreringsprosessen til organisasjonen og hald den mellombelse P12-en og passordet utanfor loggar og skript. Viss nøkkelen aldri må forlate eit smartkort eller ein beskytta leverandør, vel ein kombinasjon av klient og leverandør som uttrykkeleg støttar det kravet, eller få stadfesting frå leverandøren for versjonen du installerte. Ingen av greinene er ein omveg for den andre.

Å leggje direktivet tilbake i profilen kan ikkje gje ein integrasjon som programmet ikkje har. Ein nyare klientversjon legg det heller ikkje nødvendigvis til, fordi evna høyrer til eigen designen til frontenden.

Når den lokale nøkkelen verkar, kontrollerer tenaren framleis identiteten til sertifikatet, kjeda og autorisasjonen. Ein brukbar lokal nøkkel og ein akseptert VPN-identitet er separate utfall, og å halde dei separate er det som hindrar at ei frontend-avgrensing blir ein svekt sertifikatpolitikk.