Vilken PKCS#11 URI behöver OpenConnect för en token?

Ett smartkort som redan har rätt nyckel måste ändå få veta vilket objekt på det som ska användas. OpenConnect vill inte ha en kopierad .key-fil i den situationen; det vill ha en PKCS#11 URI som namnger certifikatet och, när den automatiska sökningen inte kan slutföra jobbet, den privata nyckeln bredvid. Det besvärliga är att en syntaktiskt giltig URI inte bevisar något. Den måste namnge den registrering som gatewayen redan litar på, inte bara ett objekt som kortet är villigt att öppna.

Vad klienten vill ha i stället för en exporterad nyckel

Alternativet -c tar normalt en filsökväg, men när värdet parsas som en PKCS#11 URI behandlar OpenConnect det som en referens till ett objekt inne i tokenet i stället för till en fil på disken. Alternativet -k beter sig på samma sätt för den privata nyckeln. Ingenting exporteras, och nyckeln lämnar aldrig det skydd kortet erbjuder. Det klienten behöver från dig är ett namn som tokenmodulen, certifikatarkivet och registreringen i gatewayen är överens om.

Det är vid den sista begränsningen de flesta försöken fastnar. En URI kan vara fullständigt välformad och ändå välja ett certifikat som gatewayen kommer att avvisa, eftersom giltighet och relevans är separata frågor. Kontrollen som är värd att göra är en jämförelse med registreringsposten, inte en letning efter det första objektet som råkar öppnas.

Två URI:er, två olika jobb

Certifikatets URI svarar på vilken identitet du gör anspråk på. Den pekar på ett certifikatobjekt vars publika nyckel och subjektrad matchar den konto- eller enhetsprofil som VPN-administratören har utfärdat. Samma certifikat kommer vanligtvis med ett objekt för den privata nyckeln sparat bredvid, och det paret är vad TLS-handskakningen faktiskt behöver.

Nyckelns URI svarar på var det matchande privata materialet finns när OpenConnect inte kan härleda det. Med bara -c satt bygger klienten en nyckelsökning från certifikatets egenskaper; att ange -k ersätter gissningen med en explicit objektreferens. Tokenets PIN är en tredje, orelaterad inmatning: den låser upp kortet för operationen, och den identifierar aldrig ett objekt.

openconnect --protocol=anyconnect \
  -c 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=1a2b3c4d;id=%01' \
  vpn.example.net

Allt i den citerade strängen är data. Semikolonen skiljer URI-egenskaper åt och procent-escaparna kodar tecken som annars skulle bryta parsningen, så hela argumentet måste överleva skalet intakt.

Hitta den URI som matchar din registrering

GnuTLS levererar p11tool, som listar vad den aktuella användaren faktiskt kan nå genom p11-kit. Börja med p11tool --list-tokens och lista sedan certifikatobjekten på den token du bryr dig om. Lägg till --login när objekten bara visas efter en PIN, och jämför subjekt och utfärdare med registreringsposten i stället för att välja det som visas först.

Om tokenet inte visas alls ligger problemet under OpenConnect: p11-kit har ingen modul registrerad för den mellanvaran, eller så är modulen registrerad för ett annat konto. Systemomfattande registrering ligger under /etc/pkcs11/modules, och en mapp per användare kan innehålla samma sak utan att röra systemkopian. Kontrollera att leverantörsvägen i modulfilen pekar på ett bibliotek som läsarens programvara faktiskt installerade.

När du kopierar URI:n ur listan, behåll citattecknen runt den. Semikolon utan citattecken kapar argumentet vid den första egenskapen, och klienten rapporterar då ett objekt den inte kan hitta.

När den automatiska nyckelsökningen ger upp

OpenConnect kan härleda en nyckelsökning från certifikatets URI, men den exakta matchningen den gör beror på versionen, och hanteringen av objekttyp och etikett har ändrats över tid. Rådet att förkorta URI:n tills den fungerar beskriver en gammal omväg, inte ett krav. Om den härledda sökningen misslyckas, namnge nyckeln uttryckligen med -k i stället för att göra certifikatets URI till något mer otydligt.

Bekräfta att nyckeln finns och är synlig med p11tool --list-keys innan du skyller på klienten. Kontrollera sedan att objektet är markerat som användbart för signering eller dekryptering, eftersom en nyckel som genererats med fel egenskaper inte kan slutföra en handskakning, hur korrekt URI:n än är. Flytta inte ett serialiserat pkcs11-id-värde från en OpenVPN-profil till ett OpenConnect-alternativ; de två klienterna använder olika identifierarformat även när de talar med samma kort.

Om URI:n löses upp och PIN-koden accepteras men autentiseringen fortfarande misslyckas, sluta justera URI:n. Läs gatewayens eget fel, eftersom nästa fel ligger ovanför tokenet.

Fel som bara ser ut som URI-problem

En gateway som talar ett annat protokoll kommer att misslyckas identiskt oavsett om din URI är korrekt eller inte. OpenConnect ersatte den gamla vpnc-klienten av en anledning, och kortstöd gör inte ett inkompatibelt gatewayprotokoll kompatibelt. Bekräfta serverns förväntade protokoll och autentiseringsupplägget innan du lägger ännu en timme på objektegenskaper.

Validering av serveridentitet är också ett eget lager. Klienten verifierar gatewayens certifikat mot sitt förtroendelager, och den kontrollen körs efter att kortet redan har gjort sin del. Läsarbehörigheter och en stoppad pcscd-tjänst ger samma yttre symptom, en oläsbar token, med en mycket enklare åtgärd.

Arbeta utåt från objektet: ser p11tool tokenet, ser den certifikatet och nyckeln, accepterar OpenConnect URI:n, och fråga först då om gatewayen accepterar identiteten. Varje steg har sitt eget felmeddelande, och varje steg är billigare att testa än nästa.