8

I have heard about the phasing out of SHA-1 based certificates for end entity use, and the steps that are outlined for Google Chrome to display progressively more aggressive warnings for SHA-1 certificates not expiring before Jan 1 2016.

At the bottom of their blog bost, Gradually sunsetting SHA-1, about this, they mention, quote:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

I don't understand the difference here.

Isn't identity proven by the advocate (higher authority) signing a hash of the certificate?

Improve this question

2 Answers 2

Reset to default
16

This is not for "certificates above the end-entity" but for "root certificates" only.

In pure X.509, there is no such thing as a "root certificate". There are certificates, and there are trust anchors. A certificate contains a public key, the name of the entity that owns that key, and is signed by another entity (an "upper certification authority"). This process of signing must start somewhere, and that somewhere is a "trust anchor". A trust anchor is a name and a public key.

X.509 does not specify how any entity should encode trust anchors, since trust anchors are something that is known a priori, not something meant to be exchanged over the network. However, a traditional method of storing trust anchors is to use the same format as certificates. A certificate contains, among other things, a non-optional field for a signature from some upper CA. Instead of defining a new format for a trust anchor, Tradition is to fill the "signature field" with a self-signature. Thus is born a root certificate: a trust anchor that is encoded as a self-signed certificate.

But that self-signature is meaningless ! It has no security value whatsoever. Correspondingly, nobody verifies it(*). Therefore, there is no problem related to its use of a hash function that is otherwise regarded with some suspicion.

(*) Some systems heuristically check that signature because self-signed certificates can only be used as a root, not as anything else. But this is not a security feature; this is for user interface convenience, with no reliance on the safety of that signature. Hence, no problem with SHA-1 or, come what may, MD5 or MD2.

Improve this answer
5
  • Ok that makes complete sense, thankyou. So CA certs between the root and the end entity cert are vulnerable to the same issue as the end entity certs? Therefore the importance of getting rid of SHA1 based certs applies to ALL certs except for root?
    – Breakhty
    Jun 18, 2015 at 14:32
  • 3
    Well, it is not urgent -- SHA-1 is not broken yet -- but yes, if there is a problem with SHA-1 then it is not limited to end-entity certificates.
    – Tom Leek
    Jun 18, 2015 at 14:39
  • Is this tradition something that just happens to be implemented by all browsers, or is it part of e.g. an RFC that signifies that this tradition needs to be followed?
    – Steve
    Jun 18, 2015 at 17:57
  • There is some embryonic standard somewhere, that somehow alludes to the interpretation of a self-signed certificate as a trust anchor, but this is as part of "trust lists" to be used with long-term signatures, and I don't think it is much supported anywhere. The Tradition predates it by at least one decade.
    – Tom Leek
    Jun 18, 2015 at 19:23
  • Okay so if I correctly understand, when I see sha1WithRSAEncryption, it is not the algorithm used to sign descendant certificate but it is the one used to sign the current algorithm. So, as root ca are self signed, it is not relevant. But if a flaw is found one day on RSA, it will be problematic as the public key of a root CA is used to verify the signature of the intermediate CAs
    – Sibwara
    Jan 6, 2020 at 10:53
4

Isn't identity proven by the advocate (higher authority) signing a hash of the certificate?

Root certificates are built into the system (or shipped with the browser). They are the end of the trust chain and there is no higher authority which signed them. They are self-signed, but only because there has to be some signature. The signature does not need to be checked and thus the security of the signature hash does not matter.

In other words: the trust of leaf and chain certificates is based on the trust into the signer and is expressed by the signature. It is necessary that this trust can not be spoofed, i.e use SHA-256 instead of SHA-1. For a self-signed certificates this would mean the trust in itself. It does not matter how hard somebody trusts himself, it only matters how much others trust him (i.e. builtin certificate means full trust).

Please note that trust in this case only means the trust that somebody issued a certificate. It does not mean how safe a site is. Hackers can also easily get certificates!

Improve this answer

You must log in to answer this question.

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