Varför OpenVPN fortfarande ber om en privat nyckelfil när du har en token

Du sätter i token, leverantörens eget verktyg ser den, och VPN-klienten ber fortfarande om en privat nyckelfil. Den begäran är inte bevis för att token inte stöds. Oftast betyder den att profilen aldrig sa till klienten att använda token, så den föll tillbaka på de certifikat- och nyckelindata den förväntar sig som standard.

Två separata värden måste vara korrekta innan den återgången upphör: leverantören som exponerar token, och identiteten för certifikatet inuti den. De anges med olika alternativ och är lätta att förväxla.

Klienten ber om en fil eftersom profilen säger det

En standardprofil förväntar sig en certifikatfil och en privat nyckelfil, eller ett enda PKCS#12-paket. När dessa indata saknas har klienten inget att ladda och uppträder nästan som vid en saknad fil, vilket är varför symtomet läses som en trasig sökväg och inte som en saknad mekanism. PKCS#11-sökvägen ersätter dessa indata i stället för att komplettera dem, så en profil som fortfarande anger en nyckelfil fortsätter att använda filen. Ta bort filindata med avsikt och låt token leverera båda halvorna.

Leverantörsalternativet anger ett middleware-bibliotek, inte en enhet och inte ett certifikat. Om en paketerad klient kan ladda det biblioteket beror på hur den byggdes, inklusive valfritt p11-kit-stöd som vissa byggen aktiverar och andra utelämnar. En allmän guide kan inte säga vilken uppsättning ditt paket har.

Den serialiserade identiteten är ett annat värde

Certifikatets identitet är en lång serialiserad sträng som upptäcktsprocessen producerar, och den är inte bibliotekssökvägen, inte tokenets PIN och inte namnet på VPN-kontot. Den innehåller ofta tecken som behöver citattecken, och ett värde utan citattecken kan trunkeras eller läsas fel utan ett tydligt fel. Använd klientens eget alternativ identitetsupptäckt för att lista vad token exponerar och kopiera sedan den avsedda posten exakt. Att välja det första objektet i listan är hur en enhet till slut presenterar fel certifikat.

Upptäcktens utdata svarar också på en tidigare fråga: om token alls är synlig via den leverantören. Om den inte listar något ligger problemet ovanför VPN-klienten och tillhör middleware.

Processen som ansluter måste nå token

En tokenoperation som fungerar i din skrivbordssession bevisar ingenting om en systemtjänst. Tjänsten kan köra som en annan användare, i ett annat mount-namnrymd, med en modulsökväg som utelämnar leverantörens bibliotek, eller utan behörighet att öppna enhetsnoden. Ta reda på vilken process som faktiskt håller anslutningen och testa från den kontexten.

PIN-hantering förtjänar ett eget beslut. Referensimplementationen erbjuder en PIN-cache och en skyddad autentiseringsväg, och båda finns så att en operatör kan välja ett arbetsflöde i stället för att hitta på ett. Gör inte ett krav utan övervakning till en PIN i klartext i en delad profil, eftersom det byter tokenets skydd mot bekvämlighet. Där token förbjuder nyckelexport sker signeringen på enheten och PIN-koden är den enda lokala hemligheten. Behandla den med den omsorg det innebär.

Vad token inte ersätter

Token autentiserar klienten enligt den utrullade policyn, och den ersätter inte klientens kontroller mot servern. Ett framgångsrikt valt certifikat är inte tillstånd att acceptera ett oväntat gateway-certifikat, och de två verifieringarna skyddar motsatta riktningar.

Registreringen måste fortfarande ske hos utfärdaren, och gatewayen måste fortfarande auktorisera identiteten.

Dela upp faserna för acceptans: leverantören laddas, det avsedda certifikatet hittas, den privata nyckeln används med lokal auktorisation, VPN autentiserar och resursoperationen lyckas. Stanna vid den första fasen som misslyckas i stället för att cykla genom lösenord och installera om kryptostacken.

Registrera versioner, modulägande, den valda offentliga identifieraren och rensade fel, och håll PIN-koder och behörighetspaket utanför den registreringen.