Windows 8.1 Enterprise Windows 8.1 Pro Windows 8.1 Windows RT 8.1 Windows Server 2012 R2 Datacenter Windows Server 2012 R2 Essentials Windows Server 2012 R2 Foundation Windows Server 2012 R2 Standard Еще…Меньше
В данной статье описывается проблема, при algorithmin подписи Windows RT 8.1 Windows 8.1 или Windows Server 2012 R2 с помощью эллиптических кривых цифровой подписи алгоритм ECDSA. Неполадки в 2962409 накопительный пакет обновления или исправление 2961892, описанное в данной статье и необходимых компонентов.
Симптомы
Рассмотрим следующий сценарий:
-
У центра сертификации (ЦС), соответствует стандартам Suite B (эллиптических кривых), и центр сертификации выдает сертификаты компьютеров для проверки подлинности протокола IP-безопасность (IPsec), используя в качестве алгоритма подписи ECDSA.
-
У вас есть Windows RT 8.1, Windows 8.1 или компьютерах под управлением Windows Server 2012 R2, запросить сертификат IPSec из центра сертификации.
-
Настроить Internet Key Exchange версии 2 (IKEv2) VPN на клиентском компьютере.
-
Включите параметр Разрешить проверку подлинности сертификата компьютера для IKEv2на сервере.
В этом случае при попытке подключения к серверу с использованием VPN IKEv2 с клиентского компьютера, установить подключение не удастся, и появляется следующее сообщение об ошибке:
Ошибка 13806 — сервер не имеет установленного сертификата, который подходит для использования с IKEv2
Решение
Чтобы устранить эту проблему, установите накопительный пакет обновления 2962409 или установить исправление, описанное в данной статье.
Сведения об обновлении
Дополнительные сведения о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2962409 Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.
Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Это исправление необходимо сначала установить обновление 2919355 Windows RT 8.1, Windows 8.1 или Windows Server 2012 R2. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:
2919355 Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Сведения о файле Windows 8.1 и Windows Server 2012 R2 и заметкиВажно. Windows Server 2012 R2 исправления и исправления Windows 8.1 включаются в тех же самых пакетов. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Для получения пакета исправлений, который применяется к одной или обеих операционных систем, установите исправления, перечисленные в разделе «Windows 8.1/Windows Server 2012 R2» на странице. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.
-
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.
Версия
Продукт
Контрольная точка
Направление поддержки
6.3.960 0.17xxx
Windows 8.1 и Windows Server 2012 R2
RTM
GDR
-
Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах». MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Для всех поддерживаемых 32-разрядных версий Windows 8.1
|
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
|---|---|---|---|---|---|
|
Vpnike.dll |
6.3.9600.17111 |
323,072 |
30-Apr-2014 |
03:15 |
x86 |
Для всех поддерживаемых 64-разрядных версий Windows 8.1 и Windows Server 2012 R2
|
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
|---|---|---|---|---|---|
|
Vpnike.dll |
6.3.9600.17111 |
403,968 |
30-Apr-2014 |
03:42 |
x64 |
Для Windows RT 8.1
|
Имя файла |
Версия файла |
Размер файла |
Дата |
Время |
Платформа |
|---|---|---|---|---|---|
|
Vpnike.dll |
6.3.9600.17111 |
271,360 |
30-Apr-2014 |
02:39 |
Неприменимо |
Статус
Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».
Дополнительные сведения
Для получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи базы знаний Майкрософт:
Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт.
Сведения о дополнительных файлах
Нужна дополнительная помощь?
Нужны дополнительные параметры?
Изучите преимущества подписки, просмотрите учебные курсы, узнайте, как защитить свое устройство и т. д.
В сообществах можно задавать вопросы и отвечать на них, отправлять отзывы и консультироваться с экспертами разных профилей.
More of the same. I import valid ssl certificates to a windows 7 64bit professional work station (three workstations actually)
I’ve set up an IKEv2 VPN connection definition that is set for machine certificates, NO User/PW signon.
(although windows doesn’t explain what a»machine» certificate is)
I import the client certificate into the machine personal certificate store.
I import the self-signed CA (Certificate Authority) into the machine Trusted Certificates Authority store.
via mmc I do a find for each certificate using the issuer string, and the system finds both certificates.
I’m trying to connect a windows 7 client to a Redhat Linux 7 server.
However whenever I try to start a VPN connection it ALWAYS fails with a 13806 error message to wit:
Error 13806 IKE failed to find a valid machine certificate. Contact your Network Security Administrator about installing a valid
certificate in the appropriate Certificate Store.
However when I use mmc to find the CA and the client certificate, mmc ALWAYS finds them. It’s the same behavior on all 3 systems.
each system has it’s own unique client cert, and they all used the same self-signed CA.
Looking at the message it says «failed to find a valid machine certificate» Does this mean the certificate it found is invalid?
If it is WHY doesn’t the «error msg handler logic» dump the certificate and display what makes the certificate invalid???
In the second part of the message;
Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.
Why doesn’t the «error message handler» specify exactly which certificate store is the appropriate store??
Is there some way of defining a certificate store to the IKEv2 VPN connection definition? (as it’s done in Unix & Linux, and z/OS)
Any ideas and/or suggestions are appreciated.
Best regards
Guy
Windows 7 supports IPSec IKEv2 with machine certificate authentication. Using StrongSwan on Linux for server, this is a good solution for Road Warrior remote access.
The problem with Windows 7 IKEv2 client is that it does not provide any log for trouble-shooting at all. So if it does not like something in your setup, it simply throws an error number and a very vague error message. Error 13806 is one of them.
I spent a few days finally got my Windows 7 running IKEv2 machine authentication with my strongswan server. Below are a few tips for Error 13806:
1. Error 13806 is because the machine certificate or CA certificate on the Windows 7 has problems. This is NOT about the Server’s certificate. So focus on fixing the Windows 7 certificates. The error message does not really tell you this clearly.
2. There are a few variables in your client certificate that are important, whether you use OpenSSL or StrongSwan ipsec pki to generate your certs:
- The Common Name (CN) in the subject of your certificate
- The Subject Alternative Name (SAN)
- The Key Usage
- The Extended Key Usage, where you can specify «clientAuth», «serverAuth», «1.3.6.1.5.5.8.2.2», either one or a combination of them.
Here is what works and what does not work in my tests (For Windows 7 client only, not for StrongSwan server):
- You do not need to set Key Usage and Extended Key Usage(EKU). If you set them, some combinations may cause trouble. see more below.
- You do not need to set SAN. If you really want to set it, it has to be exactly the same as the CN. Otherwise you will get Error 13806.
- Set CN to either a full DNS name such as «win7.mycompany.local», or just a string name «win7». Either one works.
- If you set Key Usage to «nonRepudiation, digitalSignature, keyEncipherment», and Extended Key Usage to «1.3.6.1.5.5.8.2.2,serverAuth,clientAuth», you MUST set your CN to the long form of DNS name such as «win7.mycompany.local». Using the short form «win7» will fail and cause error 13806.
The name win7.mycompany.local does not have to be in your DNS server.
What works:
- CN=»win7″, no SAN, No Keyusage, No EKU.
- CN=»win7″, SAN=»win7″, No Keyusage, No EKU.
- CN=»win7.mycompany.local», SAN=»win7.mycompany.local», No Keyusage, No EKU.
- CN=»win7.mycompany.local», SAN=»win7.mycompany.local»,keyUsage = nonRepudiation, digitalSignature, keyEncipherment, extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth,clientAuth
What does not work (Error 13806):
- CN=»win7″, SAN=»something else», No Keyusage, No EKU.
- CN=»win7″, SAN=»win7″,keyUsage = nonRepudiation, digitalSignature, keyEncipherment, extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth,clientAuth
Your server certificate should have the following:
- CN
- SAN, which should be exactly the same as your CN
- keyUsage = nonRepudiation, digitalSignature, keyEncipherment,
- extendedKeyUsage = 1.3.6.1.5.5.8.2.2,serverAuth
Your Windows 7 VPN connection host name should exactly the same as the Server’s CN. And that CN name should be DNS resolvable. The easiest way to do that in a test environment is to add the CN name to your local computer’s host file, located at «c:windowssystem32driversetchosts»
Andreas at StrongSwan also pointed out to me that although ECDSA has been supported by Windows since Windows Vista, it only works in IKEv1. IKEv2 in Windows 7 and Windows 2008 R2 does not support ECDSA. I have also personally verified that this is true.
One more important note:
Please make sure all your certificates has the PKIX recommended «Authority Key Identifier» in it. Otherwise, Windows 7 will give an Error 13806.
If you use OpenSSL to generate your certs, make sure the following line is in your openssl.conf file:
authorityKeyIdentifier=keyid,issuer
«Subject Key Identifier» seems to be optional for Windows 7.
Another useful post on this subject: http://forums.opensuse.org/english/get-technical-help-here/network-internet/435097-strongswan-opensuse-11-2-quick-setup.html
More Update:
Following above-written rules, I was able to generate certificates using StrongSwan ipsec pki command for both Windows 7 and StrongSwan, and the IKEv2 connection was established.
Here are the scripts:
First, Generate the CA:
bits=2048
ipsec pki —gen —type rsa —size $bits —outform pem > ca.key
ipsec pki —self —flag serverAuth —in ca.key —type rsa —digest sha1 —dn «C=CH, O=strongSwan, CN=pkiCA» —ca > caCert.der
Next, generate two certs, one for Server and one for Win7
bits=2048
for user in server win7; do
ipsec pki —gen —type rsa —size $bits —outform pem > $user.key
flags=»»;
[ «$user» = «server» ] && flags=»—flag serverAuth»;
ipsec pki —pub —in $user.key —type rsa | ipsec pki —issue —cacert caCert.der —cakey ca.key —digest sha1
—dn «C=CH, O=strongSwan, CN=$user.mycompany.local» —san «$user.mycompany.local» $flags —outform pem > $user.cert
done;
Next convert Win7 cert to P12 format:
# Usage: ./convert-to-p12.sh Username
user=$1
openssl pkcs12 -export -inkey $user.key -in $user.cert -name «$user» -certfile caCert.der -caname «vpnserver7» -out $user.p12
then run ./convert-to-p12.sh win7
Next convert Server key to DER format so that Strongswan can take it:
openssl rsa -in $1.key -out $1.der -outform DER
where $1 is «server»
As a follow-up to my last post regarding Always On VPN error 13801, this post will cover a similar and related error administrators may encounter, the 13806 error. As mentioned previously, certificate configuration is crucial for Always On VPN deployments. I described some specific certificates requirements for IKEv2 in this earlier post. Following this guidance, administrators should have no issues with IKEv2 Always On VPN connections. However, it is always possible to encounter an error if any of these certificates are missing or misconfigured.
Error 13806
Much like the error 13801 described previously, 13806 is also common. When an Always On VPN connection using IKEv2 fails, the Windows Application event log will record an event ID 20227 from the RasClient source. The error message states the following:
“The user [username] dialed a connection named [connection name] which has failed. The error code returned on failure is 13806”.
IKE Failed To Find Valid Machine Certificate
Error 13806 translates to ERROR_IPSEC_IKE_NO_CERT, indicating IKE failed to find a valid machine certificate. The problem can be on the device, the VPN server, or an issue with the VPN server configuration.
Device Certificate
For the device tunnel, the most obvious cause of this error is a missing device authentication certificate on the client itself. Ensure the endpoint has a valid certificate issued by the organization’s internal PKI that includes Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2). The certificate must have a subject name matching the device’s FQDN. It must also be valid (not expired), trusted, and not revoked.
Certificate Chain
A 13806 error will occur if the device certificate installed on the client is not trusted or if the client does not trust the certificate installed on the VPN server. Ensure the client has all the necessary root and intermediate certification authority (CA) certificates installed in their respective certificate stores.
VPN Server Certificate
A 13806 error can also occur if the VPN server does not have a properly configured server certificate. Ensure the VPN server has a valid certificate issued by the organization’s internal PKI that includes both the Server Authentication (OID 1.3.6.1.5.5.7.3.1) and IP security IKE intermediate (OID 1.3.6.1.5.5.8.2.2) EKUs. The subject name must match the public fully qualified domain name (FQDN) used by VPN clients to connect to the VPN server (not the server’s NetBIOS name). Again, ensure the certificate is valid (not expired), trusted, not revoked, and all necessary root and intermediate CA certificates are installed in their respective certificate stores.
Certificate Revocation
An expired Certificate Revocation List (CRL) can also result in a 13806 error. Open the Enterprise PKI console (pkiview.msc) on an issuing CA and review the status of all CRLs. If any are expired, resolve any issues preventing the CRL from publishing successfully, then issue a new CRL by running certutil.exe -crl on the issuing CA server.
RRAS Configuration
Another cause of the 13806 error for the user tunnel is a misconfigured Routing and Remote Access Service (RRAS) VPN server. An error 13806 can happen if the administrator incorrectly defines a trusted root CA using Set-VpnAuthProtocol. Ensure that the root certificate thumbprint matches exactly the root CA server’s thumbprint used to issue certificates to VPN devices and the VPN server.
Get-VpnAuthProtocol
Root CA Certificate Thumbprint
Resolution
Ensure that devices and VPN servers have correctly configured certificates installed. If the root CA certificate is assigned incorrectly on the VPN server, follow the guidelines detailed here to update the configuration.
Additional Information
Microsoft Windows Always On VPN Error 13801
Microsoft Windows Always On VPN Certificate Requirements for IKEv2
Microsoft Windows Always On VPN IPsec Root Certificate Configuration Issue
Microsoft Windows Always On VPN IKEv2 Policy Mismatch Error
Microsoft Windows Always On VPN IKEv2 Security Configuration
Microsoft Windows Always On VPN IKEv2 Fragmentation
Microsoft Windows Always On VPN IKEv2 Load Balancing and NAT
Microsoft Windows Always On VPN IKEv2 Features and Limitations
More of the same. I import valid ssl certificates to a windows 7 64bit professional work station (three workstations actually)
I’ve set up an IKEv2 VPN connection definition that is set for machine certificates, NO User/PW signon.
(although windows doesn’t explain what a»machine» certificate is)
I import the client certificate into the machine personal certificate store.
I import the self-signed CA (Certificate Authority) into the machine Trusted Certificates Authority store.
via mmc I do a find for each certificate using the issuer string, and the system finds both certificates.
I’m trying to connect a windows 7 client to a Redhat Linux 7 server.
However whenever I try to start a VPN connection it ALWAYS fails with a 13806 error message to wit:
Error 13806 IKE failed to find a valid machine certificate. Contact your Network Security Administrator about installing a valid
certificate in the appropriate Certificate Store.
However when I use mmc to find the CA and the client certificate, mmc ALWAYS finds them. It’s the same behavior on all 3 systems.
each system has it’s own unique client cert, and they all used the same self-signed CA.
Looking at the message it says «failed to find a valid machine certificate» Does this mean the certificate it found is invalid?
If it is WHY doesn’t the «error msg handler logic» dump the certificate and display what makes the certificate invalid???
In the second part of the message;
Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.
Why doesn’t the «error message handler» specify exactly which certificate store is the appropriate store??
Is there some way of defining a certificate store to the IKEv2 VPN connection definition? (as it’s done in Unix & Linux, and z/OS)
Any ideas and/or suggestions are appreciated.
Best regards
Guy