68

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

107

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.

  • 3
    Brings the question of why they are signed at all – Richard Tingle Mar 14 '17 at 12:54
  • 42
    Because the system does not support certificates that aren't signed. – Stop Harming Monica Mar 14 '17 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 Mar 14 '17 at 21:55
  • 20
    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 Mar 14 '17 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 Mar 15 '17 at 13:31
46

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.

  • 2
    Not to mention, updating a root certificate requires going through that out-of-band process again. – Kaithar Mar 13 '17 at 18:06
  • 4
    +1 for the "allegedly, hopefully" – Nathan Osman Mar 16 '17 at 1:36
6

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.

  • 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 Mar 15 '17 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.

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)

-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.
  • 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 Jul 8 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 Jul 11 at 1:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.