Кој 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 нема регистриран модул за таа средна програма, или модулот е регистриран за друга сметка. Системската регистрација се наоѓа под /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, и само тогаш прашајте дали портата го прифаќа идентитетот. Секој чекор има своја порака за грешка и секој е поевтин за тестирање од следниот.