1590085 - self signed certificates with extended key usage (EKU) give SEC_ERROR_INADEQUATE_CERT_TYPE

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Pierre Ossman]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Generate a self signed certificate with:

• Basic Constraints: CA=True
• Key Usage: keyCertSign,digitalSignature,keyEncipherment
• Extended Key Usage: serverAuth

Connect using a NSS client, e.g. tstclnt or Chrome/Chromium.

Actual results:

SEC_ERROR_INADEQUATE_CERT_TYPE

Expected results:

SEC_ERROR_UNKNOWN_ISSUER

Comment 1

[Pierre Ossman]

This has become an important issue as Apple has set new requirements for certificates:

https://support.apple.com/en-us/HT210176

Right now they've started enforcing Subject Alternate Name, but not Extended Key Usage. Given that they are both on this list we are concerned they will start enforcing Extended Key Usage as well.

This would result in us being unable to generate self signed certificates for testing and development that work in both Chrome and Safari.

Comment 2

[Pierre Ossman]

So the underlying problem here is in cert_ComputeCertType which sets either NS_CERT_TYPE_SSL_CA or NS_CERT_TYPE_SSL_SERVER, but not both if Extended Key Usage is set.

However is Extended Key Usage is omitted in the certificate then it sets both.

Comment 3

[Pierre Ossman]

Also reported for Chrome as I'm unsure who needs to change here:

https://bugs.chromium.org/p/chromium/issues/detail?id=1016288

Comment 4

[Ryan Sleevi]

JC: I closed the Chrome issue as WontFix, and I'm inclined to view this one as WontFix as well.

The reporter's done the leg-work, but just to recap the scenarios:

• basicConstraints absent, EKU absent
  • NS_CERT_TYPE_SSL_CLIENT | NS_CERT_TYPE_SSL_SERVER | NS_CERT_TYPE_EMAIL
• basicConstraints present, EKU absent
  • NS_CERT_TYPE_SSL_CA | NS_CERT_TYPE_EMAIL_CA | EXT_KEY_USAGE_STATUS_RESPONDER | NS_CERT_TYPE_SSL_CLIENT | NS_CERT_TYPE_SSL_SERVER | NS_CERT_TYPE_EMAIL
• basicConstraints absent, EKU present
  • NS_CERT_TYPE_SSL_SERVER
• basicConstraints present, EKU present
  • NS_CERT_TYPE_SSL_CA

Apple has begun enforcing that certificates with a notBefore > 2019-07-01 have an EKU containing id-kp-serverAuth

The current behaviour is long-standing NSS behaviour. The change in Apple behaviour is to push Enterprises into ensuring their hierarchies are administered in a manner consistent with industry best practice, which includes discouraging self-signed certificates (implicitly), due to how the policy overrides work.

This is only an issue for the legacy and libpkix validators; those using mozilla::pkix are not affected, as mozilla::pkix does not use that function

The workaround for this is to use a hierarchy of self-signed root / issued leaf. This aligns with what, functionally, Apple is trying to encourage folks towards, and so if folks want certificates to interoperate with Apple and non-Apple products, they have to take the more restrictive approach.

The reason I advocate for WontFix is this largely won't help Chromium consumers, based on system-NSS update rates, and this would not be categorized as a security error. We'd likely be fully moved to our own validator by the time that change was in place. The current behaviour is not unreasonable, and has aligned with NSS's historic usage for many years. Changing it to set both CA and SERVER for self-signed certs doesn't seem terribly useful, especially with workarounds.

Comment 5

[Ryan Sleevi]

Oh, and to have a fuller collection of workarounds:

• Date the certificate prior to 2019-07-01; this will work, as long as total validity < 825 days
• Switch to a two-certificate hierarchy; a self-signed root and a locally-issued certificate. This is the most future-proof way, given Apple's movement in this space
• Include the Netscape Cert Type extension 2.16.840.1.113730.1.1, which will override the EKU

Comment 6

[Pierre Ossman]

We tried the Netscape Cert Type here and it should cover our use case for now. Having a two-certificate solution might be something we do in the future.

So we're content with the current state of things for now.

Thanks.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jcj, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[J.C. Jones [:jcj] (he/they)]

I've been noodling on this for some time now, and agree with Ryan's analysis. In general, a two-certificate hierarchy is the long-term approach, and the current behavior is very long-standing. I'm going to resolve this WONTFIX.