1088140 - certverifier: support certificates signed with RSASSA-PSS

Status: RESOLVED FIXED

(Core :: Security: PSM, enhancement, P1)

Description

[Christopher Karel]

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

Comment 1

[Christopher Karel]

Attachment: Private infrastructure signing CA chain.

Comment 2

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

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.

Comment 3

[Christopher Karel]

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.

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(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?

Comment 5

[Christopher Karel]

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?

Comment 6

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(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?

Comment 7

[Christopher Karel]

Now that we know what the issue is, I'm certain we can get it changed.  Thanks for the help with that!

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Resolving as INVALID (a.k.a. "works as intended) based on the above discussion.

Comment 9

[saulschwartz]

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

[saulschwartz]

Re-issuing to SHA256 did not fix the issue.

Comment 11

[Matthias Versen [:Matti]]

saulschwartz: 
What is the exact error message that you get ?
Do you also get "sec_error_bad_der" ?

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 13

[saulschwartz]

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

[saulschwartz]

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.

Comment 15

[Christopher Karel]

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

[Robert Hoffman]

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

[Chris]

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

Comment 18

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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?

Comment 19

[Chris]

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

Comment 20

[Rinat]

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.

Comment 21

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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

Comment 22

[Andy Johnstone]

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

[Peter]

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

[Rinat]

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

Comment 25

[Chris]

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.

Comment 27

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We do not currently have plans to implement support for this.

Comment 28

[René Korthaus]

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

[Hubert Kario]

(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

[Kai Engert (:KaiE:)]

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?

Comment 31

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Seems so.

Comment 32

[Hubert Kario]

NSS now supports RSA-PSS signatures, would it be possible to try whitelisting rsa-pss signatures in mozilla::pkix?

Comment 33

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

This is potentially something we could implement. We don't have engineering resources for it at the moment, though.

Comment 34

[benjamin]

Any update on this? We are facing the same issue with our internal CA and firefox users.

Comment 35

[Wayne Thayer]

Note that we're planning to explicitly call out RSA-PSS as a valid encoding in the 2.7 update of the Mozilla Root Store policy. I plan to include a note that these encodings are not currently supported by Firefox.

Comment 36

[Ben Wilson]

Currently GitHub issue 217 (https://github.com/mozilla/pkipolicy/issues/217) is tagged with a label indicating that in the next version of the Mozilla Root Store Policy (version 2.7.1), "When Bug #1088140 is fixed, remove the following sentence from section 5.1.1: 'Note: as of version 70, RSASSA-PSS encodings are not supported by Firefox.' " If we go to publication of version 2.7.1, do we make that editorial change, or is this something we kick over to a later version?

Comment 37

[Wayne Thayer]

I wouldn't remove that comment from the policy until this bug is resolved fixed. You could, however, update the reference from Firefox 70 to the current version.

Comment 38

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: Bug 1088140 - support RSA-PSS signatures on certificates in the certificate verifier r?jschanck

Comment 39

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ce6df4d63ec
support RSA-PSS signatures on certificates in the certificate verifier r=jschanck

Comment 40

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/3ce6df4d63ec