[strongSwan] EU and EKU
Modster, Anthony
Anthony.Modster at Teledyne.com
Tue Jun 11 18:35:56 CEST 2019
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 <tobias at strongswan.org>
Sent: Wednesday, June 05, 2019 1:10 AM
To: Modster, Anthony <Anthony.Modster at Teledyne.com>; users at 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
More information about the Users
mailing list