Why Your SSL Certificate Still Has A SHA-1 Thumbprint
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)

Why Your SSL Certificate Still Has A SHA-1 Thumbprint

Thumbprints are not Signatures.

If you worked with SSL in 2015, you may still have battle scars from the SHA Transition—where the entire SSL industry abandoned the SHA-1 algorithm in a major technological update. So it may worry you to see “SHA-1” still listed beside your SSL certificate’s thumbprint. But there is no need to panic – thumbprints are not related to your certificate’s security, and your certificate is 100% compliant with industry standards.

And, if you have no idea what I am talking about – don’t worry, I will catch you up.

ThumbprintsWhen you view an SSL certificate you will see a number of fields. Each field contains data about the certificate which computers and devices use to process and understand the information within. To a human, some of the fields are straightforward – such as the “Validity” field, which tells you the date range that the certificate is valid for. But most of the other fields are of little value to the average user.

One field that can be immensely useful, but is often misunderstood, is the “Thumbprint.”

A certificate thumbprint is similar to a human thumbprint – it’s a unique identifier that no other certificate should have.

In the screenshot to the right, we are looking at a certificate in Window’s certificate viewer that is showing its thumbprint. It will always be a seemingly random string of numbers and letters. Every certificate has a thumbprint, it’s the result of a mathematical algorithm – known as a hashing algorithm – that is run against the certificate’s data.

Because different certificates can share the same field data, the thumbprint is useful for uniquely identifying a certificate. You can use a thumbprint to compare multiple certificates and determine if they are copies of the same file, or if they are unique.

So, if thumbprints are so useful, why are they also so problematic?

It has to do with that hashing algorithm I introduced before. In 2015, the entire SSL industry went through a technological upgrade where it moved from SHA-1, to a newer hashing algorithm known as SHA-2.

But this had nothing to do with thumbprints.

SSL Certificates use the same hashing algorithms for their “signature.” Signatures are similar, conceptually, to thumbprints: they are used to identify certificates. However they differ in a very important way: Signatures are a cryptographic security measure. When a computer receives a certificate, it checks the signature to make sure it is legitimate, and not a forgery. Every certificate will have a verifiable signature that proves its authenticity

The SHA-1 algorithm has structural flaws that can’t be fixed, so it’s no longer acceptable to use SHA-1 for cryptographic signatures. Security researchers have shown that SHA-1 can produce the same value for different files, which would allow someone to make a fraudulent certificate that appears real. So SHA-1 signatures are a big no-no.

While signatures are used for security, thumbprints are not. Remember, thumbprints are just for reference.

Here we can see an excerpt of a certificate’s details showing both. The signature algorithm is using SHA-256 (or, SHA-2 as we usually say for short); which is compliant with current industry security standards and web browser requirements.


The thumbprint and signature are entirely unrelated. In fact – the thumbprint is not actually a part of the certificate. It’s calculated and displayed for your reference.[1] If you are using Windows, you will see the “thumbprint algorithm” listed as SHA-1 because this just happens to be the hashing algorithm that Windows uses.

So, to summarize: SHA1 thumbprints are okay. SHA 1 signatures are not.

If you are inspecting a certificate and want to make sure it has a SHA-2 signature – which modern browsers require – make sure you look at the “Signature algorithm” field.  If you ordered your certificate in 2016, then your certificate will use SHA-2, due to new industry regulations which bar SHA-1.

[1] http://morgansimonsen.com/2013/04/16/understanding-x-509-digital-certificate-thumbprints/

  • Understood. Why are not changing SHA-2 for thumbprints too ? Always supposed to go with latest technology. am i right ?

  • Hi,
    Excellent write ups BTW.
    So any idea why chrome fails for Internal self-signed CAs. As now I understand that Thumbprint algorithm sha1 is not my issue. My internal CARoot works for IE, Firefox, Safari but not Chrome. I’ve generated my certs-keychain with sha256. I can get around this problem by to allowing the sha1 in Chrome (EnableSha1ForLocalAnchors) , I read your article below as well. This is frustrating should I just give up the goat on chrome and keep doing what I did above.

  • Seems like in order to remove SHA1 entirely from the available options the thumbprint must also change regardless of whether it is exploitable…

  • So the article says this about a SHA-1 thumbprint: “it’s a unique identifier that no other certificate should have.” But then it says security researches have shown that SHA-1 can produce the same value for different files. So how can we trust that thumbprints are unique? Why not just change the thumbprint algorithm to a secure one?

  • My internal .CA issues SHA1 to PCs and servers.
    I am going to move to SHA2 and install new certs to server. In this case, servers will have SHA256 certs.
    Can PCs still use SHA1

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *