Welke PKCS#11 URI heeft OpenConnect nodig voor een token?

Een smartcard die de juiste sleutel al bevat, moet nog steeds te horen krijgen welk object erop gebruikt moet worden. OpenConnect wil in die situatie geen gekopieerd .key-bestand; het wil een PKCS#11 URI die het certificaat benoemt en, wanneer de automatische zoekopdracht het werk niet kan afmaken, de privésleutel ernaast. Het lastige is dat een syntactisch geldige URI niets bewijst. Hij moet de inschrijving benoemen die de gateway al vertrouwt, niet zomaar een object dat de kaart bereid is te openen.

Wat de client wil in plaats van een geëxporteerde sleutel

De optie -c neemt normaal een bestandspad, maar wanneer de waarde als PKCS#11 URI wordt geparseerd, behandelt OpenConnect die als een verwijzing naar een object in het token in plaats van naar een bestand op schijf. De optie -k gedraagt zich hetzelfde voor de privésleutel. Niets wordt geëxporteerd en de sleutel verlaat nooit de bescherming die de kaart biedt. Wat de client van u nodig heeft, is een naam waarover de tokenmodule, het certificaatarchief en de inschrijving bij de gateway het eens zijn.

Bij die laatste beperking stranden de meeste pogingen. Een URI kan volkomen goed gevormd zijn en toch een certificaat selecteren dat de gateway weigert, omdat geldigheid en relevantie twee aparte vragen zijn. De controle die de moeite waard is, is een vergelijking met het inschrijvingsrecord, niet een zoektocht naar het eerste object dat toevallig opent.

Twee URI's, twee verschillende taken

De URI van het certificaat beantwoordt welke identiteit u claimt. Hij wijst naar een certificaatobject waarvan de openbare sleutel en de subjectregel overeenkomen met het account- of apparaatprofiel dat de VPN-beheerder heeft uitgegeven. Datzelfde certificaat komt meestal met een object voor de privésleutel dat ernaast is opgeslagen, en dat paar is wat de TLS-handshake echt nodig heeft.

De URI van de sleutel beantwoordt waar het bijbehorende privémateriaal staat wanneer OpenConnect dat niet kan afleiden. Met alleen -c ingesteld bouwt de client een sleutelzoekactie uit de eigenschappen van het certificaat; het opgeven van -k vervangt het gissen door een expliciete objectverwijzing. De PIN van het token is een derde, ongerelateerde invoer: hij ontgrendelt de kaart voor de bewerking en identificeert nooit een object.

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

Alles in die geciteerde tekenreeks zijn gegevens. De puntkomma's scheiden de URI-eigenschappen en de procent-escapes coderen tekens die anders het parsen zouden breken, dus het hele argument moet de shell ongeschonden doorstaan.

De URI vinden die bij uw inschrijving past

GnuTLS levert p11tool, dat laat zien wat de huidige gebruiker via p11-kit werkelijk kan bereiken. Begin met p11tool --list-tokens en som daarna de certificaatobjecten op het token op dat u interesseert. Voeg --login toe wanneer de objecten pas na een PIN verschijnen, en vergelijk het subject en de uitgever met het inschrijvingsrecord in plaats van te kiezen wat het eerst verschijnt.

Als het token helemaal niet verschijnt, zit het probleem onder OpenConnect: p11-kit heeft geen module geregistreerd voor die middleware, of de module is voor een ander account geregistreerd. Registratie op systeemniveau staat onder /etc/pkcs11/modules, en een map per gebruiker kan hetzelfde bevatten zonder de systeemkopie aan te raken. Controleer of het providerpad in het modulebestand verwijst naar een bibliotheek die de software van de lezer daadwerkelijk heeft geïnstalleerd.

Wanneer u de URI uit de lijst kopieert, houd de aanhalingstekens eromheen. Puntkomma's zonder aanhalingstekens korten het argument af bij het eerste attribuut en de client meldt dan een object dat hij niet kan vinden.

Wanneer de automatische sleutelzoekactie het opgeeft

OpenConnect kan een sleutelzoekactie afleiden uit de URI van het certificaat, maar de exacte matching die het uitvoert hangt van de versie af, en de omgang met objecttype en label is in de loop der tijd veranderd. Het advies om de URI in te korten tot hij werkt, beschrijft een oude omweg, geen vereiste. Als de afgeleide zoekactie mislukt, benoem de sleutel dan expliciet met -k in plaats van de URI van het certificaat in iets vaags te veranderen.

Bevestig dat de sleutel bestaat en zichtbaar is met p11tool --list-keys voordat u de client de schuld geeft. Controleer daarna of het object gemarkeerd is als bruikbaar voor ondertekening of ontsleuteling, want een sleutel die met verkeerde eigenschappen is gegenereerd, kan geen handshake voltooien, hoe correct de URI ook is. Zet een geserialiseerde pkcs11-id-waarde niet over van een OpenVPN-profiel naar een OpenConnect-optie; de twee clients gebruiken verschillende identificatieformaten, zelfs wanneer ze met dezelfde kaart praten.

Als de URI wordt opgelost en de PIN wordt geaccepteerd maar de authenticatie alsnog mislukt, stop dan met het afstemmen van de URI. Lees de fout van de gateway zelf, want de volgende fout zit boven het token.

Fouten die alleen op URI-problemen lijken

Een gateway die een ander protocol spreekt, faalt identiek of uw URI nu juist of onjuist is. OpenConnect verving de oude vpnc-client met een reden, en kaartondersteuning maakt een incompatibel gatewayprotocol niet compatibel. Bevestig het verwachte protocol van de server en de authenticatieopzet voordat u nog een uur aan objecteigenschappen besteedt.

Validatie van de serveridentiteit is ook een aparte laag. De client verifieert het certificaat van de gateway tegen zijn vertrouwensopslag, en die controle loopt nadat de kaart haar deel al heeft gedaan. Lezersrechten en een gestopte pcscd-dienst geven hetzelfde uiterlijke symptoom, een onleesbaar token, met een veel eenvoudiger oplossing.

Werk van het object naar buiten: ziet p11tool het token, ziet het het certificaat en de sleutel, accepteert OpenConnect de URI, en vraag pas dan of de gateway de identiteit accepteert. Elke stap heeft zijn eigen foutmelding, en elke stap is goedkoper te testen dan de volgende.