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
- basicConstraints present, EKU absent
- basicConstraints absent, EKU present
- basicConstraints present, EKU present
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.