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


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
  • 41
    Because the system does not support certificates that aren't signed. – OrangeDog 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

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

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

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.


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)

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.