We have thousands of servers that have been issued certificates signed by our CA using SHA256 but the our root CAs own certificate was generated using SHA1. Assuming SHA1 is no longer secure for our purposes what exactly is the threat to our infrastructure if our root CA certificate was signed using SHA1?


2 Answers 2



You don't trust the Root CA certificate because it was signed by anything - you trust the Root CA because you (or someone on your behalf) placed it in your trust anchor store.

A Root CA certificate has a signature simply because it is mandatory within the X509 specification - it serves no other purpose.

Technically, the trust anchor doesn't have to be a certificate, but most (all?) operating systems have taken the decision to use the X509 certificate format to store the trust anchor - there are others defined (RFC 5914) that don't have a signature, but as far as I'm aware, they are not used.

SHA1 deprecation has been in the limelight lately. If your subordinate CA certificates or your end-entity certificates are signed by SHA1, browsers will complain. However, if you sign your Root CA certificate with MD5 or MD4 (or even something earlier if you can find the tools to do so) then everything will still work.

If you take a look at Google, Facebook, Microsoft (and no doubt many more) you'll find that they still have SHA-1 signed Root CA certificates.


The signature of a message is applied over its hashed value. If it is computationally hard to generate a collision for a given hash function, it offers the same level of attestation and it generates a constant size digest that is way shorter than most signed documents.

However, if a way to generate collisions is discovered for SHA-1, it would be theoretically possible to generate a rogue certificate that produces the same hash value and, as a result, is verified by the same signature.

As a practical remark, I would expect two kinds of implications: the technical one, where attackers would create rogue certificates to impersonate other entities, and a legal one. If the binding property of a certificate is questioned, the legal binding of any digital signature produced with the certified key can be plausibly denied.

  • $\begingroup$ Thanks Sergio, but I don't understand. So we have a server X that the attacker wants to impersonate. This servers certificate was signed using SHA256. However the CA's own certificate (which signed this certificate) used SHA1. So the attacker can generate a public key that when hashed with SHA1 produces the same result as the public key of the actual CA certificate. So what? How can he produce a rogue certificate who's signature will validate? $\endgroup$
    – Marcus
    Commented Feb 29, 2016 at 12:57
  • $\begingroup$ There is one point that I missed in my answer: the major pitfall in the PKI scheme is the fact that the root certificate is self signed, and as a result I can create a self-signed certificate in the behalf of ACME as trivially as people in ACME could. In that scheme, adding a new self signed certificate to the trusted list is more reasonable than tampering an existing one. $\endgroup$ Commented Feb 29, 2016 at 13:12
  • $\begingroup$ Now, let's suppose that we have a common scheme: Root (selfsigned) -> Subordinate (signed by root) -> User certificate (signed by the subordinate). If you manage to break any point of the chain, something bad can happen. In the previous comment I addressed the root certificate, and let's ignore the user certificate, since it used SHA-256. If the subordinate certificate signature uses SHA-1 as hash, and you can create a collision for that hash, you can create your own rogue subordinate CA and create valid certificates with it. I would also insist in the legal binding effects that would derive. $\endgroup$ Commented Feb 29, 2016 at 13:21
  • $\begingroup$ "If a way to generate collisions is discovered for SHA-1, it would be theoretically possible to generate a rogue certificate that produces the same hash value"; no, generating another value that hashes to the same as the original root cert is a second preimage attack (unless the attacker gets to specify the root cert as well). That's harder than finding collisions; something that just produces collisions doesn't allow you to do that. $\endgroup$
    – poncho
    Commented Feb 29, 2016 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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