PCI Compliance - SHA1 Root

[churchers]

Hi,

I know PCI compliance has been discussed before, and it’s not really the job of the certificate provider, but I thought this the best place to raise this issue (and it’s a bit more specific than previous discussions).

I’ve just had a customer trying to get through the automated PCI compliance scans. At first I was required to disable TLSv1 and a few ciphers (even though ssllabs already reported A grade), but no issues there.
However, I’m now faced with the following -

"The remote service uses a known CA certificate in the SSL certificate chain that has been signed using a cryptographically weak hashing algorithm. Note that this plugin reports all SSL certificate chains signed with SHA-1 that expire after January 1, 2017 as vulnerable. This is in accordance with Google’s gradual
sunsetting of the SHA-1 cryptographic hash algorithm.

The following known CA certificates were part of the certificate
chain sent by the remote host, but contain hashes that are considered
to be weak."

Now first of all, I’m fairly certain, by looking at the fullchain.pem file, that “the remote host” is not sending the root CA certificate. They also mention being “in accordance with Google’s sunsetting of SHA-1”, yet even though this started at least 4 years ago, Google are clearly perfectly happy to still mark these certificates as “Secure”.

So are they being incorrect here and rejecting a certificate which should be perfectly valid?

Of course this does mean that as it stands, it’s impossible for an LE certificate to be used on any site where you may need PCI compliance, as they will reject the root CA…

Regards,
Matt

[_az]

The signatures that appear on the roots are not a factor in determining trust, because root certificates are trust anchors/self signed (it would be meaningless to verify the signature of a certificate signed by its own private key).

Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.

Whoever is printing out the PCI compliance report from Nessus doesn’t know what they are doing. If you are accidentally sending the root in the chain from the server then I can see that it might trigger some kind of false positive result, but otherwise I think it’s simply a question of being misinformed.

[danb35]

See also PCI DSS scan failed

[churchers]

Ah, thanks for the link. I didn’t find that in my original search, just much older posts.

I’m going to try and contact the scanning company as clearly they are not “in accordance with Google” here and are rejecting perfectly valid certificates. Not sure how far i’ll get…

[schoen]

You could also try sending a https://www.ssllabs.com/ scan report. Although it's not written in terms of the PCI DSS rules, it's always been significantly stricter than them on pretty much every issue. You can get an A+ with SSL Labs with a Let's Encrypt certificate.

The problem of course is that someone might say "No, but that's not enforcing PCI rules in particular". In that case you're kind of stuck because even though the tests are designed by the author of the best book on TLS

https://www.feistyduck.com/books/bulletproof-ssl-and-tls/

and updated frequently, they aren't referenced to PCI rules.

Maybe we could somehow get someone from PCI to issue a statement confirming that Google is right about this?

Edit:

https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-is-the-Council-s-guidance-on-the-use-of-SHA-1

says

Whether the use of SHA-1 meets the intent of “strong cryptography” will depend on how SHA-1 is used. The Council defers to industry standards bodies such as NIST and ANSI for determining the acceptability of specific cryptographic functions. Organizations should refer to industry resources such as NIST Special Publication 800-131A and other industry guidance for additional information on acceptable uses for SHA-1.

Maybe the Google statement counts as "other industry guidance"?

[Patches]

NIST says you cannot use SHA-1 for digital signatures created after December 1, 2013. NIST continues to allow the verification of digital signatures using SHA-1 created before that date.

While it is typically not necessary to verify the signature of a root certificate like the DST Root CA X3, even if you needed to you still could and be compliant with NIST’s guidelines, since it was created in 2001.

Google, Mozilla, and Microsoft’s deprecation of SHA-1 appears to exceed the NIST requirement, as they do not permit the use of any SHA-1 intermediate certificate authority, even ones created before 2013.

So If PCI automated scanning vendors are implementing NIST guidelines, they should allow any SHA-1 signature created before 2013. If they are implementing the browsers’ stricter guidelines, they should only allow root certificates to have SHA-1 signatures. Either way, flagging the DST Root CA X3 is wrong.

I’m surprised your PCI scanning tool doesn’t have a way to easily dispute a vulnerability finding. False positives on security scans are common and disputing them is a routine matter.

[churchers]

Just a follow up, I contested the result through their portal, which was accepted, but a following scan has also failed and I’m not yet clear until I speak to them if it’s the same issue. (Hopefully I won’t have to contest it every time they scan)

Of course the amusing part is that this scan is being done by Lloyds Bank (using Sysnet scanning services). Lloyds’ entire online banking presence (millions of personal and business customers) is running on certs with a SHA-1 root that doesn’t expire until 2031…