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