Windows Certificate Requirements

The IKEv2 Agile VPN client for Windows 7 and later introduced some requirements on VPN gateway certificates.

Required Fields

A VPN gateway certificate must have:

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

    Using the pki --issue command, add the argument

    --flag serverAuth

    In addition to serverAuth the IP Security IKE Intermediate EKU with ASN.1 OID does not hurt either and will allow you to use the certificate with older macOS releases, too.

    Thus with OpenSSL define

    extendedKeyUsage = serverAuth,

    and with the pki --issue command

    --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 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 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 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 or macOS when using EAP-TLS which will fail with error 1001 -9807.

    To do this with pki --issue, prefix the IP address with an @ symbol (e.g. --san @x.x.x.x) or since version 5.2.2 with the dns: prefix (e.g. --san dns:x.x.x.x). Otherwise the pki tool 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 subjectAltName extensions, one for each type, i.e. dNSName and iPAddress.

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 (i.e. the Common Name, the rest of the DN does not matter), SAN and EKU that work:

User and Machine Certificates

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

CN SAN EKU Comments


matching SAN


CN="" CN=""

matching SAN


If any EKU is specified, make sure clientAuth is contained

Machine Certificates Only

CN SAN EKU Comments


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 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, in the client’s registry add a DWORD called DisableIKENameEkuCheck to


Further Information

This blog entry provides detailed information about the Windows 7 certificate requirements.