3

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

cogumel0
  • 131
  • 2

2 Answers2

3

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.

Lie Ryan
  • 31,459
  • 6
  • 70
  • 94
  • 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
  • @cogumel0: the browser needs the public key embedded in the issuer certificate to validate a certificate. If an attacker manages to create a forged root certificate with the same signature as a trusted root certificate, they won't be able to issue a certificate that will be trusted by browsers because the browser won't have the forged certificate's public key in their trust database. In such case, the browser would try to validate certificates issued by the forged root using the legitimate root's public key, and the forged root's signature would not be valid. – Lie Ryan Mar 20 '17 at 01:33
  • Lie, you keep coming back to forging root certificates. I have no idea where you read that from. I've always said forging a (End Entity) Certificate as if it had been issued by a trusted root certificate authority. – cogumel0 Mar 20 '17 at 07:25
  • @cogumel0: as I have said in the first paragraph of my answer, a certificate authority can issue certificates with a different signature algorithm than the root certificate, and this is a very common practice. All roots with sha1 or weaker root hashes are still trusted because they do this. The strength of the root certificate's hash algorithm does not weaken the strength of signatures made by the root. – Lie Ryan Mar 20 '17 at 12:56
  • Let us continue this discussion in chat. – cogumel0 Mar 20 '17 at 13:02
-2

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

ObiWanKenobi
  • 9
  • 6
  • 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 06:36