Kvifor OpenVPN framleis ber om ei privat nøkkelfil når du har eit token

Du set inn tokenet, verktøyet til leverandøren sjølv ser det, og VPN-klienten ber framleis om ei privat nøkkelfil. Den førespurnaden er ikkje prov på at tokenet ikkje er støtta. Han tyder vanlegvis at profilen aldri sa til klienten at han skulle bruke tokenet, så han fall tilbake til sertifikat- og nøkkelinn-dataa han ventar som standard.

To separate verdiar må vere riktige før denne tilbakefallinga stoppar: leverandøren som eksponerer tokenet, og identiteten til sertifikatet inni det. Dei blir gjevne med ulike alternativ og er lette å forveksle.

Klienten ber om ei fil fordi profilen seier det

Ein standardprofil ventar ei sertifikatfil og ei privat nøkkelfil, eller éin PKCS#12-pakke. Når desse inn-dataa manglar, har klienten ingenting å laste og oppfører seg nesten som ved ei manglande fil, og difor blir symptomet lese som ein øydelagd sti og ikkje som ein manglande mekanisme. PKCS#11-stien erstattar desse inn-dataa i staden for å fylla dei ut, så ein profil som framleis nemner ei nøkkelfil vil halde fram med å bruke fila. Fjern filinn-dataa med vilje og la tokenet levera båe halvdelane.

Leverandøralternativet nemner eit mellomvarebibliotek, ikkje ein eining og ikkje eit sertifikat. Om ein pakka klient kan laste det biblioteket, kjem an på korleis han vart bygd, inkludert valfri p11-kit-støtte som nokre bygg slår på og andre let vere. Ei generell rettleiing kan ikkje seie deg kva oppsett pakken din har.

Den serialiserte identiteten er ein annan verdi

Identiteten til sertifikatet er ein lang serialisert streng som oppdagingsprosessen lagar, og han er ikkje bibliotekstien, ikkje PIN-en til tokenet og ikkje namnet på VPN-kontoen. Han inneheld ofte teikn som må setjast i hermeteikn, og ein verdi utan hermeteikn kan bli avkorta eller feillesen utan ein klar feil. Bruk det eigne alternativet identitetsoppdaging til klienten for å lista opp kva tokenet eksponerer, og kopier deretter den tiltenkte oppføringa nøyaktig. Å velje det første objektet i lista er måten ei eining endar med å presentere feil sertifikat.

Oppdagingsutdataa svarar også på eit tidlegare spørsmål: om tokenet i det heile er synleg gjennom den leverandøren. Viss det ikkje listar opp noko, ligg problemet ovanfor VPN-klienten og høyrer til mellomvara.

Prosessen som koplar til, må nå tokenet

Ein tokenoperasjon som fungerer i skrivebordsøkta di, provar ingenting om ein systemteneste. Tenesta kan køyre som ein annan brukar, i eit anna mount-namnerom, med ein modulsti som let leverandørbiblioteket vere, eller utan løyve til å opne einingknuten. Finn ut kva prosess som faktisk held tilkoplinga, og test frå den konteksten.

PIN-handtering fortener si eiga avgjerd. Referanseimplementasjonen tilbyr ein PIN-buffer og ein verna autentiseringssti, og båe finst for at ein operatør skal kunne velje ein arbeidsflyt i staden for å finne han opp. Ikkje gjer eit krav utan tilsyn om til ein PIN i klartekst i ein delt profil, fordi det byter vernet av tokenet mot komfort. Der tokenet forbyr nøkkeleksport, skjer signeringa på eininga og PIN-en er den einaste lokale løyndomen. Handsame han med den omsuta det inneber.

Kva tokenet ikkje erstattar

Tokenet autentiserer klienten under den utrulla policyen, og det erstattar ikkje kontrollane til klienten mot tenaren. Eit sertifikat som er valt ut med hell er ikkje løyve til å godta eit uventa gateway-sertifikat, og dei to verifiseringane vernar motsette retningar.

Registrering må framleis skje hos utgivaren, og gatewayen må framleis autorisere identiteten.

For aksept, skil fasane: leverandøren blir lasta, det tiltenkte sertifikatet blir funne, den private nøkkelen blir brukt med lokal autorisasjon, VPN autentiserer, og ressursoperasjonen lukkast. Stopp ved den første fasen som feilar i staden for å sykle gjennom passord og installere kryptostakken på nytt.

Registrer versjonar, moduleigarskap, den valde offentlege identifikatoren og reinska feil, og hald PIN-ar og legitimasjonspakkar utanfor den registreringa.