I created a self-signed root CA for my internal use, an intermediate CA, and a TLS server certificate, using OpenSSL 3.0.16. When I configure my (internal) Apache httpd with that chain, Chromium complains about the commonName not matching the subjectAltName; but FF 128 gives this opaque SEC_ERROR_BAD_DER error code and no clue as to what in the DER it failed to parse.
Is there an easier way to debug this? Because all I suspect at this point is that some of the nameConstraints that I use, NSS doesn’t like. Because nameConstraints seem to be poorly supported generally.
I just verified that, by removing all the nameConstraints from the CAs in the chain, I can get FF to accept the certs. Works with Chromium, too. I suspect that I can add back the DNS constraints but that it balked at the email and IP ones.
By trial-and-error, I’ve learned that a dNSName is not parseable by NSS in the nameConstraints but an rfc822Name or iPAddress is.
I’m guessing that they didn’t want to parse it because they’d have to also write the logic for enforcing it.
It seems like this would limit the internal use of FF in companies that issue their own CAs for internal use, since nameConstraints only make sense if they’re critical, and dNSName would be a desirable constraint.
Your code reference doesn’t mean anything to me. I’m not familiar with your generateWebTransportCertificates function. Its invocation seems irrelevant to my issue, since you’re only passing in the DN data, no name constraints.