Правильний пароль VPN не замінить відсутній сертифікат

Облікові дані правильні, профіль імпортується чисто, і все ж з'єднання обривається до завершення автентифікації. У Windows повідомлення може бути помилкою 798 про сертифікат, який не знайдено для методу EAP. У OpenVPN журнал клієнта показує рукостискання TLS, яке так і не задовольняє сервер. Обидва описи стосуються одного й того самого відсутнього об'єкта: клієнтського сертифіката, який клієнт мав пред'явити.

Пароль доводить знання секрету; сертифікат доводить володіння ключем, і одне не замінює інше.

Пароль ніколи не був проблемою

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

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

Що має містити сховище клієнта

Задіяні два об'єкти. Клієнтський сертифікат має бути встановлений для користувача, який запускає клієнт VPN, разом із закритим ключем, а видавничий корінь має бути довіреним. Файл .cer містить лише відкритий сертифікат, тому сам по собі він нічого не автентифікує. У диспетчері сертифікатів Windows посвідчення клієнта належить до особистого сховища поточного користувача, а корінь — до сховища довірених коренів.

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

Два продукти, той самий відсутній реквізит

Сервери OpenVPN типово вимагають клієнтський сертифікат. Додавання auth-user-pass клієнту надсилає ім'я користувача й пароль, а рукостискання TLS усе ще запитує сертифікат, тож сам пароль не може завершити з'єднання за verify-client-cert require. Сервер можна налаштувати так, щоб він нічого не вимагав, і тоді пароль стає єдиним реквізитом клієнта, а це реальне послаблення. Shell-скрипт за auth-user-pass-verify може перевіряти реквізити, і для нього треба ввімкнути виконання скриптів, що робить його ризикованішим рішенням, ніж повноцінний бекенд автентифікації.

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

Не виправляйте відсутній сертифікат вимкненням перевірок

Спокуса — послабити перевірку, щоб повідомлення зникло. Це прибирає контроль, який виконував свою роботу, і залишає з'єднання, яке більше не доводить заявленого. Якщо шлюз нещодавно змінив свій корінь, завантажте клієнтський пакет заново замість редагування профілю, бо старий пакет може досі містити попередній корінь. Якщо в редакторі профілів немає параметра автентифікації за сертифікатом, можливо, встановлена версія Windows не надає цього методу; оновіть систему замість ручного редагування XML.

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

Пароль був гаразд. Реквізит, який насправді потрібен був методу, був в іншому місці.