74

I understand that SSL certs cannot be signed using SHA-1 anymore. Yet, all CA root certificates are SHA-1 signed (mostly). Does it mean the same algorithm that is no longer trusted for "you grandma SSL shop" is fine for the uttermost top secured certificate of the world?

Am I missing something? (key usage? key size?)

Improve this question
8

6 Answers 6

Reset to default
112

The signature of the root CA certificates do not matter at all, since there is no need to verify them. They are all self-signed.

If you trust a root CA certificate, there’s no need to verify its signature. If you don’t trust it, its signature is worthless for you.

Edit: there are some very relevant comments below. I don’t feel comfortable copying or rephrasing them and taking credit for them instead of their authors. But I welcome people to add explanations to this answer.

Improve this answer
8
  • 3
    Brings the question of why they are signed at all
    – Richard Tingle
    Commented Mar 14, 2017 at 12:54
  • 42
    Because the system does not support certificates that aren't signed.
    – OrangeDog
    Commented Mar 14, 2017 at 14:03
  • It seems to me that the concern with a crackable root cert isn't "you don't know where you got the root cert from", but rather "you don't know who else has been able to crack this cert and use it to sign whatever they want." And it seems from your answer that the two (cert and cert-signing) are separate concerns, and that the cert itself is suitably secure and uncrackable?
    – Dewi Morgan
    Commented Mar 14, 2017 at 21:55
  • 22
    I would go even further than "there is no need to verify them". The purpose of the signature in a certificate chain is that a higher authority certifies a lower authority. For a root CA, there is no higher authority by definition (that's what "root" means), so there is nobody who could possibly sign the certificate. Since, as was mentioned, certificates must be signed, root CAs are signed with a "dummy" signature, and the simplest way to do that, is to self-sign. So, not only is there no need to verify, the very idea of verifying the signature of a root CA is non-sensical.
    – Jörg W Mittag
    Commented Mar 14, 2017 at 23:10
  • 13
    @DewiMorgan You can't "crack" a root cert with a hash collision, because the client trusts the cert itself, not its (self-)signature. You would have to recover the private key, which is an attack on RSA, not on the hash algorithm.
    – zwol
    Commented Mar 15, 2017 at 13:31
48

At the end of the day, a root certificate is self-signed. It is never signed by another entity except itself. The root certificate gets its trust through out-of-band processes like submitting it to a browsers list of trusted publishers, or getting it accepted by Microsoft for insertion into the default list of Windows trusted publishers.

These certificates (and the companies that self-signed them) are (allegedly, hopefully) thoroughly vetted through other means than just their signatures.

Improve this answer
2
  • 3
    Not to mention, updating a root certificate requires going through that out-of-band process again.
    – Kaithar
    Commented Mar 13, 2017 at 18:06
  • 5
    +1 for the "allegedly, hopefully"
    – Nathan Osman
    Commented Mar 16, 2017 at 1:36
7

The only case where this matters, is if the root is signed by SHA-1 it can be revoked by SHA-1. That is, somebody who can attack SHA-1 can construct a revocation for the root. And I'm absolutely sure the browser doesn't know how to persist that so the vandal has accomplished no more than dropping SSL connections. How lame.

Improve this answer
1
  • 1
    This is an interesting thought but I doubt this would work just this way. My guess is that each agent would have it's own unique behavior, but I doubt any developers had the idea that the revocation list would be used to manage revocation of root certs. At the very least, if this worked in some cases, it would be due to abstraction of software revocation and not intentionally by developers.
    – Peter Oehlert
    Commented Mar 15, 2017 at 14:58
1

As a note on this one, SOME CAs have already been updating their root and intermediate certificates to SHA256 anyway.

I know that last year GlobalSign was updating their certificates as we were updating our code-signing certificates, so I had to add their new chain to those, too.

You can check which specific certificates got updated and which ones they updated but also left a legacy SHA1 certificate for here => 1

Hope that helps.

Improve this answer
0

For root CA, you give you trust to the public key of the CA -bundled in the CRT - regardless its self signature.

Describing CA using the .CRT file format instead of a raw public key .PEM allows to bundle more details in it - e.g. CA name - (yet again, the signature is worthless)

Improve this answer
0
-1

There are very old, mostly 2006 or earlier era already trusted pinned SHA1 root certificates that browsers accept, but not any newer certificates. Remember when Firefox and Chrome were versioned using single digits?

Certificates fail if the root CA uses SHA1 certificates with the Not Before set to something after 2014. The actual date restrictions depends on the browser or other application. The WebCA cabforum made this clear several years ago. Test this yourself by:

  1. Create a private root Certificate Authority infrastructure signed with a SHA1, call it rootSHA1
  2. Have rootSHA1 create an "issuing" CA or "intermediate" CA that issues certificates with a certificate chained up to the root. Call it intermediateSHA256.
  3. Have the intermediateSHA256 issuing CA generate a certificates signed with a sha256 or greater hash. Call it webServerSHA256.
  4. Install webServerSHA256 into the webServerSHA56.mydomain.com.
  5. Install the rootSHA1, the intermediateSHA256, and the webServerSHA256 certificates into appropriate locations in Google Chrome. Install the root to Trusted Root Certification Authorities and the others with a certificate chain.
  6. Navigate Google Chrome to https://webServerSHA256.mydomain.com/ and verify there is not a green padlock for webServerSHA256. Test fails.
Improve this answer
4
  • This is quite wrong. Intermediate certs (and EE./leaf certs) do require SHA2, but roots do not. Google's own certs chain through their private CA (Google Internet Authority G3) to GlobalSign Root CA R2 -- which is SHA1 -- and (no surprise) are accepted by Chrome.
    – dave_thompson_085
    Commented Jul 8, 2019 at 3:05
  • Yes those pinned SHA1 certs are accepted, but not any new SHA1 root certificates even if you add it to your own Trusted Root certificate store. Added a test case to my answer.
    – rjt
    Commented Jul 11, 2019 at 1:32
  • What you are effectively demonstrating is that, the rootSHA1 certificate you are installing at step 5 in the relevant trust store, does not have the same level of trust associated as have the "CA root certificates" which are coming preinstalled with the browser or the system: the former should use SHA2 hashes to turn green, but the latter might use SHA1. The result is interesting in itself; but you did not really think you –or your IT team– might have the same level of trust as are having the developers of the browser, did you?
    – AntoineL
    Commented Jun 12, 2020 at 17:10
  • Of course I do not believe our IT team has the same level of trust and that is exactly my point. Thank You. Even though the root cert is in the same trust store and signed the with a SHA1, it is not the same most likely because of the dateStamp. It is a demonstration that not all SHA1 root certificates are trusted by chrome even if you explicitly tell the web browser to trust it. It is immaterial that the root is signed by itself and the theoretical discussion above, Chrome would still not trust it because it was SHA1.
    – rjt
    Commented Jun 12, 2020 at 19:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .