My understanding is that SHA1 is pretty much considered obsolete.

Yet, I just opened the Trusted Root Certificate Authorities on my Windows 10 computer and I see that most Trusted Root Certificate Authorities use SHA1 certificates, most expiring well into the 2030's.

This includes root CAs from Verisign, thawte, GeoTrust, DigiCert... etc.

My understanding is also that any certificate issued by a CA will automatically have the same hash algorithm and bits as the root CA, so doesn't this ultimately mean our computers are set to blindly trust something that uses a now considered obsolete hash?

I understand that whether any certificates issued by these CAs are still in use or not is a completely different thing altogether, but why do we just blindly trust them (the CAs and ultimately their issued certs) to begin with?

Edit

In fact, some root CAs still use MD5...

marked as duplicate by Xander, Xiong Chiamiov, Steffen Ullrich, techraf, schroeder Mar 14 '17 at 7:41

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

My understanding is also that any certificate issued by a CA will automatically have the same hash algorithm and bits as the root CA

This is incorrect. A CA certificate can issue certificates with different signature algorithm than its own.

A Root certificate is trusted because of its presence in the browser's root certificate store, rather than by its signature. The root's signature is not used for anything, except perhaps as a convenient way to talk about the certificate during initial validation of the root certificate for inclusion in the browser root store. Root Certificates with weak signature that has been included in the root store for years are more trustworthy than ones that had just been included recently, as there are more time for the CA, browser developer, and the public to notice if something is off with the root certificate shipped in the browser.

  • Ok, but if a trusted root CA uses what we now consider to be an insecure and prone to collision attacks hash algorithm, doesn't that mean it's also easier for someone to forge a certificate as if it had been issued by that root CA, therefore causing our machines to blindly trust them, exactly because of an increased likelihood of a collision attack? – cogumel0 Mar 19 '17 at 18:54
  • @cogumel0: even if it's possible to forge a root with the same hash, it won't be possible to have browser manufacturers (and to some extent non-malicious sysadmins) to include the forged root in the browser's default root database as the root database stores the entire root certificate, not just the hash. – Lie Ryan Mar 19 '17 at 21:26
  • I was talking about forging a certificate as if it had been issued by the CA, not forging the CA itself... If the CA is in the trusted root list all certs issued by it will be automatically trusted too. – cogumel0 Mar 19 '17 at 22:32
  • @cogumel0: browsers don't trust a CA, they trust a specific Root Certificate. Intermediate CA Certificates and End Entity Certificates (i.e. certificates issued by the Root Certificates) are subject to SHA1 deprecation, and yes if you can create a SHA1 collision on a certificate, you can forge an Intermediate CA or End Entity certificate, which is why SHA1 is no longer allowed for them, but that's not your question as I understand it. – Lie Ryan Mar 19 '17 at 22:44
  • Right, the CA is not trusted, the certificate issued by a CA is trusted (which is what makes it a "root"). My point is that if the trusted root certificates we have are using SHA1, so will any certificates they issue, correct? So bearing in mind Verisign among others still has some trusted root certificates using SHA1, would it not be possible for someone to forge a certificate as if it had been issued by this CA by means of hash collision (among others)? As far as your browser a browser is concerned that certificate would be trusted and be seen as being signed by Verisign (in this example). – cogumel0 Mar 19 '17 at 23:25

Root certificates is verified by the issuing authority name (Symantec, Entrust, etc) not by its signatures.

  • What you probably mean is that the root certificate of a trust chain is found by looking for a certificate where the subject matches the issuer of another certificate in the chain. But this has nothing to do with verification of the root certificate, only with finding the matching root certificate. Any root certificate in the trust store is simply trusted because it is in this trust store, there is no further verification of the certificate itself. – Steffen Ullrich Mar 14 '17 at 6:36

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