I have just established an IPSEC site-to-site VPN that required some ExtendedKeyUsage and I did some research on it.
The ExtendedKeyUsage for Internet Key Exchange were deprecated by RFC4945
The CA SHOULD NOT include the ExtendedKeyUsage (EKU) extension in certificates for use with IKE. Note that there were three IPsec-
related object identifiers in EKU that were assigned in 1999. The
semantics of these values were never clearly defined. The use of
these three EKU values in IKE/IPsec is obsolete and explicitly
deprecated by this specification. CAs SHOULD NOT issue certificates
for use in IKE with them. (For historical reference only, those
values were id-kp-ipsecEndSystem, id-kp-ipsecTunnel, and id-kp-
If this certificate will be used only for IKE/IPSEC, the recommendation is to set the KeyUsage to digitalSignature, nonRepudiation or both.
IKE uses an end-entity certificate in the authentication process.
The end-entity certificate may be used for multiple applications. As
such, the CA can impose some constraints on the manner that a public
key ought to be used. The KeyUsage (KU) and ExtendedKeyUsage (EKU)
extensions apply in this situation.
Since we are talking about using the public key to validate a
signature, if the KeyUsage extension is present, then at least one of
the digitalSignature or the nonRepudiation bits in the KeyUsage
extension MUST be set (both can be set as well). It is also fine if
other KeyUsage bits are set.
A summary of the logic flow for peer cert validation follows:
o If no KU extension, continue.
o If KU present and doesn't mention digitalSignature or
nonRepudiation (both, in addition to other KUs, is also fine),
o If none of the above, continue.