Какъв PKCS#11 URI е нужен на OpenConnect за токен?

Смарт карта, която вече съдържа правилния ключ, пак трябва да получи указание кой обект върху нея да се използва. OpenConnect в такава ситуация не иска копиран файл .key; той иска PKCS#11 URI, който именува сертификата и, когато автоматичното търсене не може да свърши работата, частния ключ до него. Неудобното е, че синтактично валиден URI не доказва нищо. Той трябва да именува записването, на което шлюзът вече се доверява, а не просто обект, който картата е готова да отвори.

Какво иска клиентът вместо експортиран ключ

Опцията -c обикновено приема път до файл, но когато стойността се разпознае като PKCS#11 URI, OpenConnect я третира като препратка към обект вътре в токена, а не към файл на диска. Опцията -k се държи по същия начин за частния ключ. Нищо не се експортира и ключът никога не напуска защитата, която картата осигурява. Това, което клиентът иска от вас, е име, за което модулът на токена, хранилището на сертификати и записването в шлюза са съгласни.

Именно на последното ограничение повечето опити засядат. Един URI може да е напълно добре оформен и пак да избере сертификат, който шлюзът ще отхвърли, защото валидността и относимостта са отделни въпроси. Проверката, която си струва, е сравнение със записа за записване, а не търсене на първия обект, който случайно се отвори.

Два URI, две различни задачи

URI на сертификата отговаря коя самоличност предявявате. Той сочи към обект на сертификат, чийто публичен ключ и ред на субекта съвпадат с профила на акаунта или устройството, издаден от VPN администратора. Същият сертификат обикновено идва с обект на частен ключ, съхранен до него, и точно тази двойка е нужна на TLS ръкостискането.

URI на ключа отговаря къде живее съответният частен материал, когато OpenConnect не може да го изведе. При зададена само -c клиентът изгражда търсене на ключ от свойствата на сертификата; подаването на -k замества догадката с явна препратка към обект. PIN кодът на токена е трето, несвързано входно условие: той отключва картата за операцията и никога не идентифицира обект.

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

Всичко в този цитиран низ е данни. Точките и запетаите разделят атрибутите на URI, а процентните escape-ове кодират знаци, които иначе биха счупили парсинга, затова целият аргумент трябва да оцелее в шела непокътнат.

Намиране на URI, който отговаря на вашето записване

GnuTLS доставя p11tool, който изброява какво текущият потребител реално може да достигне през p11-kit. Започнете с p11tool --list-tokens, после изброете обектите на сертификатите върху токена, който ви интересува. Добавете --login, когато обектите се появяват само след PIN, и сравнете субекта и издателя със записа за записване, вместо да избирате каквото се появи първо.

Ако токенът изобщо не се появи, проблемът е под OpenConnect: в p11-kit няма регистриран модул за този middleware или модулът е регистриран за друг акаунт. Системната регистрация се намира в /etc/pkcs11/modules, а потребителска директория може да съдържа същото, без да пипа системното копие. Проверете дали пътят на доставчика във файла на модула сочи към библиотека, която софтуерът на четеца действително е инсталирал.

Когато копирате URI от списъка, запазете кавичките около него. Нецитираните точки и запетаи отрязват аргумента при първия атрибут и клиентът после съобщава за обект, който не може да намери.

Когато автоматичното търсене на ключ се откаже

OpenConnect може да изведе търсене на ключ от URI на сертификата, но точното съпоставяне, което извършва, зависи от версията, а обработката на типа обект и етикета се е променяла с времето. Съветът да съкращавате URI, докато проработи, описва стара заобиколна мярка, а не изискване. Ако изведеното търсене се провали, назовете ключа изрично с -k, вместо да превръщате URI на сертификата в нещо по-неясно.

Потвърдете, че ключът съществува и се вижда с p11tool --list-keys, преди да обвинявате клиента. После проверете дали обектът е маркиран като използваем за подписване или дешифриране, защото ключ, генериран с грешни атрибути, не може да завърши ръкостискане, колкото и правилен да е URI. Не прехвърляйте сериализирана стойност pkcs11-id от профил на OpenVPN в опция на OpenConnect; двата клиента използват различни формати за идентификатор дори когато говорят с една и съща карта.

Ако URI се разреши и PIN се приеме, но удостоверяването все още се проваля, спрете да настройвате URI. Прочетете собствената грешка на шлюза, защото следващият отказ е над токена.

Откази, които само изглеждат като проблеми с URI

Шлюз, който говори различен протокол, ще се провали по идентичен начин независимо дали URI е правилен, или не. OpenConnect замени стария клиент vpnc по причина и поддръжката на карти не прави несъвместим протокол на шлюза съвместим. Потвърдете очаквания протокол на сървъра и подредбата на удостоверяване, преди да похарчите още един час за атрибути на обекта.

Проверката на самоличността на сървъра също е отделен слой. Клиентът проверява сертификата на шлюза спрямо своето хранилище за доверие и тази проверка се изпълнява, след като картата вече е свършила своята част. Правата на четеца и спряната услуга pcscd дават същия външен симптом — нечетим токен — но с много по-просто решение.

Работете навън от обекта: вижда ли p11tool токена, вижда ли сертификата и ключа, приема ли OpenConnect URI, и едва тогава питайте дали шлюзът приема самоличността. Всяка стъпка има собствено съобщение за грешка и всяка е по-евтина за проверка от следващата.