Правильный пароль 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.

Запишите, в каком хранилище был сертификат, какой пользователь запускал клиент и присутствовал ли закрытый ключ. Эти три пункта объясняют почти каждый случай такого сбоя.

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