Locally-signed (non publicly trusted) certificates are missing extendedKeyUsage

[sleevi]

The req_v3_conf files used to generate the CSRs for certificates, and subsequently the actual certificates for those that aren’t issued by a publicly trusted CA (e.g. untrusted-root and self-signed) lack an extendedKeyUsage extension.

Apple requires, since macOS 10.15 and iOS 13, that certificates contain this EKU, even for locally trusted certificates.

As a consequence, the error code and error handling triggered by these certificates is different on macOS/iOS than their expected purpose, because they are rejected early for violating that policy.

This is as simple as adding a extendedKeyUsage=clientAuth,serverAuth stanza to the req_v3_usr sections. There should be no harm in adding it to all of the files, as publicly trusted CAs will just ignore that part of the CSR or ensure it complies with the BRs.

This may be a useful case for adding a domain that explicitly lacks EKU, although such a certificate can not be publicly trusted. It would, however, allow exercising more code coverage on macOS/iOS.

[christhompson]

What's the expected behavior on macOS? Testing in Safari on macOS 10.15.2, it looks like self-signed.badssl.com is still working as expected (bypassable).

Adding EKU to these certs sounds good either way though, and adding a separate path for something like "no-eku-untrusted-root" seems like an easy addition.

[sleevi]

The difference mainly shows up when you use Keychain Services to inspect, or use Safari’s UI.

Briefly, I believe Chrome would have miscategorized these as invalid, but that shouldn’t be an issue anymore.

I mostly raised it as something similar to an expired, untrusted cert. It has two errors, making it hard to see the desired error :)

[christhompson]

Thanks! I'll add this to my list of updates to make.