15

Taken from here:

Don't worry if the root certificate uses SHA1; signatures on roots are not used (and Chrome won't warn about them.

Why are the signatures not used? Are not root certificates vulnerable too? Is there nothing that can be gained from breaking SHA1 to fake a root cert?

1
  • Lesson to learn: Now that the link is gone, the descriptive text "here" does not help anybody. Please do not title links with here (Wouldn't it be there anyway?)!
    – U. Windl
    Commented Aug 17 at 23:04

3 Answers 3

21

A root certificate is a self-signed certificate (by definition).

So how do you want to verify the signature of a root certificate? The root certificate is valid in itself, therefore you cannot verify it.

This is also the most problematic part of root certificates: they cannot be validated independently. If they are in the browser, then they are trusted.

8
  • 1
    @user53029: That is "a practical attack vector to impersonate a website"; it's just independent of what hash(es) was/were used in root certificate(s)'(s) self-signature(s).
    – user49075
    Commented Sep 17, 2014 at 11:21
  • 4
    @user53029 That actually happened recently. DigiNotar, a Dutch certificate authority, was hacked a few years ago and issued fraudulent root certificates for the Google domain. the hackers then managed to hack 300,000 Iranian Gmail users. DigiNotar is now bankrupt and all certificates issued by it have been revoked by every major browser.
    – Nzall
    Commented Sep 17, 2014 at 11:26
  • 3
    @user53029 either the hash needs to be broken (which happened in 2008 with MD5 hashed certs) or the CA needs to be compromised. Most CA's use heavy physical authority including measures like keeping the root certificate itself offline to prevent catastrophic damage in the event of a hack. security.stackexchange.com/questions/24896/… Commented Sep 17, 2014 at 12:50
  • 3
    @user53029 If you have access to a user's trust store, you could just add your own root certificate without having to mess with existing certificates for the same effect. See also Ángel's answer and the comment.
    – ntoskrnl
    Commented Sep 17, 2014 at 15:01
  • 2
    @NateKerkhofs Regarding DigiNotar: A certificate authority does not issue root certificates. Root certificates are self-signed and they are on the top (root) of the CA hierarchy chain. There is no CA above them to sign the certificate. The fraudulent certificates were signed by the DigiNotar CA. ------ Extending the answer: You either trust a root certificate or not. It is your decision. The signature serves no real purpose there, it could be created by anyone. --- Hash received through a different way can be used to check the integrity of the certificate. Commented Sep 24, 2014 at 8:22
18

The browser already contains a copy of the root cert. Thus, it doesn't need to verify it through its signature. Even if you broke SHA-1, you couldn't replace the root certificate that is already stored in the browser.

1
  • 17
    Or, from the other direction, if you can alter the root certificate store (for example by saying "employee, install this corporate root certificate if you want to keep your job", or by patching the browser), you can insert your own certificate regardless of which signature algorithm you use, and regardless of which algorithms legitimate CA certificates used.
    – armb
    Commented Sep 17, 2014 at 12:27
6

For non-root CA certificates, the browser can only verify the certificate by validating the signature of the certificates hash. If the signed hash was generated by a weak algorithm, an attacker may be able to create a fake certificate with the same hash, but a different key pair.

For a root certificate, however, this does not have to be a problem. Since the entire trusted certificate (not just the hash) is in your trusted root store, it is possible to compare the full certificate, and not just the hash. As such, the hashing function used is irrelevant.

You must log in to answer this question.

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