Melyik PKCS#11 URI-t várja az OpenConnect a tokenhez?

Egy okoskártya, amely már a helyes kulcsot tartalmazza, akkor is meg kell kapnia a választ, melyik objektumot használja rajta. Az OpenConnect ilyenkor nem másolt .key fájlt akar; olyan PKCS#11 URI-t akar, amely megnevezi a tanúsítványt, és amikor az automatikus keresés nem tudja befejezni a munkát, a mellette lévő privát kulcsot. A kellemetlen rész az, hogy a szintaktikailag érvényes URI semmit sem bizonyít. Neveznie kell azt a regisztrációt, amelyben az átjáró már megbízik, nem csupán egy objektumot, amelyet a kártya hajlandó megnyitni.

Mit akar az ügyfél exportált kulcs helyett

A -c kapcsoló általában fájlútvonalat fogad, de amikor az érték PKCS#11 URI-ként értelmezhető, az OpenConnect hivatkozásként kezeli a tokenen belüli objektumra, nem a lemezen lévő fájlra. A -k kapcsoló ugyanígy viselkedik a privát kulcs esetében. Semmi nem exportálódik, és a kulcs soha nem hagyja el a kártya által nyújtott védelmet. Amire az ügyfélnek szüksége van Öntől, az egy név, amelyben a tokenmodul, a tanúsítványtár és az átjáró regisztrációja egyetért.

Leginkább ezen az utolsó feltételen akadnak el a kísérletek. Egy URI tökéletesen jól formált lehet, és mégis olyan tanúsítványt választhat, amelyet az átjáró elutasít, mert az érvényesség és a relevancia külön kérdés. Az ellenőrzés, amely megéri a fáradságot, a regisztrációs rekorddal való összehasonlítás, nem az első véletlenül megnyíló objektum keresése.

Két URI, két különböző feladat

A tanúsítvány URI-ja megválaszolja, milyen identitást igényel. Egy tanúsítványobjektumra mutat, amelynek nyilvános kulcsa és tárgysora megegyezik a VPN-adminisztrátor által kiadott fiók- vagy eszközprofillal. Ugyanez a tanúsítvány általában a mellette tárolt privát kulcs objektummal érkezik, és erre a párra van valójában szüksége a TLS-kézfogásnak.

A kulcs URI-ja megválaszolja, hol található a megfelelő privát anyag, amikor az OpenConnect nem tudja kikövetkeztetni. Csak -c beállításával az ügyfél a tanúsítvány tulajdonságaiból épít kulcskeresést; a -k megadása a találgatást kifejezett objektumhivatkozással váltja fel. A token PIN-je harmadik, nem kapcsolódó bemenet: feloldja a kártyát a művelethez, és soha nem azonosít objektumot.

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

Minden ebben az idézőjeles karakterláncban adat. A pontosvesszők választják el az URI attribútumait, a százalékos escape-ek pedig olyan karaktereket kódolnak, amelyek egyébként megtörnék az értelmezést, ezért az egész argumentumnak sértetlenül kell túlélnie a shellt.

A regisztrációjához illő URI megtalálása

A GnuTLS szállítja a p11toolt, amely felsorolja, mit érhet el a jelenlegi felhasználó valójában a p11-kit segítségével. Kezdje a p11tool --list-tokens paranccsal, majd sorolja fel az érdeklő token tanúsítványobjektumait. Adja hozzá a --login kapcsolót, ha az objektumok csak PIN után jelennek meg, és hasonlítsa össze a tárgyat és a kibocsátót a regisztrációs rekorddal, ahelyett hogy az elsőként megjelenőt választaná.

Ha a token egyáltalán nem jelenik meg, a probléma az OpenConnect alatt van: a p11-kitben nincs regisztrált modul ehhez a köztes szoftverhez, vagy a modul más fiókhoz van regisztrálva. A rendszerszintű regisztráció a /etc/pkcs11/modules alatt található, és egy felhasználónkénti könyvtár ugyanezt tárolhatja anélkül, hogy hozzányúlna a rendszerpéldányhoz. Ellenőrizze, hogy a modulfájlban lévő szolgáltatói útvonal olyan könyvtárra mutat, amelyet az olvasó szoftvere valóban telepített.

Amikor az URI-t kimasolja a listából, tartsa meg a körülötte lévő idézőjeleket. Az idézőjel nélküli pontosvesszők az első attribútumnál elvágják az argumentumot, és az ügyfél ezután olyan objektumot jelent, amelyet nem talál.

Amikor az automatikus kulcskeresés feladja

Az OpenConnect a tanúsítvány URI-jából le tud vezetni egy kulcskeresést, de a pontos egyeztetés, amelyet végez, a verziótól függ, és az objektumtípus megnevezésének kezelése idővel változott. Az a tanács, hogy rövidítse az URI-t, amíg működik, egy régi kerülőutat ír le, nem követelményt. Ha a levezetett keresés sikertelen, nevezze meg a kulcsot kifejezetten a -k kapcsolóval, ahelyett hogy a tanúsítvány URI-ját valami homályosabbá alakítaná.

Erősítse meg, hogy a kulcs létezik és látható a p11tool --list-keys segítségével, mielőtt az ügyfelet okolná. Utána ellenőrizze, hogy az objektum aláírásra vagy visszafejtésre használhatónak van-e megjelölve, mert a rossz attribútumokkal létrehozott kulcs nem tud kézfogást befejezni, bármilyen helyes is az URI. Ne ültessen át sorosított pkcs11-id értéket egy OpenVPN-profilból egy OpenConnect-kapcsolóba; a két ügyfél különböző azonosítóformátumokat használ, még ha ugyanazzal a kártyával beszél is.

Ha az URI feloldódik és a PIN elfogadásra kerül, de a hitelesítés továbbra is sikertelen, hagyja abba az URI hangolását. Olvassa el magának az átjárónak a hibáját, mert a következő hiba a token felett van.

Hibák, amelyek csak URI-problémáknak tűnnek

Egy másik protokollt beszélő átjáró ugyanúgy meghiúsul, akár helyes az URI-ja, akár nem. Az OpenConnect okkal cserélte le a régi vpnc-ügyfelet, és a kártyatámogatás nem tesz kompatibilissé egy inkompatibilis átjáróprotokollt. Erősítse meg a kiszolgáló elvárt protokollját és a hitelesítés elrendezését, mielőtt még egy órát költene objektumattribútumokra.

A kiszolgáló identitásának ellenőrzése szintén külön réteg. Az ügyfél az átjáró tanúsítványát a saját bizalmi tárolójával ellenőrzi, és ez az ellenőrzés azután fut, hogy a kártya már megtette a maga részét. Az olvasó engedélyei és egy leállt pcscd szolgáltatás ugyanazt a külső tünetet okozza, egy olvashatatlan tokent, sokkal egyszerűbb javítással.

Az objektumtól kifelé haladjon: látja-e a p11tool a tokent, látja-e a tanúsítványt és a kulcsot, elfogadja-e az OpenConnect az URI-t, és csak ezután kérdezze meg, elfogadja-e az átjáró az identitást. Minden lépésnek saját hibaüzenete van, és mindegyik olcsóbban tesztelhető, mint a következő.