14

I was playing a little bit with signature algorithms, trying to determine which CAs among the ones I use are currently issuing SHA2 certificates.

I generated a CSR specifying the SHA256 hash (either using gnutls-certtool with the hash param and openssl req with the -sha256 param) and the CSR is clearly displaying sha256WithRSAEncryption as the signature algorithm.

$ openssl req -noout -text -in test.csr

Certificate Request:
    ...
    Signature Algorithm: sha256WithRSAEncryption
        ...

However, the resulted certificate from the CA is hashed with sha1WithRSAEncryption.

$ openssl x509 -noout -text -in test.crt

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: ... (...)
        Signature Algorithm: sha1WithRSAEncryption

Of course, generating a CSR with --hash SHA1 (sha1WithRSAEncryption hash) will cause the resulting certificate to use sha1WithRSAEncryption (as expected).

The CA states that the hash should be specified as part of the order, not of the CSR (which is something I can't do in any case given I'm submitting the order via a third party service).

Hence the question. Should the CA obey to the hash algorithm specified in the CSR?

  • Should they? Probably (though I would need to search for the relevant RFCs). On the other hand, it seems to be common practice for CA's to ignore almost everything in a CSR besides your public key. – lzam Sep 11 '14 at 1:19
  • You might find this study and associated source code interesting. eff.org/observatory – zedman9991 Sep 11 '14 at 12:46
14

The signature algorithm specified when creating the CSR corresponds to the message digest used to sign the request itself, it is not intented to ask the CA to prefer that algorithm when signing your certificate.

The MD used in the CSR establishes the level of confidence in your request, but does not imply what algorithm is used on the certificate since signing does not depend on that digest but on the public key.

Most CA stick to the same algorithm for a specific issuing certificate unless it were discovered to be "weak", ignoring what message digest you used in your request.

A good CA would reject any CSR signed with MD5 (for precaution since they shouldn't trust you), and should be forcing you to use SHA256 for any certificate you pretend to use for more than two years starting today (2014), since Microsoft (and maybe others) will be rejecting certificates signed with SHA-1 or lower on January 2017.

  • 1
    To further build on this, the signature algorithm choice is part of the certificate authority's security, not yours. Let's say you said CRC-32. Their certificates could then be manipulated and horribly misused. Also, if you can't trust them to choose an appropriately strong algorithm, why would you trust them at all? – John Deters Sep 11 '14 at 17:20
1

From my experience, CAs do have their own settings and they are often not willing (or are not able at all, because it is wired into their software) to change anything in it. I´m talking about mandatory Subject fields, key usage, extended key usage, ...

For example you would like to have L, ST, C in the Subject, but CA will cut is off and you get hte certificate only with C=county. Or you submit a simple .csr and you get certificate with special extended key usages, like Client Authentication (1.3.6.1.5.5.7.3.2) and Server Authentication (1.3.6.1.5.5.7.3.1). And many times you get also SAN equal to CN, free of charge.

If you want to have the certificate signed with sha1 or sha256, you should ask the RA=registration authority. RA sends the actual request to the CA and can set up the settings, including used hashing algorithm.

CAs use the signature in .csr file only to verify that you own the private key, nothing else.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.