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.

Required fields

Your gateway certificate must have:

  1. An Extended Key Usage flag explicitly allowing the certificate to be used for authentication purposes. The serverAuth EKU having the OID (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

    --flag serverAuth

    In addition to serverAuth the "IP Security IKE Intermediate" EKU with OID 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,
    --flag serverAuth --flag ikeIntermediate
  2. 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,

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

    subjectAltName =

    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 @ symbol (e.g. --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.

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

Further information

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.