Який PKCS#11 URI потрібен OpenConnect для токена?

OpenConnect потрібен PKCS#11 URI, який називає сертифікат і ключ токена, а не експортований PEM. Знайдіть об'єкт, що відповідає реєстрації, і візьміть його в лапки.

Смарт-карта, яка вже містить правильний ключ, усе одно має отримати вказівку, який об'єкт на ній використовувати. 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, і лише потім питайте, чи приймає шлюз особу. Кожен крок має власне повідомлення про помилку, і кожен дешевше перевірити, ніж наступний.

Схожі статті