I've heard conflicting statements about this from certificate authorities and security groups and would like to confirm: Is a SHA-256 signature required on a CSR in order to generate a signed certificate with SHA-256 signature?
I thought it wasn't a requirement but can't find anything to definitively confirm one way or the other.
There is no technical reason that would prevent a CA from issuing a certificate with a SHA-256 signature, even if the CSR was signed by the requestor using some weaker signature algorithm.
The purpose of the signature in the CSR by the requestor is to prevent someone from requesting a bogus certificate containing someone else's public key. It is the responsibility of the CA to verify the signature in the CSR (signed by the requestor using the private key corresponding to the public key contained in the CSR), using the public key contained in the CSR. Assuming that the signature is verified, the CA then goes ahead and produces a certificate containing the relevant information from the CSR (e.g. the common name, public key, etc), and then signs the certificate using their own private key, using whatever signature algorithm that they choose (usually SHA-256 nowadays). Of course, the CA could reject the request if they feel that the signature algorithm used by the requestor to sign the CSR was not strong enough, but that would be at their discretion. But as you can see, there is nothing that would prevent the CA from issuing a certificate and signing it with a SHA-256 signature, so long as they were satisfied with the signature by the requestor in the CSR.
I thought it wasn't a requirement but can't find anything to definitively confirm one way or the other.
No. This is not a technical requirement. CAs can do what they want. They can issue you a cert if you submit your data written on the back of a bar napkin if they choose. There's nothing technical to stop them.
Is a SHA-256 signature required on a CSR in order to generate a signed certificate with SHA-256 signature?
No. Meanwhile most CAs default to SHA-2-family-type hashes anyway and you actually have to specifically state that you want a SHA1 cert instead.
But about a year ago this question generated a lot of confusion.
According to helpful, but terribly named, website
https://shaaaaaaaaaaaaa.com/
there is indeed one CA:
- Gandi now uses SHA-2 for certificates expiring after January 1 2017. For certificates expiring before that, you have to generate a CSR yourself with SHA-2.
And indeed, that CA website says:
Until 1 January 2016:
Certificates with an expiration date after 1 January 2017 will be issued as SHA-2 only, even if the CSR was generated with SHA-1.
Certificates with earlier expiration dates will be issued as SHA-1 if the CSR was generated with SHA-1
Certificates with earlier expiration dates will be issued as SHA-2 if the CSR was generated with SHA-2
Q: Why do they do that?
A: Again, no technical reason. It's just a more a less useful convention/organisational thing for them. I guess this is somewhat similar to this hypothetical idea: if you want to apply for a Green Card to work in the US, you might be asked to submit your application on a green sheet of paper. Nothing technical about that. Pure organizational process. It's just one bit of data (SHA2? ON/OFF) that would otherwise have to be transferred in a different way. (Say via like a checkbox on the website.)
