Does the certificate offer a SHA-2 signature?

1

I have a co-located domain which only has a SHA-1 certificate. I’m trying to get my host to upgrade it. When I asked about SHA-256 they said:

"First of all I would like to let you know that we do support SHA-2
signature for SSL certificates. Upon checking your account, I noticed
that you don’t have any SSL product at the moment. "

Because I have only small websites that do not generate me any revenue, I’m trying to use one of the Let’s Encrypt certificates which are free. However, my host only supports SHA-2 apparently. This is what they said:

“I’d only like to draw your attention to the fact that in this case you will have to verify with the SSL provider you choose whether they offer SHA-2 signature or not. And regarding your initial question: yes, you may install such a certificate to our server.”

2

Let’s Encrypt uses SHA-256 hashes in it’s certificates and SHA-256 is one of the SHA-2 hash family variants.

1 Like
3

There is currently no CA that over new SHA1 certificates. There is an request by two company that
the get “Legacy Validated” SHA1 that they only deliver to old clients.

1 Like
4

one Idea would be to make the “primary signature of those as sha1” but to add an extra field that contains a sha256 sig, would be great so you can serve old and new clients alike, assuming they would support that.

5

The CA/Browser Forum would need to agree on a solution. If you start changing the format, it will also break current clients that work fine and would have issues with a whole new format. Those browsers either would fail to parse correctly or just see only the SHA1 signature because they wouldn’t know where to look for the “new” signature. Basically, it would be a much bigger mess than currently.

6

well you cant really serve 2 certs at once and basically a new field shiouldnt be a problem, I saw enough certs with unknown fields.

true that there might be some time till the browsers see the 2nd sig, but better than nothing

7

But in theory it should be possible to choose the certificate based on an analysis of the ClientHello. For example, the supported client cipher suits.. ClientHello profiling should be able to detect old clients and a webserver could be able to serve another certificate based on that.
That said, I haven't found anything like that in Apache :stuck_out_tongue:

8

Hi, this is what i do on my domain. If i receive an unknown FQDN i generate an new “self” signed cert with the best option. Mean prever EC over RSA and selected the curve based on the available list.

It is part of what the company prefer for LV but not simply say if the client can only anounce no SHA1 but based on fingerprint only for known client hello’s.

Adding an new field for SHA1+SHA2 is stupid.

  1. The signate is not extension so the default must be at an given place. Since all current client only check this possition, CA/B would never accept there SHA1 and place SHA1 as an extension is no value too since we need this only for clients that are no longer developed and so will not implement it.
9

If multiple signature types were supported from early on, then we wouldn’t be having as much problem with offering multiple signature types.

10

I can’t help but feel that would be a bigger mess as then certain software would only support certain signature types.

11

Since yesterday no body can say “Let’s use SHA1” :slight_smile:

There are an algorithm that can (after 9,223,372,036,854,775,808 SHA1 computations) corrupt your SHA1. See complete article at shattered.io.

At this momente the most used is SHA256 of the SHA2 family.

12

Indeed, the techniques that were used in the new collision result were described over the course of years (including by some of the people who worked on achieving it), so hopefully nobody has been saying this for some time!