Recente antwoorden op Private CA certs cause SEC_ERROR_BAD_DER in FF38, works fine in FF36 (OSX)https://support.mozilla.org/nl/questions/10649912015-06-04T10:02:47-07:00I had looked previously, and nothing appeared to be a direct match. I may create an account there an2015-06-04T10:02:47-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-737091<p>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.
</p>You can check if your issue is covered by an existing bug report.
https://bugzilla.mozilla.org/bugl2015-06-04T09:59:57-07:00cor-elhttps://support.mozilla.org/nl/questions/1064991#answer-737090<p>You can check if your issue is covered by an existing bug report.
</p>
<ul><li><a href="https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&amp;order=bugs.bug_id%20desc&amp;chfieldto=Now&amp;chfieldfrom=2014-01-01&amp;content=SEC_ERROR_BAD_DER" rel="nofollow">https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&amp;order=bugs.bug_id%20desc&amp;chfieldto=Now&amp;chfieldfrom=2014-01-01&amp;content=SEC_ERROR_BAD_DER</a>
</li></ul>That would be helpful in theory, except that apparently several errors map to SEC_ERROR_BAD_DER whic2015-06-04T09:55:54-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-737087<p>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).
</p>See also:
https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Error_Codes_i2015-06-04T09:32:41-07:00cor-elhttps://support.mozilla.org/nl/questions/1064991#answer-737065<p>See also:
</p>
<ul><li><a href="https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Error_Codes_in_Firefox" rel="nofollow">https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Error_Codes_in_Firefox</a>
</li></ul>This is the list of cyphers afaik (about 2/3rd down):
https://wiki.mozilla.org/Security/Server_Sid2015-06-03T11:02:22-07:00rmcguiganhttps://support.mozilla.org/nl/questions/1064991#answer-736676<p>This is the list of cyphers afaik (about 2/3rd down):
</p>
<ul><li><a href="https://wiki.mozilla.org/Security/Server_Side_TLS" rel="nofollow">https://wiki.mozilla.org/Security/Server_Side_TLS</a>
</li></ul>Well, neither wildcard issue are at play (we don't use any wildcards).
Off hand I don't know if the 2015-06-03T10:28:29-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-736654<p>Well, neither wildcard issue are at play (we don't use any wildcards).
</p><p>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.
</p><p>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.
</p>I did ask if there were other causes for this error, also thank you for the example, I still need to2015-06-03T10:01:35-07:00rmcguiganhttps://support.mozilla.org/nl/questions/1064991#answer-736642<p>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:
</p>
<ul><li> it can be cause by a lack of a NULL parameter following the rsaEncryption OID in the subject key info
</li><li> 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)
</li><li> or another example that causes this issue: like *.*.example.com in the SAN
</li><li> or *<a href="http://foo.example.com" rel="nofollow">foo.example.com</a> or foo*.example.com
</li></ul>
<p><source>
</p>Are you saying this is the result of one of those bugs? To be clear, the IP in dNSName thing isn't a2015-06-03T09:31:27-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-736635<p>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.
</p>I doublechecked, currently there is not a work around, but stay posted with that bug.
2015-06-03T09:26:04-07:00rmcguiganhttps://support.mozilla.org/nl/questions/1064991#answer-736629<p>I doublechecked, currently there is not a work around, but stay posted with that bug.
</p>Created new "example.com" root CA and certificate for "example.com" so I can give example certificat2015-06-03T07:58:55-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-736594<p>Created new "<a href="http://example.com" rel="nofollow">example.com</a>" root CA and certificate for "<a href="http://example.com" rel="nofollow">example.com</a>" so I can give example certificate that isn't working (but works everywhere else) without leaking internal website names etc.
</p><p><a href="https://gist.github.com/jonathanvaughn/bc0a02a0040c78f38f42" rel="nofollow">gist of certificate and root CA certificate</a>
</p>Algorithms should be supported - Certificates use regular RSA keys with SHA256 hashes, and ordinary 2015-06-03T07:37:50-07:00jvaughnhttps://support.mozilla.org/nl/questions/1064991#answer-736583<p>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.
</p><p>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.
</p><p>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.
</p>I did some more research on this because my first thought was the RSA changes that were made after t2015-06-03T06:49:33-07:00rmcguiganhttps://support.mozilla.org/nl/questions/1064991#answer-736561<p>I did some more research on this because my first thought was the RSA changes that were made after the SSL cleanup.
</p><p>Are the algorithims supported?
</p>
<ul><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1088140" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1088140</a>
</li></ul>
<p>Another regression domain mismatch- <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1148766" rel="nofollow">this comment, are you using ip addresses in your certs instead of dNSName</a>
</p>
<ul><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1148766" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1148766</a>
</li></ul>
<p>That bug is waiting for a patch to treat is as a mismatch instead see<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1170303" rel="nofollow">Bug 1170303</a>
</p><p>You can use this tool, if you have not already to check any places of error:
</p><pre><a href="https://www.ssllabs.com/ssltest/analyze.html?d=" rel="nofollow">https://www.ssllabs.com/ssltest/analyze.html?d=</a>
</pre>
<p>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.
</p><p>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.
</p>