Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

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"

  • 15 replies
  • 111 have this problem
  • Last reply by dapc

more options

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

All Replies (15)

more options

This means that is was not properly encoded

I am also asking for help from the security team.

more options

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.

more options

Chosen Solution

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

more options

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

more options

It will depend on the NSS version listed in about:support , but the listed supported algorithms are listed here:

more options


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


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



      • 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:


in addition, there is reference to:


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

more options

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

In the previous version: 316 there were errors for the signature algo: RSA-PSS via

It may be safe to say it is not supported. This other thread with a self assigned cert by changing a key 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.

more options

Back, got the list for nightly here:

To get the current release mxr list:

more options

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?

more options

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 [] It was also being worked on here: there is some information on implementation.

Its possible to vote on these bugs, however before posting on them please see the bug etiquette:

Also, kpix was the new certificate implementation that came out in 33. More information on the RSA forgery here:

more options

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.

more options

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

more options

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*, 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.

more options

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!

more options

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

the certificate is issued to

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?