X
Thinta lapha ukuze uye kuveshini yamakhalekhukhwini kusayithi.

Isithangami Sabeseki

Lolu chungechunge lwabekwa kunqolobane. Uyacelwa ubuze umbuzo omusha uma udinga usizo.

Private CA certs cause SEC_ERROR_BAD_DER in FF38, works fine in FF36 (OSX)

Kuphostiwe

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.

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.

Isisombululo esikhethiwe

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.

Funda le mpendulo ngokuhambisana nalesi sihloko 0

Eminye Imininingwane Yohlelo

Fakela amapulagi

  • Adobe PDF Plug-In For Firefox and Netscape 11.0.9
  • Google Update
  • NPRuntime Script Plug-in Library for Java(TM) Deploy
  • Next Generation Java Plug-in 11.31.2 for Mozilla browsers
  • The plug-in allows you to open and edit files using Microsoft Office applications
  • Office Authorization plug-in for NPAPI browsers
  • The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.
  • Shockwave Flash 17.0 r0
  • Shockwave Flash 16.0 r0
  • 5.1.30514.0

Isisebenziso

  • I-ejenti Engumsebenzisi: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0

Eminye Imininingwane

guigs 1072 izisombululo 11697 izimpendulo
Kuphostiwe

Impendulo Ewusizo

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.

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? *[https://bugzilla.mozilla.org/show_bug.cgi?id=1088140] Another regression domain mismatch- [https://bugzilla.mozilla.org/show_bug.cgi?id=1148766 this comment, are you using ip addresses in your certs instead of dNSName] *[https://bugzilla.mozilla.org/show_bug.cgi?id=1148766] That bug is waiting for a patch to treat is as a mismatch instead see[https://bugzilla.mozilla.org/show_bug.cgi?id=1170303 Bug 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.

Umnikazi wombuzo

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.

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.

Umnikazi wombuzo

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.

gist of certificate and root CA 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. [https://gist.github.com/jonathanvaughn/bc0a02a0040c78f38f42 gist of certificate and root CA certificate]
guigs 1072 izisombululo 11697 izimpendulo
Kuphostiwe

I doublechecked, currently there is not a work around, but stay posted with that bug.

I doublechecked, currently there is not a work around, but stay posted with that bug.

Umnikazi wombuzo

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.

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.
guigs 1072 izisombululo 11697 izimpendulo
Kuphostiwe

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

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 <source #security keeler>

Umnikazi wombuzo

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.

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.
guigs 1072 izisombululo 11697 izimpendulo
Kuphostiwe

This is the list of cyphers afaik (about 2/3rd down):

This is the list of cyphers afaik (about 2/3rd down): *[https://wiki.mozilla.org/Security/Server_Side_TLS]
cor-el
  • Top 10 Contributor
  • Moderator
17467 izisombululo 157838 izimpendulo
Kuphostiwe
See also: *https://developer.mozilla.org/en-US/docs/Mozilla/Security/x509_Certificates#Error_Codes_in_Firefox

Impendulo Ewusizo

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).

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).
cor-el
  • Top 10 Contributor
  • Moderator
17467 izisombululo 157838 izimpendulo
Kuphostiwe
You can check if your issue is covered by an existing bug report. *https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=bugs.bug_id%20desc&chfieldto=Now&chfieldfrom=2014-01-01&content=SEC_ERROR_BAD_DER

Isisombululo Esikhethiwe

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.

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.