Hvorfor OpenVPN fortsatt spør om en privat nøkkelfil når du bruker token

Du setter inn tokenet, leverandørens eget verktøy ser det, men VPN-klienten spør likevel om en privat nøkkelfil. Den forespørselen beviser ikke at tokenet mangler støtte. Vanligvis betyr den at profilen aldri ba klienten om å bruke tokenet, slik at den falt tilbake til sertifikat- og nøkkelinndataene den forventer som standard.

To atskilte verdier må være korrekte før denne tilbakefallingen opphører: leverandøren som gjør tokenet tilgjengelig, og identiteten til sertifikatet inni det. De oppgis gjennom forskjellige alternativer og er lette å forveksle.

Klienten spør om en fil fordi profilen sier det

En standardprofil forventer en sertifikatfil og en privat nøkkelfil, eller én PKCS#12-pakke. Mangler disse inndataene, har klienten ingenting å laste og oppfører seg omtrent som ved en manglende fil, og derfor leses symptomet som en ødelagt sti og ikke som en manglende mekanisme. PKCS#11-stien erstatter disse inndataene i stedet for å supplere dem, så en profil som fortsatt navngir en nøkkelfil vil fortsette å bruke filen. Fjern filinndataene bevisst og la tokenet levere begge halvdeler.

Leverandøralternativet navngir 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 slår på og andre utelater. En generell veiledning kan ikke fortelle deg hvilken konfigurasjon 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, ikke tokenets PIN og ikke navnet på VPN-kontoen. Den inneholder ofte tegn som krever anførselstegn, og en verdi uten anførselstegn kan bli avkortet eller feillest uten en tydelig feil. Bruk klientens eget alternativ identitetsoppdagelse for å liste det tokenet eksponerer, og kopier deretter den tiltenkte oppføringen nøyaktig. Å velge det første objektet i listen er hvordan en enhet ender 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. Lister den ingenting, ligger problemet over VPN-klienten og hører til mellomvaren.

Prosessen som kobler til, må nå tokenet

En tokenoperasjon som virker 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. Fastslå hvilken prosess som faktisk holder forbindelsen, og test fra den konteksten.

PIN-håndtering fortjener sin egen avgjørelse. 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 å oppfinne en. 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 vellykket valgt, 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, del opp fasene: leverandøren lastes, det tiltenkte sertifikatet finnes, den private nøkkelen brukes med lokal autorisasjon, VPN autentiserer, og ressursoperasjonen lykkes. Stopp ved den første fasen som feiler i stedet for å gå gjennom passord og installere kryptostakken på nytt.

Loggfør versjoner, moduleierskap, den valgte offentlige identifikatoren og rensede feil, og hold PIN-er og legitimasjonspakker utenfor den loggen.