(moved from bug 7394) We upgraded our iPad from iOS 12 to iOS 13 and now we can no longer connect to machines using self signed certificates, even when following our instruction where the cn is correct and the certificate has been added with full trust. The normal connections work fine, and it's only the WebSocket connection that fails. In the browser console we see the error "OSStatus -9807" which means errSSLXCertChainInvalid. Apple's documentation does not go in to details what that might mean. iOS 13 has some new requirements on certificates though which might be an issue: https://support.apple.com/en-us/HT210176 We're currently failing these points: * We don't set Subject Alternate Name properly * Extended Key Usage isn't set * Our validity time is too long (3 years)
After some testing it turns out that Subject Alternate Name is the critical missing piece. Adding that makes things work. So we should have a look at updating our make-dummy-cert script. We should probably try to comply with the other things as well while we're at it.
Seems to work fine now. Tester should make sure the script works with both old and new versions of OpenSSL.
Generating the cert works well on Fedora 30. Using the dummy cert works great on macOS 10.14: * Chrome 77 ✓ * Firefox 69 ✓ * Safari 14 ✓ and on iOS 13: * Safari 13 ✓ and on Android 9: * Firefox 69 ✓ * Chrome 77 ✓ and on Windows 10: * IE 11 ✓ * Edge 14 ✓ (aside from bug 5997) * Firefox 69 ✓ * Chrome 77 ✓ but using the dummy cert does NOT work in Chrome on Fedora 30: * Chrome 77 ✗ * Firefox 69 ✓
So Chrome apparently uses the TLS library from the system, which on Linux means NSS (same as Firefox). However it seems like Firefox does its own certificate verification, whilst Chrome uses the default handler in NSS. The problem is in how NSS handles Extended Key Usage. It maps the OIDs of that extension in to an internal bit mask (based on a deprecated older extension). However this bit mask has a special bit for CA certificates, and no such equivalent exists in Extended Key Usage. They way it resolves this is by looking at the Basic Constraints extension and mapping to different bits depending on if it's marked as a CA or not. There is no way you can get both the server and CA bit set at the same time. So it will either consider the subject certificate to have incorrect key usage, or the issuer (same cert, two different checks).[1] Oddly enough though, omitting the Extended Key Usage means that it is always approved for server usage. That's how we used to have it. But that fails one of the listed requirements from Apple. Chrome is less upset about the usage bits being wrong for the issuer. It treats it the same as an unknown issuer. Need to check how other browsers behave. [1] See cert_ComputeCertType() in certdb.c
Also note that I managed to get Firefox on Fedora really upset about the certificate as well, citing SEC_ERROR_INADEQUATE_KEY_USAGE, and completely refusing to continue. That error code is set when the legacy Key Usage bits (not the Extended) are bad. I was not able to figure out why though and the problem magically disappeared after a while. I did clear out all certificate exceptions before that, but it had no immediate effect. Perhaps it needed some time to take hold.
Note that the error code given currently by NSS is SEC_ERROR_INADEQUATE_CERT_TYPE, which Chrome translates to ERR_CERT_INVALID.
(In reply to comment #9) > > Chrome is less upset about the usage bits being wrong for the issuer. It treats > it the same as an unknown issuer. Need to check how other browsers behave. > Dropping the Basic Constraints to make Chrome happen breaks the iOS use case as iOS no longer considers it a CA and you can no longer enable trust for things using it. So I guess we'll have to drop the Extended Key Usage and hope Apple doesn't make them a hard requirement.
Reported upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1590085 https://bugs.chromium.org/p/chromium/issues/detail?id=1016288
Upstream has stated they don't think this is worth fixing. Chrome will most likely be using a different validator before a change to NSS can be widely deployed. They did provide us with a better workaround though, in the form of Netscape's legacy certificate type. Seems to work fine now. Tested with Chrome and Firefox on Linux, Safari on iOS and macOS, and IE and Edge on Windows.
(In reply to comment #15) > > Seems to work fine now. Tested with Chrome and Firefox on Linux, Safari on iOS > and macOS, and IE and Edge on Windows. > Retested it on these and it works fine.
