Hvorfor OpenVPN stadig beder om en privat nøglefil, når du har et token

Du sætter tokenet i, udbyderens eget værktøj ser det, og VPN-klienten beder stadig om en privat nøglefil. Den anmodning er ikke bevis på, at tokenet ikke understøttes. Den betyder normalt, at profilen aldrig fortalte klienten, at den skulle bruge tokenet, så den faldt tilbage til de certifikat- og nøgleinput, den forventer som standard.

To separate værdier skal være rigtige, før den tilbagefald stopper: udbyderen, der eksponerer tokenet, og identiteten af certifikatet indeni. De leveres af forskellige indstillinger og er nemme at forveksle.

Klienten beder om en fil, fordi profilen siger det

En standardprofil forventer en certifikatfil og en privat nøglefil eller en enkelt PKCS#12-pakke. Når disse input mangler, har klienten intet at indlæse og opfører sig næsten som ved en manglende fil, og derfor læses symptomet som en brudt sti snarere end en manglende mekanisme. PKCS#11-stien erstatter disse input i stedet for at supplere dem, så en profil, der stadig angiver en nøglefil, vil fortsat bruge filen. Fjern filinputtene med vilje, og lad tokenet levere begge halvdele.

Udbyderindstillingen angiver et middleware-bibliotek, ikke en enhed og ikke et certifikat. Om en pakket klient kan indlæse det bibliotek, afhænger af, hvordan den blev bygget, inklusive valgfri p11-kit-understøttelse, som nogle builds aktiverer og andre udelader. En generisk vejledning kan ikke fortælle dig, hvilket arrangement din pakke har.

Den serialiserede identitet er en anden værdi

Certifikatets identitet er en lang serialiseret streng, som opdagelsesprocessen producerer, og den er ikke biblioteksstien, tokenets PIN eller VPN-kontonavnet. Den indeholder ofte tegn, der skal sættes i anførselstegn, og en værdi uden anførselstegn kan blive afkortet eller læst forkert uden en klar fejl. Brug klientens egen indstilling identitetssøgning til at liste, hvad tokenet eksponerer, og kopiér derefter den ønskede post nøjagtigt. At vælge det første objekt på listen er måden, hvorpå en enhed ender med at præsentere det forkerte certifikat.

Opdagelsesoutputtet besvarer også et tidligere spørgsmål: om tokenet overhovedet er synligt gennem den udbyder. Hvis det ikke viser noget, ligger problemet opstrøms for VPN-klienten og hører til middleware.

Processen, der opretter forbindelse, skal kunne nå tokenet

En tokenoperation, der virker i din skrivebordssession, beviser intet om en systemtjeneste. Tjenesten kan køre som en anden bruger, i et andet mount-navnerum, med en modulsti der udelader udbyderens bibliotek, eller uden tilladelse til at åbne enhedsknudepunktet. Find ud af, hvilken proces der faktisk holder forbindelsen, og test fra den kontekst.

PIN-håndtering fortjener sin egen beslutning. Referenceimplementeringen tilbyder en PIN-cache og en beskyttet godkendelsessti, og begge findes, så en operatør kan vælge et arbejdsforløb i stedet for at opfinde et. Omdan ikke et krav uden opsyn til en PIN i klartekst i en delt profil, fordi det bytter tokenets beskyttelse for bekvemmelighed. Hvor tokenet forbyder nøgleeksport, sker signeringen på enheden, og PIN'en er den eneste lokale hemmelighed. Behandl den med den omhu, det indebærer.

Hvad tokenet ikke erstatter

Tokenet godkender klienten under den udrullede politik, og det erstatter ikke klientens kontrol af serveren. Et korrekt valgt certifikat er ikke tilladelse til at acceptere et uventet gateway-certifikat, og de to verifikationer beskytter modsatte retninger.

Tilmelding skal stadig ske hos udstederen, og gatewayen skal stadig autorisere identiteten.

Til accept skal du adskille faserne: udbyderen indlæses, det tilsigtede certifikat findes, den private nøgle bruges med lokal autorisation, VPN godkender, og ressourceoperationen lykkes. Stop ved den første fase, der fejler, i stedet for at cykle gennem adgangskoder og geninstallere kryptostakken.

Registrér versioner, modulejerskab, den valgte offentlige identifikator og rensede fejl, og hold PIN'er og legitimationspakker ude af den registrering.