X
Tap here to go to the mobile version of the site.

Support Forum

When accessing Intranet sites that use SSL Certificates issued by our internal PKI, FF for Windows give an error of "improperly formatted DER-encoded message"

Posted

When accessing Intranet sites with that have SSL Certificates issued by our internal PKI, FF for Windows gives an error messsage - An error occurred during a connection to myshaw. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

Chrome and IE work fine. This is a new PKI using the SHA-2 signature algorithm.

When accessing Intranet sites with that have SSL Certificates issued by our internal PKI, FF for Windows gives an error messsage - An error occurred during a connection to myshaw. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der) Chrome and IE work fine. This is a new PKI using the SHA-2 signature algorithm.

Chosen solution

I was able to identify the issue. Our PKI was using some signature algorithms that FF did not support.

Read this answer in context 1

Additional System Details

Installed Plug-ins

  • Google Update
  • Shockwave Flash 15.0 r0
  • Version 5.38.6.0
  • ActiveTouch General Plugin Container Version 105
  • HttpWatch Professional - HTTP Viewer for Firefox
  • The QuickTime Plugin allows you to view a wide variety of multimedia content in Web pages. For more information, visit the QuickTime Web site.
  • Adobe PDF Plug-In For Firefox and Netscape 11.0.8
  • Next Generation Java Plug-in 10.51.2 for Mozilla browsers
  • NPRuntime Script Plug-in Library for Java(TM) Deploy
  • VMware Remote Console Plug-in
  • The VMware Client Support Plug-in
  • 5.1.30214.0
  • The plugin allows you to have a better experience with Microsoft SharePoint
  • The plugin allows you to have a better experience with Microsoft Lync
  • Microsoft Lync Web App Plug-in

Application

  • User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0

More Information

guigs 1072 solutions 11697 answers

This means that is was not properly encoded https://wiki.mozilla.org/SecurityEngi.../x509Certs

I am also asking for help from the security team.

This means that is was not properly encoded [https://wiki.mozilla.org/SecurityEngineering/x509Certs] I am also asking for help from the security team.

Question owner

That is helpful, the problem I have is Google, IE and Openssl all read the and verify the certificate just fine (on windows 8.1, I've not tested on any other OS). The error message does not give anything helpful to determine what exactly FF does not like about the certificate.

That is helpful, the problem I have is Google, IE and Openssl all read the and verify the certificate just fine (on windows 8.1, I've not tested on any other OS). The error message does not give anything helpful to determine what exactly FF does not like about the certificate.

Chosen Solution

I was able to identify the issue. Our PKI was using some signature algorithms that FF did not support.

I was able to identify the issue. Our PKI was using some signature algorithms that FF did not support.
swinster70 0 solutions 7 answers

Can you tel me what security algorithms were used and what is it that FF doesn't support?

Can you tel me what security algorithms were used and what is it that FF doesn't support?
guigs 1072 solutions 11697 answers

It will depend on the NSS version listed in about:support , but the listed supported algorithms are listed here: http://www-archive.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html

It will depend on the NSS version listed in about:support , but the listed supported algorithms are listed here: http://www-archive.mozilla.org/projects/security/pki/nss/nss-3.11/nss-3.11-algorithms.html
swinster70 0 solutions 7 answers

Hi,

Here is the info from the about:support page:

Library Versions Expected minimum version Version in use NSPR 4.10.7 4.10.7 NSS 3.17.2 Basic ECC 3.17.2 Basic ECC NSSSMIME 3.17.2 Basic ECC 3.17.2 Basic ECC NSSSSL 3.17.2 Basic ECC 3.17.2 Basic ECC NSSUTIL 3.17.2 3.17.2

The CAs and Server that the certificate is issued to runs Windows 2012r2. We have removed and adjusted some of the Windows cryptography settings by adjusting the registry entries since the recent spate of SSL vulnerabilities. To make this simpler we use IIS Crypto version 1.6 build 7 with the "Best Practices" setting. The leaves the following protocol and cipher suites:

Protocols Enabled: TLS 1.0 TLS 1.1 TLS 1.2

Ciphers Enabled: Triple DES 168 AES 128/128 AES 256/256

Hashes Enabled: MD5 SHA SHA 256 SHA 384 SHA 512

Key-Exchanges Enabled: Diffie-Hellman PCKS ECDH

SSL Cipher Suite Order: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_RSA_WITH_AES_256_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA

For reference, the actual certificate assigned to the site I'm trying to browse has these details:

Version: 3 Signature Algorithm RSASSA-PSS Signature has algorithm Sha256 Public Key RSA (1024bits) Thumbprint algorithm SAH1

To note though, both IE (version 11 running Windows 7) and Chrome Version 39.0.2171.71 m work with no issues….

Regards

Chris


      • Update****

I can see that that are matches in the TLS Algorithm Reference on the page you link through to and those that are enabled on the server, such as:

TLS-RSA-with-AES-256-CBC-SHA TLS-RSA-with-AES-128-CBC-SHA

in addition, there is reference to:

TLS-ECDHE-RSA-with-AES-256-CBC-SHA TLS-ECDHE-RSA-with-AES-128-CBC-SHA

although both of these are appended with either P521, P384 or P256 in Windows.

The reference to NSS 3.11 is almost 9 years old (!!!), and as can be seen above, the version I am running is 3.17. I'm guessing thing have move on since then.

Hi, Here is the info from the about:support page: '''Library Versions''' Expected minimum version Version in use NSPR 4.10.7 4.10.7 NSS 3.17.2 Basic ECC 3.17.2 Basic ECC NSSSMIME 3.17.2 Basic ECC 3.17.2 Basic ECC NSSSSL 3.17.2 Basic ECC 3.17.2 Basic ECC NSSUTIL 3.17.2 3.17.2 The CAs and Server that the certificate is issued to runs Windows 2012r2. We have removed and adjusted some of the Windows cryptography settings by adjusting the registry entries since the recent spate of SSL vulnerabilities. To make this simpler we use IIS Crypto version 1.6 build 7 with the "Best Practices" setting. The leaves the following protocol and cipher suites: '''Protocols Enabled:''' TLS 1.0 TLS 1.1 TLS 1.2 '''Ciphers Enabled:''' Triple DES 168 AES 128/128 AES 256/256 '''Hashes Enabled:''' MD5 SHA SHA 256 SHA 384 SHA 512 '''Key-Exchanges Enabled:''' Diffie-Hellman PCKS ECDH '''SSL Cipher Suite Order:''' TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_RSA_WITH_AES_256_GCM_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA For reference, the actual certificate assigned to the site I'm trying to browse has these details: Version: 3 Signature Algorithm RSASSA-PSS Signature has algorithm Sha256 Public Key RSA (1024bits) Thumbprint algorithm SAH1 '''To note though, both IE (version 11 running Windows 7) and Chrome Version 39.0.2171.71 m work with no issues….''' Regards Chris ***Update**** I can see that that are matches in the TLS Algorithm Reference on the page you link through to and those that are enabled on the server, such as: TLS-RSA-with-AES-256-CBC-SHA TLS-RSA-with-AES-128-CBC-SHA in addition, there is reference to: TLS-ECDHE-RSA-with-AES-256-CBC-SHA TLS-ECDHE-RSA-with-AES-128-CBC-SHA although both of these are appended with either P521, P384 or P256 in Windows. The reference to NSS 3.11 is almost 9 years old (!!!), and as can be seen above, the version I am running is 3.17. I'm guessing thing have move on since then.

Modified by swinster70

guigs 1072 solutions 11697 answers

Swinster70, Gah! sorry about that I will be sure to update my sources as well!

Release notes for the version on your system:

Sha256 is default in this version. -> https://bugzilla.mozilla.org/show_bug.cgi?id=1058933

In the previous version: 316 there were errors for the signature algo: RSA-PSS via https://bugzilla.mozilla.org/show_bug.cgi?id=1005084

It may be safe to say it is not supported. This other thread with a self assigned cert by changing a key https://support.mozilla.org/en-US/que.../986085 I will keep looking for more recent data in a few. However mozilla:pkix can be disabled, but would also open security issues in other places.

Swinster70, Gah! sorry about that I will be sure to update my sources as well! Release notes for the version on your system: *[https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.17.1_release_notes/] Sha256 is default in this version. -> [https://bugzilla.mozilla.org/show_bug.cgi?id=1058933] In the previous version: 316 there were errors for the signature algo: RSA-PSS via [https://bugzilla.mozilla.org/show_bug.cgi?id=1005084] It may be safe to say it is not supported. This other thread with a self assigned cert by changing a key [https://support.mozilla.org/en-US/questions/986085] I will keep looking for more recent data in a few. However mozilla:pkix can be disabled, but would also open security issues in other places.
guigs 1072 solutions 11697 answers

Back, got the list for nightly here: https://dxr.mozilla.org/mozilla-centr.../pkixtypes.h#46

To get the current release mxr list: http://lxr.mozilla.org/mozilla-centra.../pkixtypes.h#46

Back, got the list for nightly here: [https://dxr.mozilla.org/mozilla-central/source/security/pkix/include/pkix/pkixtypes.h#46] To get the current release mxr list: [http://lxr.mozilla.org/mozilla-central/source/security/pkix/include/pkix/pkixtypes.h#46]
swinster70 0 solutions 7 answers

Helpful Reply

Hi Guigs2,

From the other post you link too, I can confirm that both the Root and Subordinate CA have been commissioned with the:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\IssuingCA\CSP\AlternateSignatureAlgorithm = 1

registry key set. As can be seen above, the Signature algorithm on an issued certificate is RSASSA-PSS. This is been Microsoft suggested deployment IF you do not wish to support either XP or Windows 2003 machine and lower. In fact, I believe the option has been around since Windows 2008, however, there were of course, a lot more XP machines back then.

The obvious answer is that we would like to maintain the updated algorithm, AND see support for it added for Firefox. I think you will see a LOT more posts like this as people deploy more 2012 PKI infrastructure supporting only Windows 7 and up. Heavens, we may well be forced to Chrome or even back to IE!!! Whilst I do not what to necessary open up other potential vulnerabilities, for the sake of testing, what do you mean by disabling mozilla:pkix?

Hi Guigs2, From the other post you link too, I can confirm that both the Root and Subordinate CA have been commissioned with the: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CertSvc\Configuration\IssuingCA\CSP\AlternateSignatureAlgorithm = 1 registry key set. As can be seen above, the Signature algorithm on an issued certificate is RSASSA-PSS. This is been Microsoft suggested deployment IF you do not wish to support either XP or Windows 2003 machine and lower. In fact, I believe the option has been around since Windows 2008, however, there were of course, a lot more XP machines back then. The obvious answer is that we would like to maintain the updated algorithm, AND see support for it added for Firefox. I think you will see a LOT more posts like this as people deploy more 2012 PKI infrastructure supporting only Windows 7 and up. Heavens, we may well be forced to Chrome or even back to IE!!! Whilst I do not what to necessary open up other potential vulnerabilities, for the sake of testing, what do you mean by disabling mozilla:pkix?
guigs 1072 solutions 11697 answers

Of course, I can confirm that there is no "anti" implementation, its just currently not being worked on.

If you are receiving sec_error_bad_der See [ https://bugzilla.mozilla.org/show_bug.cgi?id=1088140] It was also being worked on here: https://bugzilla.mozilla.org/show_bug.cgi?id=158750 there is some information on implementation.

Its possible to vote on these bugs, however before posting on them please see the bug etiquette:https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Also, kpix was the new certificate implementation that came out in 33. More information on the RSA forgery here: https://blog.mozilla.org/security/201.../rsa-signature-forgery-in-nss/

Of course, I can confirm that there is no "anti" implementation, its just currently not being worked on. If you are receiving sec_error_bad_der See [ https://bugzilla.mozilla.org/show_bug.cgi?id=1088140] It was also being worked on here: [https://bugzilla.mozilla.org/show_bug.cgi?id=158750] there is some information on implementation. Its possible to vote on these bugs, however before posting on them please see the bug etiquette:[https://bugzilla.mozilla.org/page.cgi?id=etiquette.html] Also, kpix was the new certificate implementation that came out in 33. More information on the RSA forgery here: [https://blog.mozilla.org/security/2014/09/24/rsa-signature-forgery-in-nss/]
swinster70 0 solutions 7 answers

Many thanks for this.

WRT to the RSA forgery, does this apply to ALL RSA signed thing, or just specifics. There are so many acronyms and specifics in cryptography, I nevery really know what bit apply to what.

Many thanks for this. WRT to the RSA forgery, does this apply to ALL RSA signed thing, or just specifics. There are so many acronyms and specifics in cryptography, I nevery really know what bit apply to what.
guigs 1072 solutions 11697 answers

I do not know the vulnerability bug was made private, sorry about that. That may be a question for the security team.

I do not know the vulnerability bug was made private, sorry about that. That may be a question for the security team.
cs413 0 solutions 1 answers

Helpful Reply

Our users started seeing this error when Firefox upgraded to 37.0.1. It does not happen with 36.0.4. We advised our users to downgrade or use another browser. The connection established by Firefox 36.0.4 uses TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2. The cert is a wildcard cert with a partial wildcard, for example foo*.example.com, but I don't know why this would suddenly cause Secure Connection Failed with sec_code_bad_der. The user has no option to continue. The cert otherwise is very standard (common fields/extensions) and has been in use for years with no issue on any of the browsers.

Our users started seeing this error when Firefox upgraded to 37.0.1. It does not happen with 36.0.4. We advised our users to downgrade or use another browser. The connection established by Firefox 36.0.4 uses TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 128 bit keys, TLS 1.2. The cert is a wildcard cert with a partial wildcard, for example foo*.example.com, but I don't know why this would suddenly cause Secure Connection Failed with sec_code_bad_der. The user has no option to continue. The cert otherwise is very standard (common fields/extensions) and has been in use for years with no issue on any of the browsers.
guigs 1072 solutions 11697 answers

cs413 please consider a new thread for further investigation:

It really depends on the case but if you have an example url let's start a new thread. ty!

cs413 please consider a new thread for further investigation: *[https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_certificates] It really depends on the case but if you have an example url let's start a new thread. ty!
dapc 0 solutions 1 answers

We have exactly the same issue of cs413 but we found this

the certificate is issued to my.webpage.com

I got sec_code_bad_der. but if i call in the browser the public ip of the server

https://150.***.***.*** goes ok

any Idea?

We have exactly the same issue of cs413 but we found this the certificate is issued to my.webpage.com I got sec_code_bad_der. but if i call in the browser the public ip of the server https://150.***.***.*** goes ok any Idea?