Private CA certs cause SEC_ERROR_BAD_DER in FF38, works fine in FF36 (OSX)
FF36 works fine, FF38 fails (at least on OSX - other OSes not yet tested, we've frozen FF updates until this is resolved). Chrome and Safari work.
We have an internal CA to generate certificates, when we started updating to FF38 found that we get SEC_ERROR_BAD_DER when trying to connect to servers using these certificates. At first thought it was perhaps because we had not yet upgraded to SHA256 certificates, but I upgraded one and tested and still get the error.
From Wireshark I can see the following: 1: TLS handshake starts, the server responds 2: client asks for a change cipher spec 3: server responds with encrypted handshake message 4: browser shows SEC_ERROR_BAD_DER
This is occurring on both Apache 2.2.x and Tomcat web servers, across multiple physical servers (CentOS 6.x).
Every web based tool I can find says there is zero problems with our certificates, and all other browsers agree.
I have tried playing with the settings in about:config based on some googling (insecure_fallback_hosts, version.fallback-limit, version.min) and none made any difference.
Ausgewählte Lösung
I had looked previously, and nothing appeared to be a direct match. I may create an account there and post the issue directly as a bug report, though.
Diese Antwort im Kontext lesen 👍 0Alle Antworten (12)
I did some more research on this because my first thought was the RSA changes that were made after the SSL cleanup.
Are the algorithims supported?
Another regression domain mismatch- this comment, are you using ip addresses in your certs instead of dNSName
That bug is waiting for a patch to treat is as a mismatch instead seeBug 1170303
You can use this tool, if you have not already to check any places of error:
https://www.ssllabs.com/ssltest/analyze.html?d=
They are still working on a patch if is is the mismatch error, however there is not an indication if this also affects the ESR branch yet. Until there is an eta/patch on this I do not know when it will be fixed.
Asking the certificate@mozilla.com or the security mailing list with reference to the direct bug might be able to give you better insight on how to proceed.
Algorithms should be supported - Certificates use regular RSA keys with SHA256 hashes, and ordinary cipher options for Apache (SSL2/3/Poodle/etc risks are turned off). Tomcat is running purely default config for ciphers.
The particular certificate I'm trying to troubleshoot at the moment does not have any IPs at all, just regular domain names. We do have some certificates with IP in both dNSName and ipv4 entries because it's required to support IE (and maybe Chrome on Windows, I forget - but it's an issue with Windows' SSL only supporting IPs in dNSName and not ipv4/ipv6 entries), but this is not one of those certificates.
I've used the SSL Labs SSL Test before. Currently, getting a rating of "T" (would be A) because the root is our self-signed root certificate.
Created new "example.com" root CA and certificate for "example.com" so I can give example certificate that isn't working (but works everywhere else) without leaking internal website names etc.
I doublechecked, currently there is not a work around, but stay posted with that bug.
Are you saying this is the result of one of those bugs? To be clear, the IP in dNSName thing isn't an issue on this particular certificate (there's no IPs in the certificate in any form), I was just commenting that we do have some other certificates where that would be an issue.
I did ask if there were other causes for this error, also thank you for the example, I still need to learn how to do this via command line. I will still provide the information here:
- it can be cause by a lack of a NULL parameter following the rsaEncryption OID in the subject key info
- it can also be caused by improperly encoding the INTEGER representing the RSA modulus (if the highest bit is set, there should be a leading zero byte)
- or another example that causes this issue: like *.*.example.com in the SAN
- or *foo.example.com or foo*.example.com
Well, neither wildcard issue are at play (we don't use any wildcards).
Off hand I don't know if the lack of NULL or improperly encoded INTEGER are an issue, we use a 3rd party library to do all the ASN1 encoding and x509 generation (just scripting together a front end to it) so I'd like to hope they're right but I don't know that. I haven't been able to find any kind of strict validator that can tell me for sure if those are issues.
I tried googling for some kind of command line mozpkix tool that I could use to get more detailed error information but didn't find anything.
This is the list of cyphers afaik (about 2/3rd down):
That would be helpful in theory, except that apparently several errors map to SEC_ERROR_BAD_DER which are not specifically bad ASN or even invalid x.509, but somehow Firefox doesn't like (instead of giving an error specific to why it doesn't meat mozpkix's standards, which would help resolve the problem).
You can check if your issue is covered by an existing bug report.
Ausgewählte Lösung
I had looked previously, and nothing appeared to be a direct match. I may create an account there and post the issue directly as a bug report, though.