Home / server / Questions / 837994
Accepted
131
Asked: 2017-03-14 07:09:44 +0800 CST

Why are CA root certificates all SHA-1 signed (since SHA-1 is deprecated)?

  • 772

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

ssl certificate-authority ssl-certificate

6 Answers

  1. Best Answer

    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.

    • 110

  2. 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.

    • 46

  3. 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.

    • 7

  4. 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.

    • 1

  5. 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)

    • 0

  6. 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.
    • -1