Айку не удалось найти действительный сертификат компьютера

Обновлено: 03.07.2024

Тема Windows Server 2016, Always On VPN IKE в технической части; Во второй половине дня я следовал следующему руководству по настройке Always on VPN с IKE, но у меня возникли проблемы.

Обратная ссылка

Инструменты темы

Поиск темы

Всегда на VPN IKE

Я следовал следующему руководству по настройке Always on VPN с IKE, но у меня возникают проблемы с тем, что IKE не находит действительный сертификат компьютера, и я не знаю, почему.

Я использую Windows Server 2016 с RRAS и NPS. У меня есть общедоступный сертификат, который установлен в разделе «Локальный компьютер» > «Личные» > «Сертификаты», и два внутренних сертификата, хранящиеся в одном месте. Один частный сертификат имеет только следующую аутентификацию клиента и сервера EKU, тогда как другой сертификат имеет аутентификацию клиента и сервера, а также промежуточный IP-безопасность IKE.

Клиентский компьютер имеет сертификат пользователя с аутентификацией клиента и сертификат компьютера с аутентификацией клиента и сервера.

Может ли кто-нибудь помочь мне понять, где я ошибаюсь? Я знаю, что у Microsoft не так много документации по функции Always On VPN, но я хотел бы реализовать ее на новых ноутбуках для сотрудников.

Спасибо корейкилингу от:

Дата регистрации август 2007 г. Местоположение towels.retain.snake Сообщений: 2,601 Поблагодарили: 956 Поблагодарили: 817 раз в 439 сообщениях Репутация: 1041

Это в комментариях;

Отличная статья, очень хочется увидеть окончательные статьи!

К вашему сведению, я следовал этому письму в своей тестовой среде, но не смог развернуть сертификат пользователя. Разрешения и сертификат настроены правильно.

Оказывается, для «Провайдера криптографии платформы Microsoft» требуется микросхема TPM, поскольку я использовал виртуальную машину для клиентской машины (которая, очевидно, не имеет аппаратного обеспечения TPM). Я мог видеть сообщение об ошибке «Не удается найти действительный CSP в локальный компьютер" при попытке зарегистрировать сертификат вручную.

Решение состоит в том, чтобы также отметить «Поставщик хранилища ключей программного обеспечения Майкрософт» и сделать его вторым по порядку после «Поставщик криптографии платформы Microsoft»

Все сообщения с тегами IKE не смогли найти действительный сертификат компьютера

В дополнение к моему последнему сообщению об ошибке Always On VPN 13801 в этом сообщении будет рассмотрена похожая и связанная ошибка, с которой могут столкнуться администраторы, — ошибка 13806. Как упоминалось ранее, конфигурация сертификата имеет решающее значение для развертываний Always On VPN. Я описал некоторые конкретные требования к сертификатам для IKEv2 в этом предыдущем посте. Следуя этому руководству, у администраторов не должно возникнуть проблем с соединениями IKEv2 Always On VPN. Однако всегда можно столкнуться с ошибкой, если какой-либо из этих сертификатов отсутствует или неправильно настроен.

Ошибка 13806

Подобно описанной ранее ошибке 13801, ошибка 13806 также является распространенной. В случае сбоя соединения Always On VPN с использованием IKEv2 в журнале событий приложений Windows будет записано событие с идентификатором 20227 из источника RasClient. В сообщении об ошибке указано следующее:

«Пользователь [имя пользователя] набрал соединение с именем [имя соединения], которое не удалось. В случае сбоя возвращается код ошибки: 13806”.

IKE не удалось найти действительный сертификат компьютера

Ошибка 13806 преобразуется в ERROR_IPSEC_IKE_NO_CERT, что указывает на то, что протоколу IKE не удалось найти действительный сертификат компьютера. Проблема может быть связана с устройством, VPN-сервером или проблемой с конфигурацией VPN-сервера.

Сертификат устройства

Для туннеля устройства наиболее очевидной причиной этой ошибки является отсутствие сертификата проверки подлинности устройства на самом клиенте. Убедитесь, что конечная точка имеет действительный сертификат, выданный внутренней PKI организации, который включает EKU проверки подлинности клиента (OID 1.3.6.1.5.5.7.3.2). Сертификат должен иметь имя субъекта, соответствующее полному доменному имени устройства. Он также должен быть действительным (не просроченным), доверенным и не отозванным.

Цепочка сертификатов

Ошибка 13806 возникает, если сертификат устройства, установленный на клиенте, не является доверенным или если клиент не доверяет сертификату, установленному на VPN-сервере. Убедитесь, что у клиента установлены все необходимые корневые и промежуточные сертификаты центра сертификации (ЦС) в соответствующих хранилищах сертификатов.

Сертификат VPN-сервера

Ошибка 13806 также может возникнуть, если сервер VPN не имеет правильно настроенного сертификата сервера. Убедитесь, что VPN-сервер имеет действующий сертификат, выданный внутренней PKI организации, который включает в себя как аутентификацию сервера (OID 1.3.6.1.5.5.7.3.1), так и промежуточный IP-безопасность IKE (OID 1.3.6.1.5.5.8.2.2) EKU. . Имя субъекта должно соответствовать общедоступному полному доменному имени (FQDN), используемому VPN-клиентами для подключения к VPN-серверу (а не NetBIOS-имени сервера).Опять же, убедитесь, что сертификат действителен (срок его действия не истек), доверен, не отозван, а все необходимые корневые и промежуточные сертификаты ЦС установлены в соответствующих хранилищах сертификатов.

Отзыв сертификата

Список отзыва сертификатов (CRL) с истекшим сроком действия также может привести к ошибке 13801. Откройте консоль Enterprise PKI (pkiview.msc) в выпускающем ЦС и проверьте состояние всех CRL. Если какие-либо из них просрочены, устраните все проблемы, препятствующие успешной публикации списка отзыва сертификатов, а затем создайте новый список отзыва сертификатов, запустив certutil.exe -crl на выпускающем сервере ЦС.

Конфигурация RRAS

Еще одной причиной ошибки 13806 для пользовательского туннеля является неправильно настроенный VPN-сервер службы маршрутизации и удаленного доступа (RRAS). Ошибка 13806 может произойти, если администратор неправильно определяет доверенный корневой ЦС с помощью Set-VpnAuthProtocol. Убедитесь, что отпечаток корневого сертификата точно совпадает с отпечатком корневого сервера CA, используемого для выдачи сертификатов VPN-устройствам и VPN-серверу.

Отпечаток корневого сертификата ЦС

Разрешение

Убедитесь, что на устройствах и VPN-серверах установлены правильно настроенные сертификаты. Если корневой сертификат ЦС неправильно назначен на VPN-сервере, следуйте инструкциям, приведенным здесь, чтобы обновить конфигурацию.

Всегда в сети VPN — Пользовательский туннель — IKE не удалось найти действительный сертификат компьютера

Я настроил инфраструктуру Always on VPN (пользовательский туннель) с Windows Server 2019 для серверов VPN и NPS. Когда я пытаюсь подключиться из Windows 10, появляется сообщение об ошибке: IKE не удалось найти действительный сертификат компьютера.

Eventviewer на ноутбуке показывает код ошибки 13806, в то время как журналы CAPI2 на сервере RRAS показывают ошибки с идентификаторами событий 11, 41 и 42 (сборка цепочки, проверка информации об отзыве и отклонение информации об отзыве) для проверки сертификата VPN-сервера.

Все сертификаты (корневой и подчиненный) установлены.

Может ли кто-нибудь помочь мне решить проблему, пожалуйста?

2 ответа

Что касается вашей проблемы, вот мои предложения:

"Код ошибки 13806" обычно возникает, когда на VPN-сервере отсутствует сертификат компьютера или корневой сертификат компьютера. Убедитесь, что сертификаты, описанные в этом развертывании, установлены как на клиентском компьютере, так и на VPN-сервере.

Сертификат сервера. Сертификат IKEv2 на VPN-сервере должен быть выдан внутренним частным центром сертификации (ЦС) организации. Он должен быть установлен в хранилище сертификатов «Локальный компьютер/Личный» на VPN-сервере. Имя субъекта в сертификате должно соответствовать полному доменному имени, используемому VPN-клиентами для подключения к серверу.
Кроме того, сертификат должен включать EKU проверки подлинности сервера (1.3.6.1.5.5.7.3.1) и промежуточный EKU IP-безопасности IKE (1.3.6.1.5.5.8.2.2).

Сертификат клиента (пользовательский туннель): если при использовании PEAP выбран вариант проверки подлинности сервера путем проверки сертификата, клиент должен иметь сертификаты для корневого ЦС и всех подчиненных ЦС, установленных в доверенном корневом сертификате и промежуточном сертификате. Хранилища сертификатов центров сертификации.

-------Если мой ответ полезен для вас, не забудьте отметить его как ответ. Спасибо!------

Я пытаюсь настроить VPN-подключение со следующими настройками:

Тип VPN: IKEv2
Аутентификация: использовать сертификат компьютера
DHGroup: ECP256 или ECP384

Когда я пытаюсь подключиться к этому VPN, я получаю следующую ошибку:

Когда я изменяю конфигурацию на DHGroup "Group14", соединение устанавливается успешно.

Эта ошибка возникает только при использовании одной из групп ECPxxx DHGroups.

Ниже приведен вывод команды, который показывает рабочий сценарий + обновление конфигурации + сценарий сбоя:

Сервер VPN настроен на прием любой из следующих групп DHGroups: Group14, ECP256, ECP384.

Когда я пытаюсь подключиться, используя другую DHGroup, я получаю совершенно другую ошибку:

Когда я пытаюсь подключиться с помощью Group14, но у меня нет установленного сертификата, я также получаю сообщение об ошибке "IKE не удалось найти действительный сертификат компьютера".

Похоже, что при использовании одной из ECPxxx DHGroups требования к сертификату отличаются.

Я пытался удалить/создать заново сертификат с другими настройками:

аутентификация клиента
аутентификация клиента + аутентификация сервера
все варианты использования ключей + все EKU

но мне не удалось установить соединение.

Я нашел документ, объясняющий требования к сертификату для серверной стороны, но не для клиентского сертификата.

Есть идеи, как это исправить?

Все ответы

Давайте искать решение отсюда.

Настройка IKEv2/Windows 10

Удалось ли вам разблокировать ситуацию?

Я могу подтвердить это поведение. PfsGroup можно без проблем переключить на ECP384. Но как только я переключаю DHGroup на ECP384, клиенты не могут установить VPN.

Конфигурация:
Windows 10 Pro v1803
IPFire v2.21 Build 123
IKEv2 с использованием сертификатов компьютера

Я столкнулся с той же проблемой, когда настраивал свою инфраструктуру VPN: она выдавала ошибку с идентификатором события 20227 и кодом ошибки. При сбое возвращался код ошибки 13806. Проблема была вызвана недоступностью сертификата в локальном хранилище VPN-сервер. После установки необходимых сертификатов в хранилище сертификатов VPN-сервера ошибка исчезла

Инфраструктура Windows Shajeer.K

Учитывая, насколько тщательно был изучен первоначальный вопрос (включая «удаление/повторное создание сертификата с другими настройками»), вероятно возникает подозрение, что может потребоваться сертификат с ключом ECDSA, и это действительно так. Это требование является артефактом реализации Microsoft, а не самим протоколом IKEv2.

RFC 4754 (Аутентификация IKE и IKEv2 с использованием алгоритма цифровой подписи на эллиптических кривых (ECDSA)) говорит в разделе 1:

Для любого заданного уровня защиты от лучших известных атак подписи ECDSA
меньше, чем подписи RSA, а ключи ECDSA требуют
меньшей пропускной способности, чем ключи DSA [LV]; есть также преимущества скорости вычислений и эффективности во многих настройках. Дополнительная
эффективность может быть достигнута за счет одновременного использования ECDSA для
аутентификации IKE/IKEv2 и использования групп эллиптических кривых для
обмена ключами IKE/IKEv2. Поэтому разработчики IPsec и IKE/IKEv2 могут счесть
желательным использовать ECDSA в качестве метода аутентификации Phase 1/IKE-AUTH.

Microsoft серьезно восприняла этот совет.

При использовании проверки подлинности машинного сертификата реализация Microsoft жестко связывает подробный механизм проверки подлинности IKEv2 с группой DH, используемой в сообщении IKE_SA_INIT. Для DH-ECP-256 (группа 19) метод аутентификации 9 (ECDSA с SHA-256 на кривой P-256) отправляется в полезной нагрузке аутентификации; для DH-ECP-384 (группа 20) отправляется Auth Method 10 (ECDSA с SHA-384 на кривой P-384); для других групп DH, поддерживаемых Microsoft, отправляется метод аутентификации 1 (цифровая подпись RSA).

Этот процесс выбора метода проверки подлинности происходит при настройке туннеля IKEv2 (путем вызова FwpmIPsecTunnelAdd2) в BFE (базовом механизме фильтрации) и до выполнения поиска доступных/подходящих сертификатов. Контекст поставщика BFE IKEv2 фазы 1 (основной режим), который настраивается, когда указана группа DH ECP256, выглядит следующим образом:

Несмотря на то, что в контекст включены 3 метода аутентификации, только первый указывает действительный тип outboundConfigType.

Длина ключа ECDSA используемого сертификата должна соответствовать длине группы DH.

Устранение неполадок Always On VPN

Применимо к: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10

Если при настройке Always On VPN не удается подключить клиентов к вашей внутренней сети, причиной, скорее всего, является недействительный сертификат VPN, неправильные политики NPS или проблемы со сценариями развертывания клиентов или с маршрутизацией и удаленным доступом. Первым шагом в устранении неполадок и тестировании VPN-подключения является понимание основных компонентов инфраструктуры Always On VPN.

Устранить неполадки с подключением можно несколькими способами. Журналы приложений на клиентских компьютерах бесценны при проблемах на стороне клиента и при устранении общих неполадок. В случае проблем, связанных с проверкой подлинности, журнал NPS на сервере NPS может помочь определить источник проблемы.

Описание ошибки. Удаленное подключение не было установлено, так как попытка туннелирования VPN не удалась. Сервер VPN может быть недоступен. Если это подключение пытается использовать туннель L2TP/IPsec, параметры безопасности, необходимые для согласования IPsec, могут быть настроены неправильно.

Возможная причина. Эта ошибка возникает, когда для типа туннеля VPN установлено значение "Автоматически" и попытка подключения не удалась для всех туннелей VPN.

Возможные решения:

Если вы знаете, какой туннель использовать для своего развертывания, установите тип VPN на этот конкретный тип туннеля на стороне VPN-клиента.

При установлении VPN-подключения с определенным типом туннеля ваше подключение все равно не будет выполнено, но это приведет к ошибке, связанной с туннелем (например, "GRE заблокирован для PPTP").

Эта ошибка также возникает, когда VPN-сервер недоступен или не удается установить туннельное соединение.

Порты IKE (UDP-порты 500 и 4500) не блокируются.

Правильные сертификаты для IKE присутствуют как на клиенте, так и на сервере.

Описание ошибки. Не удалось установить сетевое соединение между вашим компьютером и сервером VPN, так как удаленный сервер не отвечает.Это может быть связано с тем, что одно из сетевых устройств (например, брандмауэры, NAT, маршрутизаторы) между вашим компьютером и удаленным сервером не настроено на разрешение VPN-соединений. Обратитесь к администратору или поставщику услуг, чтобы определить, какое устройство может быть причиной проблемы.

Возможная причина. Эта ошибка вызвана блокировкой портов UDP 500 или 4500 на сервере VPN или брандмауэре.

Возможное решение. Убедитесь, что порты UDP 500 и 4500 разрешены через все брандмауэры между клиентом и сервером RRAS.

Описание ошибки. Не удается подключиться к Always On VPN. Соединение было запрещено из-за политики, настроенной на вашем сервере RAS/VPN. В частности, метод аутентификации, который сервер использовал для проверки вашего имени пользователя и пароля, может не совпадать с методом аутентификации, настроенным в вашем профиле подключения. Пожалуйста, свяжитесь с администратором сервера RAS и сообщите ему или ей об этой ошибке.

Возможные причины:

Обычная причина этой ошибки заключается в том, что сервер политики сети указал условие проверки подлинности, которое клиент не может выполнить. Например, сервер политики сети может указать использование сертификата для защиты подключения PEAP, но клиент пытается использовать EAP-MSCHAPv2.

Журнал событий 20276 регистрируется в средстве просмотра событий, когда настройка протокола аутентификации VPN-сервера на основе RRAS не соответствует настройке протокола VPN-клиента.

Возможное решение. Убедитесь, что конфигурация вашего клиента соответствует условиям, указанным на сервере NPS.

Код ошибки: 13806

Описание ошибки. IKE не удалось найти действительный сертификат компьютера. Обратитесь к администратору сетевой безопасности по поводу установки действительного сертификата в соответствующем хранилище сертификатов.

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

Возможное решение. Убедитесь, что сертификаты, описанные в этом развертывании, установлены как на клиентском компьютере, так и на VPN-сервере.

Код ошибки: 13801

Описание ошибки. Учетные данные для аутентификации IKE неприемлемы.

Возможные причины. Эта ошибка обычно возникает в одном из следующих случаев:

Сертификат компьютера, используемый для проверки IKEv2 на сервере RAS, не имеет проверки подлинности сервера в расширенном использовании ключа.

Срок действия сертификата компьютера на сервере RAS истек.

Корневой сертификат для проверки сертификата сервера RAS отсутствует на клиентском компьютере.

Имя VPN-сервера, используемое на клиентском компьютере, не совпадает с subjectName сертификата сервера.

Возможное решение. Убедитесь, что сертификат сервера включает проверку подлинности сервера в разделе «Расширенное использование ключа». Убедитесь, что сертификат сервера все еще действителен. Убедитесь, что используемый центр сертификации указан в списке доверенных корневых центров сертификации на сервере RRAS. Убедитесь, что VPN-клиент подключается, используя полное доменное имя VPN-сервера, указанное в сертификате VPN-сервера.

Код ошибки: 0x80070040

Описание ошибки. В сертификате сервера нет проверки подлинности сервера в качестве одной из записей об использовании сертификата.

Возможная причина. Эта ошибка может возникнуть, если на сервере RAS не установлен сертификат проверки подлинности сервера.

Возможное решение. Убедитесь, что сертификат компьютера, который сервер RAS использует для IKEv2, имеет проверку подлинности сервера в качестве одной из записей использования сертификата.

Код ошибки: 0x800B0109

Как правило, клиентский компьютер VPN присоединяется к домену на основе Active Directory. Если вы используете учетные данные домена для входа на VPN-сервер, сертификат автоматически устанавливается в хранилище доверенных корневых центров сертификации. Однако, если компьютер не присоединен к домену или вы используете альтернативную цепочку сертификатов, вы можете столкнуться с этой проблемой.

Описание ошибки. Цепочка сертификатов обработана, но завершена корневым сертификатом, которому не доверяет поставщик доверия.

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

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

Журналы приложений на клиентских компьютерах записывают большую часть высокоуровневых сведений о событиях VPN-подключений.

Ищите события из исходного RasClient. Все сообщения об ошибках возвращают код ошибки в конце сообщения. Некоторые из наиболее распространенных кодов ошибок подробно описаны ниже, но полный список доступен в разделе Коды ошибок маршрутизации и удаленного доступа.

NPS создает и хранит журналы учета NPS. По умолчанию они хранятся в папке %SYSTEMROOT%\System32\Logfiles\ в файле с именем INXXXX.txt, где XXXX — дата создания файла.

По умолчанию эти журналы имеют формат значений, разделенных запятыми, но не содержат строки заголовка. Строка заголовка:

Если вы вставите эту строку заголовка в качестве первой строки файла журнала, а затем импортируете файл в Microsoft Excel, столбцы будут правильно помечены.

Журналы NPS могут быть полезны при диагностике проблем, связанных с политикой. Дополнительные сведения о журналах NPS см. в статье Интерпретация файлов журнала формата базы данных NPS.

Проблемы со сценарием VPN_Profile.ps1

К наиболее частым проблемам при ручном запуске сценария VPN_ Profile.ps1 относятся:

Используете ли вы инструмент удаленного подключения? Убедитесь, что вы не используете RDP или другой метод удаленного подключения, так как это мешает обнаружению входа пользователя в систему.

Является ли пользователь администратором этой локальной машины? Убедитесь, что при запуске сценария VPN_Profile.ps1 у пользователя есть права администратора.

Включены ли у вас дополнительные функции безопасности PowerShell? Убедитесь, что политика выполнения PowerShell не блокирует сценарий. Перед запуском скрипта вы можете отключить режим ограниченного языка, если он включен. Вы можете активировать ограниченный языковой режим после успешного завершения скрипта.

Проблемы с подключением клиента Always On VPN

Небольшая неправильная конфигурация может привести к сбою подключения клиента, и найти причину может быть сложно. Клиент Always On VPN проходит несколько этапов, прежде чем установить соединение. При устранении неполадок с подключением клиентов пройдите процесс устранения следующим образом:

Подключен ли компьютер шаблона извне? Сканирование whatismyip должно показывать общедоступный IP-адрес, который вам не принадлежит.

Можно ли преобразовать имя сервера удаленного доступа/VPN в IP-адрес? В Панели управления > Сеть и Интернет > Сетевые подключения откройте свойства своего профиля VPN. Значение на вкладке «Общие» должно быть общедоступным через DNS.

Можете ли вы получить доступ к VPN-серверу из внешней сети? Рассмотрите возможность открытия протокола управляющих сообщений Интернета (ICMP) для внешнего интерфейса и проверки связи с удаленным клиентом. После успешной проверки связи вы можете удалить разрешающее правило ICMP.

Правильно ли настроены внутренние и внешние сетевые карты на сервере VPN? Они в разных подсетях? Подключается ли внешний сетевой адаптер к правильному интерфейсу брандмауэра?

Открыты ли порты UDP 500 и 4500 от клиента к внешнему интерфейсу VPN-сервера? Проверьте брандмауэр клиента, брандмауэр сервера и любые аппаратные брандмауэры. IPSEC использует UDP-порт 500, поэтому убедитесь, что IPEC нигде не отключен и не заблокирован.

Не проходит ли проверка сертификата? Убедитесь, что сервер политики сети имеет сертификат проверки подлинности сервера, который может обслуживать запросы IKE. Убедитесь, что в качестве клиента NPS указан правильный IP-адрес VPN-сервера. Убедитесь, что вы выполняете аутентификацию с помощью PEAP, а свойства Protected EAP должны разрешать аутентификацию только с помощью сертификата. Вы можете проверить журналы событий NPS на наличие ошибок аутентификации. Дополнительные сведения см. в разделе Установка и настройка сервера политики сети

Вы подключаетесь, но у вас нет доступа к Интернету/локальной сети? Проверьте пулы IP-адресов DHCP/VPN-серверов на наличие проблем с конфигурацией.

Вы подключаетесь и имеете действительный внутренний IP-адрес, но не имеете доступа к локальным ресурсам? Убедитесь, что клиенты знают, как получить доступ к этим ресурсам. Вы можете использовать VPN-сервер для маршрутизации запросов.

Проблемы с условным доступом к Azure AD

К сожалению, вы еще не можете добраться до этого

Описание ошибки. Когда политика условного доступа не выполняется, VPN-подключение блокируется, но подключается после того, как пользователь выбирает X, чтобы закрыть сообщение. Выбор OK вызывает еще одну попытку аутентификации, которая заканчивается другим сообщением «Oops». Эти события записываются в журнал рабочих событий AAD клиента.

Возможная причина

У пользователя есть действительный сертификат проверки подлинности клиента в хранилище личных сертификатов, который не был выпущен Azure AD.

Раздел профиля VPN либо отсутствует, либо не содержит записей условного доступа AAD 1.3.6.1.4.1.311.87 условного доступа AAD 1.3.6.1.4.1.311.87. Записи и сообщают VPN-клиенту, какой сертификат следует извлечь из хранилища сертификатов пользователя при передаче сертификата на VPN-сервер. Без этого клиент VPN использует любой действительный сертификат проверки подлинности клиента, который находится в хранилище сертификатов пользователя, и проверка подлинности проходит успешно.

Сервер RADIUS (NPS) не настроен для приема только клиентских сертификатов, содержащих OID условного доступа AAD.

Возможное решение. Чтобы выйти из этого цикла, сделайте следующее:

В Windows PowerShell запустите командлет Get-WmiObject, чтобы получить дамп конфигурации профиля VPN.

Убедитесь, что разделы , , и существуют и отображают правильное имя и OID.

ложно верно верно derras2. corp.deverett.info;derras2.corp.deverett.info ForceTunnel Ikev2 Eap Eap 25 0 0 0 25 true true false 13 true true 5a 89 fe cb 5b 49 a7 0b 1a 52 63 b7 35 ee d7 1c c2 68 be 4b false se

RememberCredentials : False TrustedNetworkDetection : PSComputerName : DERS2">

Чтобы определить, есть ли действительные сертификаты в хранилище сертификатов пользователя, выполните команду Certutil:

[!NOTE] Если сертификат от издателя CN = Microsoft VPN root CA gen 1 присутствует в личном хранилище пользователя, но пользователь получил доступ, нажав X, чтобы закрыть сообщение Oops, соберите журналы событий CAPI2, чтобы убедитесь, что сертификат, используемый для проверки подлинности, является действительным сертификатом проверки подлинности клиента, который не был выдан корневым ЦС Microsoft VPN.

Если в личном хранилище пользователя существует действующий сертификат проверки подлинности клиента, соединение завершается сбоем (как и должно быть) после того, как пользователь выбирает X и если разделы , и существуют и содержат правильную информацию.

Появляется сообщение об ошибке "Не удалось найти сертификат, который можно использовать с расширяемым протоколом аутентификации".

Не удалось удалить сертификат из блейда подключения к VPN

Описание ошибки. Сертификаты на колонке подключения VPN нельзя удалить.

Возможная причина. Сертификат установлен как основной.

Читайте также: