Hello Tobias
? is this true, that the StrongSwan does not check the peer certificate KU and
EKU during the initial IPsec VPN connection (i.e., the "IPSec client" only
checks the Subject Distinguish Name (SDN) of the peer certificate).
We want to see if the "IPSec client" can be altered to check KU and EKU fields
of the peer certificate (in addition to SDN).
NOTE: Current "IPSec gateway" certificate key usage is "digitalSignature and
key encipherment" and EKU is "id-kp-clientAuth {1.3.6.1.5.5.7.3.2};
id-kp-serverAuth {1.3.6.1.5.5.7.3.1}; iKEIntermediate {1.3.6.1.5.5.8.2.2};
id-kp-ipsecIKE {1.3.6.1.5.5.7.3.17}". And we want to make sure that during the
VPN connection initiation, the "IPSec gateway" certificate has the right KU and
EKU set in the certificate field.
Thanks
-----Original Message-----
From: Tobias Brunner <tob...@strongswan.org>
Sent: Wednesday, June 05, 2019 1:10 AM
To: Modster, Anthony <anthony.mods...@teledyne.com>; users@lists.strongswan.org
Subject: Re: [strongSwan] EU and EKU
---External Email---
Hi Anthony,
> ? does the latest version of strongswan provide better “checking of
> the peer certificate EU and EKU”
I guess you mean KU not EU. But what exactly do you mean with "better"?
The cRLSign KU bit is used in revocation checking (if a CRL is not signed by
the CA). And since 5.6.3, in compliance with RFC 4945, section 5.1.3.2,
certificates either must not contain a KU extension (like the ones generated by
pki), or have at least one of the digitalSignature or nonRepudiation bits set.
The only EKU that's used is OCSPSigning for revocation checking (analogous to
the cRLSign KU).
Regards,
Tobias
