Requirements for certificates used with Windows 7¶
The Windows 7 Beta release was liberal in accepting certificates, but already the Release Candidate added several new requirements for the VPN gateway certificate.
Your gateway certificate must have:
- An Extended Key Usage flag explicitly allowing the certificate to be used for authentication purposes. The serverAuth EKU having the OID 22.214.171.124.126.96.36.199.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
For the ipsec pki tool add the following argument
In addition to serverAuth the "IP Security IKE Intermediate" EKU with OID 188.8.131.52.184.108.40.206.2 does not hurt either and will allow you to use the certificate with older Mac OS X releases too.
So, this will work too:
extendedKeyUsage = serverAuth, 220.127.116.11.18.104.22.168.2
--flag serverAuth --flag ikeIntermediate
- The hostname of the VPN gateway entered in the clients connection properties MUST be contained either in the subjectDistinguishedName of the server certificate
C=CH, O=strongSwan Project, CN=vpn.strongswan.org
and/or in a subjectAltName extension that can be added with the OpenSSL option
subjectAltName = DNS:vpn.strongswan.org
or the ipsec pki --issue argument
For optimal interoperability with other client implementations it is recommended to include the hostname as subjectAltName, because matching only parts of the distinguished name is actually not compliant with RFC 4945. Having the hostname encoded as subjectAltName is essential when using our Android app or working with Mac OS X clients.
If you intend to use IP addresses instead of host names with Windows clients, add them in a subjectAltName of type dNSName (i.e.
DNS:x.x.x.x) and not one of type iPAddress (i.e.
IP:x.x.x.x). The client will throw a 13801 error if this is not met. The same applies to some versions of Apple's iOS/Mac OS X when using EAP-TLS, which will fail with error 1001 -9807.
To do this with ipsec pki --issue, prefix the IP address with an
--san @x.x.x.x) or, since 5.2.2, with the dns: prefix (e.g.
--san dns:x.x.x.x). Otherwise, the tool automatically detects the IP address and encodes it with type iPAddress.
For interoperability with other client implementations the IP address should probably be added in two subjectAltName extensions one for each type.
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 (the rest of the DN does not matter), SAN and EKU that work:
|Usable as user and machine certificates|
|When using user certificates Windows will not send the subject DN as client identity, but the CN instead (e.g. "user" for the first one). If no matching SAN is contained in the certificate strongSwan will reject it because it can't confirm the client identity.|
|matching SAN||clientAuth...||If any EKU are specified, make sure clientAuth is contained|
|Only usable as machine certificates|
|none or not matching||none|
|does not matter||serverAuth||Even if a matching SAN is contained and strongSwan would accept it, Windows will ignore it for user authentication due to the missing clientAuth EKU|
Disabling extended certificate checks¶
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, add a DWORD called DisableIKENameEkuCheck to
in the client's registry.
For more details about the requirements and other ways to disable the certificate checks, have a look to this knowledge base article.
This blog entry also provides detailed information about the Windows 7 certificate requirements.