strongSwan

h1. 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.

h2. Required fields

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 _1.3.6.1.5.5.7.3.1_ (often called _TLS Web server authentication_) will do that. If you are using OpenSSL to generate your certificates then include the option

  <pre>

extendedKeyUsage = serverAuth

</pre>

  For the [[IpsecPkiIssue|ipsec pki]] tool add the following argument

  <pre>

--flag serverAuth

</pre>

  In addition to _serverAuth_ the "IP Security IKE Intermediate" EKU with OID _1.3.6.1.5.5.8.2.2_ does not hurt either and will allow you to use the certificate with older [[IOS_(Apple)|Mac OS X releases]] too.

  So, this will work too:

  <pre>

extendedKeyUsage = serverAuth, 1.3.6.1.5.5.8.2.2

</pre><pre>

--flag serverAuth --flag ikeIntermediate

</pre>

# The hostname of the VPN gateway entered in the clients connection properties *MUST* be contained either in the *subjectDistinguishedName* of the server certificate

  <pre>

C=CH, O=strongSwan Project, CN=vpn.strongswan.org

</pre>

  and/or in a *subjectAltName* extension that can be added with the OpenSSL option

  <pre>

subjectAltName = DNS:vpn.strongswan.org

</pre>

  or the [[IpsecPkiIssue|ipsec pki --issue]] argument

  <pre>

--san vpn.strongswan.org

</pre>

  *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":http://tools.ietf.org/html/rfc4945. Having the hostname encoded as *subjectAltName* is essential when using [[AndroidVpnClient|our Android app]] or working with [[IOS_(Apple)|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 [[IOS_(Apple)|Apple's iOS/Mac OS X]] when using EAP-TLS, which will fail with error _1001 -9807_.

  To do this with [[IpsecPkiIssue|ipsec pki --issue]], prefix the IP address with an <code>@</code> symbol (e.g. <code>--san @x.x.x.x</code>) or, since version:5.2.2, with the _dns:_ prefix (e.g. @--san dns:x.x.x.x@). Otherwise, the tool [[IdentityParsing|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.

h2. Client certificates

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:

|_<. CN                     |_<. SAN                       |_<. EKU          |_<. Comments|

|\4(level2). Usable as user and machine certificates|

|\4(level3). 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.|

|CN="user"

CN="user@example.com"

CN="host.example.com"       |matching SAN                  |none             ||

|CN="user"

CN="user@example.com"

CN="host.example.com"       |matching SAN                  | _clientAuth_... |If any EKU are specified, make sure _clientAuth_ is contained|

|\4(level2). Only usable as machine certificates|

|CN="user"

CN="host@example.com"

CN="host.example.com"       |none or not matching          |none             ||

|CN="user"

CN="host@example.com"

CN="host.example.com"       |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|

h2. 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

<pre>

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters\

</pre>

in the client's registry.

h2. Further information

For more details about the requirements and other ways to disable the certificate checks, have a look to "this knowledge base article":http://support.microsoft.com/kb/926182.

"This blog entry":http://www.carbonwind.net/blog/post/VPN-Reconnect-in-Windows-7-RC-redux.aspx also provides detailed information about the Windows 7 certificate requirements.