Windows Certificate Requirements
The IKEv2 Agile VPN client for Windows 7 and later introduced some requirements on VPN gateway certificates.
A VPN gateway certificate must have:
An Extended Key Usage (EKU) flag explicitly allowing the certificate to be used for authentication purposes. The
serverAuthEKU having the ASN.1 OID
184.108.40.206.220.127.116.11.1(often called TLS Web server authentication) will do that. If you are using OpenSSL to generate your certificates then include the option
extendedKeyUsage = serverAuth
pki --issuecommand, add the argument
In addition to
serverAuththe IP Security IKE Intermediate EKU with ASN.1 OID
18.104.22.168.22.214.171.124.2does not hurt either and will allow you to use the certificate with older macOS releases, too.
Thus with OpenSSL define
extendedKeyUsage = serverAuth, 126.96.36.199.188.8.131.52.2
and with the
--flag serverAuth --flag ikeIntermediate
The hostname of the VPN gateway entered in the clients connection properties MUST be contained either in the
subjectDistinguishedNameof the server certificate
C=CH, O=strongSwan Project, CN=vpn.strongswan.org
and/or in a
subjectAltNameextension that can be added with the OpenSSL option
subjectAltName = DNS:vpn.strongswan.org
For optimal interoperability with other client implementations it is recommended to include the hostname as
subjectAltNamebecause matching only parts of the distinguished name is actually not compliant with RFC 4945. Having the hostname encoded as
subjectAltNameis essential when using the strongSwan Android app or working with macOS clients.
If you intend to use IP addresses instead of host names with Windows clients, add them in a
DNS:x.x.x.x) and not one of type
IP:x.x.x.x). The client will throw a
13801error if this is not met. The same applies to some versions of iOS or macOS when using EAP-TLS which will fail with error
To do this with
pki --issue, prefix the IP address with an
--san @x.x.x.x) or since version 5.2.2 with the
--san dns:x.x.x.x). Otherwise the
pkitool will automatically interpret the field as an IP address and encode it as type
iPAddress. For interoperability with other client implementations the IP address should probably be added in two
subjectAltNameextensions, one for each type, i.e.
When using client certificates you may come across Error 13806. This happens if Windows does not find a suitable client certificate. Besides the certificate being installed in the wrong location or problems with the CA certificate, this could be due to the properties of the certificate itself. The following table lists combinations of CN (i.e. the Common Name, the rest of the DN does not matter), SAN and EKU that work:
When using user certificates Windows will not send the subject DN (Distinguished
Name) as client identity but the CN (Common Name) instead, (e.g.
user for the
first identity below). If no matching SAN (
subjectAltName) is contained
in the certificate, strongSwan will reject it because it can’t confirm the client
If any EKU is specified, make sure
none or not matching
does not matter
Even if a matching SAN is contained and strongSwan would accept it, Windows will
ignore it for user authentication due to the missing
Alternatively, you may disable these extended certificate checks on the client.
|This is potentially dangerous, as any certificate holder assured by your CA may act as the VPN gateway.|
To disable the extended checks, in the client’s registry add a
This blog entry provides detailed information about the Windows 7 certificate requirements.