Які 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, а працэнтныя экраны кадуюць сімвалы, якія інакш зламалі б разбор, таму ўвесь аргумент павінен цэлым перажыць абалонку.

Пошук 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, і толькі потым пытайцеся, ці прымае брама асобу. Кожны крок мае ўласнае паведамленне пра памылку, і кожны каштуе танней за наступны.