Bug 1212132

Paul, in Description you said 
"This NSS feature will be required before we can release libreswan-3.13" 
Just checked and we currently have
on fedora:   libreswan-3.16-1.fc23.x86_64 and 
on rhel-7.2: libreswan-3.15-5.el7_1.x86_64
Do we still this this bug?

We have worked around this problem but problem still exists and work-around is not totally fool proof. Our work-around was to verify certificate as TLS client cert first and if this fails, as TLS server cert so normally certificates work.

But because IPsec vpn certificates are not required to have EKU at all it's very likely we will hit problems with our work-around sooner or later.

The version using NSS code for certificate verification is 3.14 and later.

It seems like you're asking for something rather simple, which is, to add some more known constants for key usages, is that correct?

Could you please be more precise in which ones exactly you need, etc?

We need to implement this upstream. If you give us more details, we can try to add it upstream. If you need it urgently, we can try to backport it to RHEL when done.

But we need some more exact details first, what exactly is missing. Are you able to provide the details?

Most VPN certificates don't specify any EKU's. We'd be happy if we can tell NSS to skip checking any EKU's. But let's get Matt Rogers input on this as well,

Requirements for certificates for ike use are explained in

https://tools.ietf.org/html/rfc4809#section-3

Generally, "Digital Signature" KU is required, EKU must not be checked at all. But I find it easier to point to document instead of writing all that info here.

It would suffice to have a SECCertificateUsage type to pass to CERT_PKIXVerifyCert() and other verify functions, eg. 'certificateUsageIPsec' that follows this logic for the KU validation:

https://tools.ietf.org/html/rfc4945#section-5.1.3.2

5.1.3.2.  KeyUsage

   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),
      reject cert.

   o  If none of the above, continue.

Along with this, the EKU should be ignored.

This is also a big problem on Fedora 23 (libreswan-3.16-1.fc23.x86_64, nss-3.21.0-1.1.fc23.x86_64).
I have been trying to use certificates for roadrunner users in libreswan for more than 3 days now, without success.
The debug output shows me the certificates are always rejected (both by client and server profiles), whatever combination of KU/EKU flags I've tried.
Even certificates without KU/EKU are rejected.
It's a pity I cannot replace the (buggy and outdated) racoon daemon by libreswan because of this problem.
Many thanks in advance for a serious fix.

This bug is not a libreswan support request. https://lists.libreswan.org/ is correct contact.

(In reply to Kai Engert (:kaie) from comment #6)
> It seems like you're asking for something rather simple, which is, to add
> some more known constants for key usages, is that correct?
> 
> Could you please be more precise in which ones exactly you need, etc?
> 
> We need to implement this upstream. If you give us more details, we can try
> to add it upstream. If you need it urgently, we can try to backport it to
> RHEL when done.
> 
> But we need some more exact details first, what exactly is missing. Are you
> able to provide the details?

What would be the time to get such an interface which doesn't chack EKU at all and only verify required key usages (digitalSignature and/or nonRepudiation).

We'd really need this asap. Note, we use CERT_PKIXVerifyCert() now, If we need to switch to another interface, please give us information which interface we should use.

It would be nice/helpful if you could attach (at least one) sample certificate.

If your scenario involves a chain of certs, please attach a full chain (any format), or multiple example chains.

Thanks to Paul and Tuomo for today's IRC discussion, which clarified my questions.

I've reported the request to the upstream project at
  https://bugzilla.mozilla.org/show_bug.cgi?id=1252891

nss-util-3.36.0-2.el7

nss-util-3.36.0-2.el7,nss-3.36.0-8.el7

This patch shouldn't be in modified or ON_QA yet. It wasn't part of the rebase daiki did.

Fixed in nss-3.43.0-2.el7

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2237