Hvorfor cryptoapicert ikke virker i OpenVPN 3 og Connect på Windows

Du kopierer en fungerende OpenVPN 2-profil til en nyere Windows-klient, og det certifikat, som den gamle klient selv fandt, bliver ikke længere tilbudt. Linjen, der gjorde det muligt, er en Windows-specifik vælger, der tilhører Community 2-klienten, og den nyere applikation er et andet program med en anden legitimationsvej. Profilen er uændret bortset fra den ene linje, og det er netop, hvad der gør forskellen svær at se.

Tre lag blandes sammen i den rapport: Community-klienten, kernelbiblioteket og frontenden, som nogen har installeret. Kun én af dem har nogensinde forstået direktivet.

Hvad indstillingen betyder, hvor den findes

I Community OpenVPN 2-klienten på Windows angiver cryptoapicert et certifikat, som klienten skal finde i Windows-certifikatlageret i stedet for i en fil. Det er en Windows-specifik bekvemmelighed, og den virker, fordi klienten ved, hvordan lageret optælles, og hvordan den resulterende nøgle gives til dens egen TLS-stak. Direktivet er derfor en del af klientens konfigurationssprog, ikke en egenskab ved OpenVPN-protokollen. Intet i overførselsformatet bærer det.

Kopier den samme linje til et andet program, og du har kopieret et ord, som det nye program måske parser, ignorerer eller afviser. Et direktiv er ikke en protokolfunktion, og dette er ikke engang en funktion i enhver klient, der taler OpenVPN.

Hvad kernelbiblioteket i stedet eksponerer

OpenVPN 3 Core er et bibliotek, som andre programmer indlejrer, og det håndterer eksterne legitimationsoplysninger gennem en API i stedet for et lageropslag. Det indlejrende program leverer en certifikatkæde og beder senere biblioteket om at signere med en ekstern nøgle, og biblioteket kalder tilbage i programmet for at gøre det. Det er et mere generelt design, og det betyder, at frontenden bestemmer, hvilke udbydere der findes. I kernens egen indstillingshåndtering optræder cryptoapicert blandt de direktiver, der ikke er implementeret, hvilket stemmer med den ansvarsfordeling.

Eksistensen af disse callbacks betyder ikke, at en given pakket applikation optæller den aktuelle brugers personlige lager, understøtter en bestemt nøgleudbyder eller kan gennemføre en smartkortprompt. Det er frontend-egenskaber, og hver af dem skal dokumenteres af frontenden.

Hvad Windows-frontenden i stedet gør

OpenVPN Connect tager en anden vej: operatøren importerer en PKCS#12-fil med certifikatet og dets private nøgle til et OpenVPN Certificate Store, der er oprettet til formålet, og tildeler derefter det eksterne certifikat til profilen. Det er et bevidst importtrin, ikke en automatisk registrering af, hvad der tilfældigt ligger i det personlige lager. Forskellen betyder noget, når nogen antager, at et certifikat, der er installeret til et andet formål, blot vises på klientens liste.

Importen har også en konsekvens for nøglepolitikken, fordi eksport af en nøgle til en P12-fil er præcis det, en ikke-eksporterbar nøgle er designet til at forhindre. Det er et politikspørgsmål snarere end et konfigurationsspørgsmål, og det fortjener et svar, før nogen forsøger importen.

Vælg en vej, der passer til nøglens politik

Hvis legitimationsoplysningerne kan eksporteres, og politikken tillader den dokumenterede import, skal du bruge organisationens beskyttede tilmeldingsproces og holde den midlertidige P12 og dens adgangskode ude af logfiler og scripts. Hvis nøglen aldrig må forlade et smartkort eller en beskyttet udbyder, skal du vælge en kombination af klient og udbyder, der udtrykkeligt understøtter det krav, eller få bekræftelse fra leverandøren for den version, du installerede. Ingen af grenene er en omvej for den anden.

At føje direktivet tilbage til profilen kan ikke levere en integration, som programmet ikke har. En nyere klientversion tilføjer den heller ikke nødvendigvis, fordi evnen hører til frontendens eget design.

Når den lokale nøgle virker, kontrollerer serveren stadig certifikatets identitet, kæden og autorisationen. En brugbar lokal nøgle og en accepteret VPN-identitet er separate resultater, og at holde dem adskilt er det, der forhindrer, at en frontend-begrænsning bliver til en svækket certifikatpolitik.