Hvorfor OpenVPN fortsatt ber om en privat nøkkelfil når du har et token

Du setter inn tokenet, leverandørens eget verktøy ser det, og VPN-klienten ber fortsatt om en privat nøkkelfil. Den forespørselen er ikke bevis på at tokenet ikke støttes. Den betyr vanligvis at profilen aldri fortalte klienten at den skulle bruke tokenet, så den falt tilbake til sertifikat- og nøkkelinndataene den forventer som standard.

To separate verdier må være riktige før denne tilbakefallingen stopper: leverandøren som eksponerer tokenet, og identiteten til sertifikatet inni det. De angis med forskjellige alternativer og er lette å forveksle.

Klienten ber om en fil fordi profilen sier det

En standardprofil forventer en sertifikatfil og en privat nøkkelfil, eller én PKCS#12-pakke. Når disse inndataene mangler, har klienten ingenting å laste og oppfører seg nesten som ved en manglende fil, og derfor leses symptomet som en ødelagt sti snarere enn en manglende mekanisme. PKCS#11-stien erstatter disse inndataene i stedet for å utfylle dem, så en profil som fortsatt angir en nøkkelfil vil fortsette å bruke filen. Fjern filinndataene med vilje og la tokenet levere begge halvdelene.

Leverandøralternativet angir et mellomvarebibliotek, ikke en enhet og ikke et sertifikat. Om en pakket klient kan laste det biblioteket avhenger av hvordan den ble bygget, inkludert valgfri p11-kit-støtte som noen bygg aktiverer og andre utelater. En generell veiledning kan ikke fortelle deg hvilket oppsett pakken din har.

Den serialiserte identiteten er en annen verdi

Sertifikatets identitet er en lang serialisert streng som oppdagelsesprosessen produserer, og den er ikke bibliotekstien, tokenets PIN eller navnet på VPN-kontoen. Den inneholder ofte tegn som må settes i anførselstegn, og en verdi uten anførselstegn kan bli avkortet eller feilleset uten en klar feil. Bruk klientens eget alternativ identitetsoppdagelse for å liste opp hva tokenet eksponerer, og kopier deretter den tiltenkte oppføringen nøyaktig. Å velge det første objektet i listen er måten en enhet ender opp med å presentere feil sertifikat.

Oppdagelsesutdataene svarer også på et tidligere spørsmål: om tokenet i det hele tatt er synlig gjennom den leverandøren. Hvis det ikke lister opp noe, ligger problemet ovenfor VPN-klienten og tilhører mellomvaren.

Prosessen som kobler til, må nå tokenet

En tokenoperasjon som fungerer i skrivebordsøkten din beviser ingenting om en systemtjeneste. Tjenesten kan kjøre som en annen bruker, i et annet mount-navnerom, med en modulsti som utelater leverandørens bibliotek, eller uten tillatelse til å åpne enhetsnoden. Identifiser hvilken prosess som faktisk holder tilkoblingen, og test fra den konteksten.

PIN-håndtering fortjener sin egen beslutning. Referanseimplementasjonen tilbyr en PIN-buffer og en beskyttet autentiseringssti, og begge finnes for at en operatør skal kunne velge en arbeidsflyt i stedet for å finne den opp. Ikke gjør et krav uten tilsyn om til en PIN i klartekst i en delt profil, fordi det bytter tokenets beskyttelse mot bekvemmelighet. Der tokenet forbyr nøkkeleksport, skjer signeringen på enheten og PIN-en er den eneste lokale hemmeligheten. Behandle den med den omhuen det innebærer.

Hva tokenet ikke erstatter

Tokenet autentiserer klienten under den utrullede policyen, og det erstatter ikke klientens kontroller mot serveren. Et sertifikat som er valgt ut med hell er ikke tillatelse til å godta et uventet gateway-sertifikat, og de to verifiseringene beskytter motsatte retninger.

Registrering må fortsatt skje hos utstederen, og gatewayen må fortsatt autorisere identiteten.

For aksept, skill fasene: leverandøren lastes, det tiltenkte sertifikatet blir funnet, den private nøkkelen brukes med lokal autorisasjon, VPN autentiserer, og ressourceoperasjonen lykkes. Stopp ved den første fasen som feiler i stedet for å sykle gjennom passord og installere kryptostakken på nytt.

Registrer versjoner, moduleierskap, den valgte offentlige identifikatoren og rensede feil, og hold PIN-er og legitimasjonspakker utenfor den registreringen.