Confusion with Azure Cloud Service SHA1 and SHA256 Certificates
This came up on a camp I ran yesterday. Somebody noticed in Visual Studio, that the algorithm used for the certificate thumbprint is SHA1. There isn’t an option to change it to SHA256. And all recent advice about SHA1 is to avoid using it and use SHA256.
Figure 1: The Certificates tab in Visual Studio.
Figure 2: If you drill in to the underlying file, you get only one option – SHA1:
Well, you can relax. This has nothing to do with making the security of any data transmission less secure, or with validating the data, the certificate or any key material.
Over the years, various encryption and hashing algorithms have been found to have weaknesses and subsequently security experts have recommended using more modern, more secure equivalents. That’s where we are with SHA1 and SHA256.
But that is dealing with all the crypto material inside the certificate. The thumbprint is essentially a moniker for the name of the certificate. In the same way that I have a couple of names that people use to identify me. I will respond to either “Steve” or (more usually) “Planky”. You can do the same thing with certificates. You could use maybe the Subject field to identify a certificate. Maybe the CN (Common Name). Maybe some concatenation of the 2 fields. Some other field maybe.
In a certificate store on a computer, you could have 2 certificates with the same subject name. It’d be like walking in to a room and saying “Steve?” and hitting a momentary period of confusion as both me and my colleague, Steve, say “Yes?”.
That’s no good in the world of computing. So you need a way of absolutely identifying the certificate you want to use. It’s a little bit like the way my thumbprint exactly identifies me and nobody else in the world (as far as we know). That’s what the thumbprint of a certificate is.
It’s not a value that is stored inside the certificate. It’s a calculated value. What happens is that all the binary data that makes up the certificate is run through an algorithm and it produces a value. It gets run through the SHA1 algorithm. SHA1 is a hashing algorithm. That means you can put a string of data in to it and you get a fixed length string out of it. It produces a 160-bit value. That gives you a 40 character hexadecimal value. Look at the value in figure 2 above (and figure 3 below) and you can see the hexadecimal representation of that 160 bit value.
Figure 3: SHA1 certificate thumbprint
So, when you want to use a certificate in your Azure Cloud Service you’ve got 2 things to do. One is to upload the certificate, so it ends up in the certificate store of the machine(s) your cloud service is running on. The other job is to tell the machine which certificate you want to use. The machine has a pretty wide choice of certificates in its certificate store. You want to be sure it selects the right one. You do this by identifying the certificate with its thumbprint.
What will happen is when your app passes over the thumbprint from the .cscfg file, the system will go through every certificate in its store and find one with a thumbprint that matches the one you are talking about in the .cscfg.
How does the machine know the thumbprints of all the certificates in its certificate store if it’s not a value that is contained in the certificate? It calculates it. It simply runs the naked binary data of each cert through the SHA1 algorithm (as shown in figure 3 above) and look for a value that matches. If it finds one, then it’s got the right certificate.
The algorithm used for the thumbprint has now done its job. All the crypto material inside the certificate will be used to protect any data you transfer to and from the server. So – when you see sha1 in the .cscfg for the certificate thumbprint, you don’t have to worry that your website/app/data is insecure, it’s simply using it as a way of identifying the certificateit wants to use…
Have fun – and relax, a SHA1 cert thumbprint is not going to compromise your system security….