PCI DSS scan failed

Help
1

My domain is: secure.lexicom.ca

Not sure this is the right category but I couldn’t identify a better one so here goes.

As part of a quarterly PCI “vulnerability” scan, the scanner (“SafeMaker”) raised a “non-compliant” vulnerability complaining about the “O=Digital Signature Trust Co./CN=DST Root CA X3” certificate in the chain. Specifically, their complaint is, “A known CA SSL certificate in the certificate chain has been signed using a weak hashing algorithm.” They claim it’s in compliance with the “sunsetting of SHA1 hashes” but they provide no references on that sunsetting applying to root certificates.

My understanding is that they are raising this complaint in error since they’re complaining about a root certificate, but they have so far ignored the false positive I’ve raised. I haven’t been able to find any definitive policy reference on SHA-1 being allowed for the self-signature on root certificates, though. (Weak Google-fu maybe.)

1 Like
2

Hi @astle, I think this is the right category :slight_smile:

You're correct - this is an erroneous finding. I'm not sure if there is a "definitive" reference, but the signature on the root certificate is not validated the same way a signature on an intermediate or leaf certificate is and the SHA1 deprecation by Google/Mozilla does not apply. You can find information confirming this in a few places, e.g:

Edit: here's another answer I provided a user in the forum with the same question: SHA-1 signed certificate in chain - #2 by cpu

3

@astle I just noticed Google's announcement on SHA1 deprecation does specifically say that roots are not affected:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

That should be definitive!

2 Likes
4

Another way of thinking about Google’s policy statement is that it’s true for the same reason that you aren’t supposed to send root certificates as part of a certificate chain during the TLS session establishment: if the client already trusts the root certificate, it won’t learn anything by receiving an additional copy of it (receiving it is redundant); if it doesn’t already trust the root certificate, it won’t learn anything by receiving a copy of it (receiving it is unpersuasive). In either case, the client doesn’t verify the validity of the root certificate itself because there’s no external standard by which its validity could meaningfully be tested.

2 Likes
5

Indeed. That does seem pretty definitive. I’ll see if that gets me anywhere with the PCI scanning people.

1 Like
6

The scanning vendor finally accepted the false positive report with the various bits of evidence. Thank you, everyone who responded.

3 Likes
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.