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"
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.
Wubrane rozrisanje
I was able to identify the issue. Our PKI was using some signature algorithms that FF did not support.
Tutu wotmołwu w konteksće čitać 👍 1Wšě wotmołwy (15)
This means that is was not properly encoded https://wiki.mozilla.org/SecurityEngi.../x509Certs
I am also asking for help from the security team.
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.
Wubrane rozrisanje
I was able to identify the issue. Our PKI was using some signature algorithms that FF did not support.
Can you tel me what security algorithms were used and what is it that FF doesn't support?
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
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.
Wot swinster70 změnjeny
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.
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
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?
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/
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.
I do not know the vulnerability bug was made private, sorry about that. That may be a question for the security team.
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.
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!
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?