Hvorfor cryptoapicert mislykkes i OpenVPN 3 og Connect på Windows

Du kopierer en fungerende OpenVPN 2-profil til en nyere Windows-klient, og sertifikatet som den gamle klienten fant selv, tilbys ikke lenger. Linjen som gjorde det mulig, er en Windows-spesifikk velger som tilhører Community 2-klienten, og den nyere applikasjonen er et annet program med en annen legitimasjonsvei. Profilen er uendret bortsett fra den ene linjen, og det er nettopp det som gjør forskjellen vanskelig å se.

Tre lag blandes sammen i den rapporten: Community-klienten, kjernebiblioteket og frontenden noen installerte. Bare én av dem har noen gang forstått direktivet.

Hva innstillingen betyr der den finnes

I Community OpenVPN 2-klienten på Windows angir cryptoapicert et sertifikat som klienten skal finne i Windows-sertifikatlageret i stedet for i en fil. Det er en Windows-spesifikk bekvemmelighet, og den virker fordi klienten vet hvordan lageret skal listes opp og den resulterende nøkkelen gis til sin egen TLS-stakk. Direktivet er derfor en del av konfigurasjonsspråket til den klienten, ikke en egenskap ved OpenVPN-protokollen. Ingenting i overføringsformatet bærer det.

Kopier den samme linjen til et annet program, og du har kopiert et ord som det nye programmet kanskje parser, ignorerer eller avviser. Et direktiv er ikke en protokollfunksjon, og dette er ikke engang en funksjon i enhver klient som snakker OpenVPN.

Hva kjernebiblioteket tilbyr i stedet

OpenVPN 3 Core er et bibliotek som andre programmer bygger inn, og det håndterer eksterne legitimasjoner gjennom et API i stedet for oppslag i lageret. Programmet som bygger det inn, leverer en sertifikatkjede og ber senere biblioteket signere med en ekstern nøkkel, og biblioteket kaller tilbake til programmet for å gjøre det. Det er en mer generell design, og det betyr at frontenden bestemmer hvilke tilbydere som finnes. I kjernens egen innstillingshåndtering opptrer cryptoapicert blant direktivene som ikke er implementert, noe som stemmer med den ansvarsfordelingen.

At disse callbackene finnes, betyr ikke at en gitt pakket applikasjon lister opp den gjeldende brukerens personlige lager, støtter en bestemt nøkkelleverandør eller kan fullføre en smartkortforespørsel. Det er frontend-egenskaper, og hver av dem må dokumenteres av frontenden.

Hva Windows-frontenden gjør i stedet

OpenVPN Connect tar en annen vei: operatøren importerer en PKCS#12-fil med sertifikatet og dens private nøkkel inn i et OpenVPN Certificate Store som er opprettet for formålet, og tildeler deretter det eksterne sertifikatet til profilen. Det er et bevisst importtrinn, ikke en automatisk oppdagelse av det som tilfeldigvis ligger i det personlige lageret. Forskjellen betyr noe når noen antar at et sertifikat installert for et annet formål bare vil dukke opp i klientens liste.

Importen har også en følge for nøkkelpolicyen, fordi eksport av en nøkkel til en P12-fil er nettopp det en ikke-eksporterbar nøkkel er laget for å forhindre. Det er et policy-spørsmål snarere enn et konfigurasjonsspørsmål, og det fortjener et svar før noen forsøker importen.

Velg en vei som passer til nøkkelens policy

Hvis legitimasjonen er eksporterbar og policyen tillater den dokumenterte importen, bruk organisasjonens beskyttede registreringsprosess og hold den midlertidige P12-en og passordet utenfor logger og skript. Hvis nøkkelen aldri må forlate et smartkort eller en beskyttet leverandør, velg en kombinasjon av klient og leverandør som uttrykkelig støtter det kravet, eller få bekreftelse fra leverandøren for versjonen du installerte. Ingen av grenene er en omvei for den andre.

Å legge direktivet tilbake i profilen kan ikke gi en integrasjon som programmet ikke har. En nyere klientversjon legger det heller ikke nødvendigvis til, fordi evnen hører til frontendens egen design.

Når den lokale nøkkelen virker, kontrollerer serveren fortsatt sertifikatets identitet, kjeden og autorisasjonen. En brukbar lokal nøkkel og en akseptert VPN-identitet er separate utfall, og å holde dem separate er det som hindrer at en frontend-begrensning blir en svekket sertifikatpolicy.