mozilla::pkix doesn't support certificates signed with RSASSA-PSS/RSA-PSS

REOPENED
Unassigned

Status

()

Core
Security: PSM
P3
normal
REOPENED
3 years ago
16 days ago

People

(Reporter: Christopher Karel, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [psm-backlog])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8510418 [details]
Inspection device certificate chain.

Our company has two sets of internal certificates being used.  Both of them started failing with FF33.  They seemed to work fine in FF32 and earlier, and still work great in Chrome/IE.  The error appears to indicate there's some sort of issue with the cert, but I'm unaware of any means to actually troubleshoot that.  I see that these certs have a superfluous path length basic constraint, but FF shouldn't be choking on that per Bug 985021.

I just downloaded at tested FF36's Nightly (2014-10-23 build), and the same issue occurs there.

I've attached two cert chains that give us issues.  Both of these are from private CA's.  One we use for signing our own infrastructure certs, and the other for SSL inspection at our gateway security device.
(Reporter)

Comment 1

3 years ago
Created attachment 8510419 [details]
Private infrastructure signing CA chain.
Component: General → Security: PSM
Product: Firefox → Core
For some of those certificates, it looks like the signature algorithm is this:

    Signature Algorithm: rsassaPss
         Hash Algorithm: sha256
         Mask Algorithm: mgf1 with sha256
         Salt Length: 20
         Trailer Field: 0xbc (default)

Looking at bug 158750 and bug 1005084, we unfortunately don't support RSA-PSS yet. I'm surprised this ever worked in Firefox, actually.
(Reporter)

Comment 3

3 years ago
Interesting.  That chain did have some problems being verified in earlier versions of FF if the intermediate cert wasn't trusted.  We had chalked it up to being related to a large keysize, as insinuated in the comments for bug 403220.  

Regardless, there must be something else afflicting at least one of these chains in FF33, because they don't both use RSA-PSS.
(In reply to Christopher Karel from comment #3)
> Interesting.  That chain did have some problems being verified in earlier
> versions of FF if the intermediate cert wasn't trusted.  We had chalked it
> up to being related to a large keysize, as insinuated in the comments for
> bug 403220.

I suspect many of the comments in that bug are now out of date.

> Regardless, there must be something else afflicting at least one of these
> chains in FF33, because they don't both use RSA-PSS.

Right - the interesting thing about that chain is it appears to validate just fine for me with Firefox 36 (Nightly). Do you see the same behavior?
(Reporter)

Comment 5

3 years ago
Hmm...you're right.  It appears the issues with the second chain were caused by a cert8.db corruption that must have been either caused by the 32->33 upgrade, or only noticed then.  I removed and then re-added the root certificate, and the issue went away.

It didn't help the other cert chain, though.  I assume that's explained by the lack of support for RSA-PSS failing differently in than in the past?
(In reply to Christopher Karel from comment #5)
> It didn't help the other cert chain, though.  I assume that's explained by
> the lack of support for RSA-PSS failing differently in than in the past?

I think so, yes, unfortunately. Can you or someone at your organization regenerate those certificates with different signature algorithms?
(Reporter)

Comment 7

3 years ago
Now that we know what the issue is, I'm certain we can get it changed.  Thanks for the help with that!
Resolving as INVALID (a.k.a. "works as intended) based on the above discussion.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID

Comment 9

3 years ago
I'm having the same issue, and my chain looks very similar to Christopher's internal CA Chain. I just built a new enterprise PKI using Windows 2012 R2 and chose RSA-PSS as our signature algorithm for the Root and intermediate certificates. End-entity cert is using SHA256.

Comment 10

3 years ago
Re-issuing to SHA256 did not fix the issue.
saulschwartz: 
What is the exact error message that you get ?
Do you also get "sec_error_bad_der" ?
I'm going to reopen this, because SEC_ERROR_BAD_DER is the wrong error to return. Instead, the error code should be something like SEC_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM.

When you use the RSA-PSS algorithm, I recommend that you choose SHA-256 or stronger, not SHA-1. It is likely that if we add RSA-PSS support to mozilla::pkix, we won't add SHA-1 support.

Also, could you please tell me how much control your CA software gave you over the salt length? Was that a parameter that you chose? Or, does the CA software pick it for you?

It would be great if you could share some certificate that you generated using Windows Server 2012 R2.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: sec_error_bad_der on Internal certs → SEC_ERROR_BAD_DER on certificates with RSA-PSS signatures and/or RSA-PSS public keys

Comment 13

3 years ago
Yes, I got the sec_error_bad_der.

When I changed to sha256, it still got sec_error_bad_der, but once I imported the Intermediate cert to the browser, everything worked. 

Before I changed to sha256 (RSA-PSS), even importing the certificate wouldn't work.

Comment 14

3 years ago
Also - no, I don't think we had the option of controlling the salt length by default. The CA is just Microsoft Active Directory Certificate Services, Windows 2012 R2. 

I'm trying to figure out how to attach an item to share the cert chain.
(Reporter)

Comment 15

3 years ago
Brian, for what it's worth, the RSA-PSS certificate chain I've already uploaded was generated via a Windows 2012R2 CA.  From speaking with the admin of that machine, he doesn't recall any options for salt length.

It's also worth noting that RSA-PSS isn't supported on Certificate Authorities, even though I was under the impression that root certs don't have their signature checked.  (ie:  Sha1 is fine for a root cert) So if you have this issue, re-issuing client certs isn't enough.  You'll need to make sure that whatever CA is trusted by FireFox is also not using RSA-PSS.

Comment 16

3 years ago
I'm having a similar issue where we have a Windows 2008 R2 CA and any certificates that I issue using that CA work fine in IE and in Chrome.  In Firefox versions 33.0.2 I get the following error:

Secure Connection Failed

An error occurred during a connection to server1. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der)

    The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
    Please contact the website owners to inform them of this problem.

Comment 17

3 years ago
I believe the that when you setup a CA in Windows, the suggest Microsoft deployment is to set the registry key:

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

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. 

Setting this to 0 and in the capolicy.inf file, then reissuing the the CA Certs and so on may resolve this (see https://support.mozilla.org/en-US/questions/986085)

However, 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!!!
Thanks Chris. That is very useful information.

I am curious about why you chose RSA-PSS instead of ECDSA. Also, are your end-entity certificates's keys RSA-PSS too?
Flags: needinfo?(swin)

Comment 19

3 years ago
Hi Brian (apologies for the long post, but I think its all relevant),

Like so many sys admins out there especially in small/medium size enterprise or small teams, we cover a multitude of roles from Active Directory maintenances, to web site administration, to database admin, and now PKI. I would not consider myself a security expert in any sense of the word - the proliferation of acronyms and contexts with regard to setting up and maintaining a PKI hierarchy is unwieldy at best. 

So what to do? Well, we have to resort to reading the documentation and basing our decisions of the advice a guidance from the manufactures of the equipment - in our case this is Microsoft. In the first instance, I (along with many others) will be directed to the best practice guidance, specifically the "Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" (http://technet.microsoft.com/en-us/library/cc772670%28v=ws.10%29.aspx) which although directed at Windows 2003, is still the most relevant documentation that Microsoft points to as the vast majority of it is conceptual, and the practices have not really changed over the years, just the implementation. In  the Example (http://technet.microsoft.com/en-us/library/cc779714%28v=ws.10%29.aspx), at step 5 of the "Installing the Offline Root CA Software Components", it refers to using the "Microsoft Strong Cryptographic Provider", which only support up to SHA1.

However, as we are implementing this in 2012r2, the guide falls short, so we need to look elsewhere. This comes at Technet article "Active Directory Certificate Services Overview" (http://technet.microsoft.com/en-us/library/hh831740.aspx). In this guide, the "Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy" (http://technet.microsoft.com/en-us/library/hh831348.aspx) outlines the setup required to implement the aforementioned PKI.

In Step 3 of "To prepare the CAPolicy.inf for the standalone root CA", you will not the use of the AlternateSignatureAlgorithm=1 and the note that follow it which relates to XP and 2003 based machines - well this is now fine for a lot of us to we keep the setting as is.

Then, on step 17 of "To install the standalone root CA", we are asked to "ensure that the cryptographic provider is RSA#Microsoft Software Key Storage Provider, the key length is set to 2048 and the hash algorithm is set to SHA1"

Now, at this point I diverged slightly, having read that SHA1 has been found wanting and is now depreciated (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx), so I up this to SHA256 and also up the key length to 4096. However, I have left the "cryptographic provider" as is outlined in the guide.


As a side note, we also manipulate the registry keys in our Windows servers to alter the 
Windows cryptography settings, and in order to do this we utilise the 
IS 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_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 

Whilst I see that ECDHE suites are preferred by being listed at the top, as they also have RSA in the title, I really had no clue that setting the "cryptographic provider" to RSA#Microsoft Software Key Storage Provider would result in anything other than what I might want. This is also the default option, so will general be selected by most people - and you would have thought would be the most widely supported

This page (http://technet.microsoft.com/en-us/library/hh831574.aspx) lists the other cryptographic providers. The only providers listed with ECDSA in the title are limited in their key lengths to a maximum of 512. I'm not entirely sure how the key lengths of say the RSA#Microsoft Software Key Storage Provider and the ECDSA_P521#Microsoft Software Key Storage Provider differ, but I was under the impression that a larger key length would provide stronger security.

Obviously, to change this is not a trivial scenario. I hope this gives an account of the dilemmas we face in setting up the Certificate Authorities and why you may see more and more users run into this issue with Firefox.

Regards

Chris
Flags: needinfo?(swin)

Comment 20

3 years ago
The following patch solves issue for me:

-------------cut
--- security/pkix/lib/pkixder.cpp.orig	2014-11-26 05:17:37.000000000 +0300
+++ security/pkix/lib/pkixder.cpp	2015-01-12 01:50:28.175275195 +0300
@@ -241,6 +241,7 @@
     algorithm = SignatureAlgorithm::rsa_pkcs1_with_sha1;
   } else {
     algorithm = SignatureAlgorithm::unsupported_algorithm;
+    return Result::ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED;
   }
 
   return Success;
-------------cut

As far as I understand, AlgorithmIdentifier() from pkixder.cpp assumes
oidValueParser() eats all data related to signature algorithm. But
RSA-PSS have additional data block and probably thus the last call to
End(value) fails with Result::ERROR_BAD_DER.

I think, SignatureAlgorithmOIDValue() should return
ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED immediately, if algorithm is
not supported.
(In reply to Rinat from comment #20)
> -------------cut
> --- security/pkix/lib/pkixder.cpp.orig	2014-11-26 05:17:37.000000000 +0300
> +++ security/pkix/lib/pkixder.cpp	2015-01-12 01:50:28.175275195 +0300
> @@ -241,6 +241,7 @@
>      algorithm = SignatureAlgorithm::rsa_pkcs1_with_sha1;
>    } else {
>      algorithm = SignatureAlgorithm::unsupported_algorithm;
> +    return Result::ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED;
>    }
>  
>    return Success;
> -------------cut

<snip>

> I think, SignatureAlgorithmOIDValue() should return
> ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED immediately, if algorithm is
> not supported.

There is a reason we didn't do that in Firefox 37 and earlier. However, as of bug 1130754, which is fixed in Firefox 38, we do exactly that, because that reason no longer applies. Thus, Firefox 38 will give you ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED, which is overridable, instead of SEC_ERROR_BAD_DER, which isn't overridable.
Depends on: 1130754

Comment 22

3 years ago
Not sure if this will assist, but can confirm that we are having issues with SEC_ERROR_BAD_DER for users running Firefox 37.0 but not for users running Firefox ESR or other earlier versions.

The problem is for Certificate Authorities using PKCS #1 RSASSA-PSS Signatures.

Unfortunately, this is our new corporate standard.

Comment 23

3 years ago
Certificates using RSASSA-PSS are quite common as MS ADCS (2012) are issued quite frequently. Are there any (time) plans to implement this new "feature" in the near future?

To be honest I'm a little bit surprised that a standard defined in 2005 (!!!) is still not implemented in Mozilla software.

Comment 24

3 years ago
I have no more issues with RSA-PSS certificates since Firefox 38.0.

Comment 25

3 years ago
Great. Many thanks. Now, all I need to do is somehow deploy our root CA certs to the Firefox Authorities store as Firefox doesn't seem to want to pick up the Local machines Trusted Root or Intermediate Certification Authority certificate stores. This is so users will not see the security warning from our self signed certs.
Duplicate of this bug: 1227203
Summary: SEC_ERROR_BAD_DER on certificates with RSA-PSS signatures and/or RSA-PSS public keys → mozilla::pkix doesn't support certificates signed with RSASSA-PSS/RSA-PSS
Depends on: 1215295
We do not currently have plans to implement support for this.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago2 years ago
Resolution: --- → WONTFIX

Comment 28

10 months ago
You should definitely reconsider this decision, for several good reasons.

(1) The European Union's Agency For Network and Information Security recommended use of PKCS#1 v1.5 signatures in legacy applications only already in 2014, see https://www.enisa.europa.eu/publications/algorithms-key-size-and-parameters-report-2014, section 4.6.1
(2) Germany's Federal Agency for Information Security does not allow PKCS#1v1.5 signatures anymore, PSS is required now, see https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=3 chapter 5.4.1 (German only)
(3) It was added to NSS already in 2010, see https://bugzilla.mozilla.org/show_bug.cgi?id=158750 and https://blog.hboeck.de/archives/737-Secure-RSA-padding-RSA-PSS.html
(4) TLS 1.3 will drop PKCS#1 v1.5 signatures in favor of PSS
(5) Safari, IE and Chrome all support it already today

Comment 29

10 months ago
(6) The TLS 1.2 specification (RFC 5246) says, that the signature algorithms advertised in the signature_algorithms extension specify also the signatures supported for server certificates. Thus a server that replies with RSA-PSS signed certificate to a Client Hello that includes RSA-PSS algorithms is behaving correctly. At the same time, client that does advertise that support but doesn't support it, is not following the standard.

Comment 30

10 months ago
David, do you think comment 28 and comment 29 are good arguments to reopen this bug?

It sounds like this issue can cause interoperability failures with servers?
Flags: needinfo?(dkeeler)
Seems so.
Status: RESOLVED → REOPENED
Flags: needinfo?(dkeeler)
OS: Windows 7 → All
Priority: -- → P3
Hardware: x86_64 → All
Resolution: WONTFIX → ---
Whiteboard: [psm-backlog]
Version: 33 Branch → Trunk

Comment 32

a month ago
NSS now supports RSA-PSS signatures, would it be possible to try whitelisting rsa-pss signatures in mozilla::pkix?
Flags: needinfo?(dkeeler)

Updated

a month ago
Depends on: 1005084
This is potentially something we could implement. We don't have engineering resources for it at the moment, though.
Flags: needinfo?(dkeeler)
You need to log in before you can comment on or make changes to this bug.