The guide I\'m following says to use openssl genrsa to generate a TLS key, which
ID: 658007 • Letter: T
Question
The guide I'm following says to use openssl genrsa to generate a TLS key, which I did. I've changed the CSR generation command to use SHA256 instead of SHA1, but I'm still not sure if this is the optimal solution.
The oldest clients I would like to support are Windows XP with SP3 (cries) and Android 2.3 (preferably, but I don't really need this), or if that causes serious pain, Android 4.0.
What is the optimal key type for this? I'm assuming RSA, but ECDSA keys look nice too (except for compat problems).
Explanation / Answer
Everybody uses RSA. If you stick to RSA, you certificate should be acceptable everywhere. Use a 2048-bit key size. ECDSA is nifty and very hipster, but won't work everywhere yet.
A RSA key is a RSA key. However, a certificate is also a signed object, and a signature algorithm begins with some hashing. Thus, a certificate will contain references to a hash function. Some modern browsers have apparently decided to scream and wail and shout when they see "SHA-1" in a certificate; therefore, to avoid dropping out of fashion, you need to use SHA-256. This should work on XP since SP3 (but not before). Take care that this is about the signature on the certificate, so really it is the problem of the Certification Authority that signs your certificate.
Whether you sign your certificate request with SHA-1 or SHA-256 as supporting hash function, should not matter. The CA extracts the public key from your request, pushes it in the new certificate, and then will use SHA-1 or SHA-256 depending on its configuration, regardless of what you used yourself to sign the request. At least that is how CA are supposed to work; some CA do weird things at times.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.