Чому OpenVPN і далі вимагає файл закритого ключа, коли є токен

Ви вставляєте токен, інструмент самого постачальника його бачить, а клієнт VPN усе ще просить файл закритого ключа. Цей запит не доводить, що токен не підтримується. Зазвичай він означає, що профіль жодного разу не сказав клієнтові використовувати токен, тому той повернувся до вводів сертифіката й ключа, які очікує за замовчуванням.

Перш ніж цей відкат припиниться, мають бути правильними два окремі значення: провайдер, який надає токен, і ідентифікатор сертифіката всередині нього. Вони задаються різними параметрами, і їх легко переплутати.

Клієнт просить файл, бо так указано в профілі

Профіль за замовчуванням очікує файл сертифіката і файл закритого ключа або один пакет PKCS#12. Коли цих вводів немає, клієнтові нема чого завантажувати, і він поводиться майже як за відсутнього файлу, тому симптом читається як зламаний шлях, а не як відсутній механізм. Шлях PKCS#11 замінює ці вводи, а не доповнює їх, тож профіль, який усе ще вказує файл ключа, продовжить використовувати файл. Приберіть файлові вводи навмисно й дозвольте токену надати обидві половини.

Параметр провайдера називає бібліотеку проміжного програмного забезпечення, а не пристрій і не сертифікат. Чи може запакований клієнт завантажити цю бібліотеку, залежить від того, як його зібрано, зокрема від необов'язкової підтримки p11-kit, яку одні збірки вмикають, а інші пропускають. Загальний посібник не скаже, яка конфігурація у вашого пакета.

Серіалізований ідентифікатор — це інше значення

Ідентифікатор сертифіката — це довгий серіалізований рядок, який створює процес виявлення, і це не шлях до бібліотеки, не PIN токена і не назва облікового запису VPN. У ньому часто є символи, що потребують лапок, а значення без лапок може бути обрізане або прочитане неправильно без явної помилки. Скористайтеся власним параметром клієнта виявлення ідентифікатора, щоб перелічити те, що надає токен, а потім точно скопіюйте потрібний запис. Вибір першого об'єкта в списку — це шлях, яким пристрій зрештою подає не той сертифікат.

Вивід виявлення відповідає і на попереднє питання: чи видно токен через цього провайдера взагалі. Якщо він нічого не перелічує, проблема розташована вище клієнта VPN і належить проміжному програмному забезпеченню.

Процес, який установлює з'єднання, має дістатися до токена

Операція з токеном, яка працює у вашому сеансі робочого столу, нічого не доводить щодо системної служби. Служба може працювати від іншого користувача, у іншому просторі імен монтування, зі шляхом до модулів, який пропускає бібліотеку постачальника, або без права відкрити вузол пристрою. Визначте, який процес насправді утримує з'єднання, і перевіряйте з цього контексту.

Поводження з PIN заслуговує окремого рішення. Еталонна реалізація пропонує кеш PIN і захищений шлях автентифікації, і обидва існують для того, щоб оператор міг вибрати робочий процес, а не вигадувати його. Не перетворюйте вимогу без нагляду на PIN відкритим текстом усередині спільного профілю, бо це обмінює захист токена на зручність. Там, де токен забороняє експорт ключа, підписування відбувається на пристрої, і PIN є єдиним локальним секретом. Поводьтеся з ним з обережністю, яку це передбачає.

Що токен не замінює

Токен автентифікує клієнт згідно з розгорнутою політикою і не замінює перевірок клієнта щодо сервера. Успішно вибраний сертифікат не є дозволом приймати неочікуваний сертифікат шлюзу, і ці дві перевірки захищають протилежні напрямки.

Реєстрація все ще має відбуватися в емітента, і шлюз усе ще має авторизувати ідентифікатор.

Для приймання розділіть етапи: провайдер завантажується, потрібний сертифікат знаходиться, закритий ключ використовується з локальною авторизацією, VPN автентифікується, і операція з ресурсом завершується успішно. Зупиніться на першому невдалому етапі, а не перебирайте паролі й перевстановлюйте криптографічний стек.

Записуйте версії, належність модулів, вибраний публічний ідентифікатор і очищені помилки, а PIN і пакети облікових даних тримайте поза цим записом.