Creating parallel ECDSA & RSA keys -- same CSR, just with add'l cmmd line params? or NEW, re-keyed csr?


#1

Taking a tangent from the discussion from Status of and instructions for EC certification generation using CertBot?

Iiuc, there’s certainly no reason I can’t create two certs manually.

If I’ve created an elliptical privkey

openssl ecparam -genkey -name secp384r1 -noout -out my.privkey.pem

I know I can generate the CSR for ec cert generation using it

openssl req -new -sha512 -nodes -key my.privkey.pem ... -outform der -out example.com.csr.der

to submit to LE as

certbot-auto certonly --server <prod CA> --standalone --standalone-supported-challenges tls-sni-01 --csr=example.com.csr.der

To generate a 2nd, but RSA, key do I simply RESUBMIT to LE with the same CSR, but add the ‘rsa-key-size’?

certbot-auto certonly --server <prod CA> --standalone --standalone-supported-challenges tls-sni-01 --csr=example.com.csr.der --rsa-key-size 2048

Or do I need to regenerate a NEW csr, with a new/2nd RSA privkey, submitting with THAT, new-generated csr

certbot-auto certonly --server <prod CA> --standalone --standalone-supported-challenges tls-sni-01 --csr=example.com.RSA-keyd.csr.der --rsa-key-size 2048

?


#2

When you use a CSR, Certbot has no idea about your private keys at all. That’s (one of) the purpose of CSRs, they prove whoever made this request knows the private key, but they don’t contain it or substitute for it.

So, you need an RSA private key, otherwise there won’t be an RSA public key and the certificate is essentially two things bundled together (your identity + a public key, in this case an RSA public key) then signed by the CA to say they believe this identity really controls the corresponding private key.

I have no idea what would happen if you hand over a CSR for a Elliptic Curve public key, and then say you want to choose RSA key size, but if it’s not just an error (as I expect) then I doubt it will be good.


#3

TBH, I’d never considered that it’s my privkey in the SSL cert that’s defining the SSL cert algo; just frankly never looked. I thought it was my key stating my identity, and locking down the CSR, and the resulting CERT and the algo that it was signed with that defined the SSL algo use in the browser<->client comms.

So two privkeys – one RSA for generating the RSA cert, and one EC for generating the EC cert.

I think that means I have to be twice as careful in not exceeding the LE RateLimits. If all’s working as it should, that won’t normally/eventually be a problem.


#4

Not your privkey in the cert. Public key in the cert. Very important not to get those muddled :slight_smile: Nobody needs your private key except you (and your web server or whatever). Nobody. Not me, not even Let’s Encrypt.

A certificate will have a public key in it belonging to the subject (that’s you / your web server) and that public key could be RSA or ECDSA. The subject knows a private key that corresponds to this public key, but nobody else does.

The certificate also needs to be signed, by the issuer (that’s Let’s Encrypt in this case) and that signature uses RSA or ECDSA too, plus it needs a cryptographic hash - which at the moment will be SHA-256 - because public key algorithms work on numbers, and a whole certificate is too big a number to process easily, so they use the algorithm on the 256-bit hash value instead.

Today Let’s Encrypt only ever sign things using the RSA algorithm. But they are willing to sign either an ECDSA or RSA key in your certificate. Then a web browser (for example) can use the ECDSA key, if that’s what is in the certificate, to secure a connection to your server, even though it needs to use the RSA algorithm to check that your certificate is genuinely from Let’s Encrypt.


#5

Not your privkey

oops, typo.

not to get those muddled

indeed

Today Let’s Encrypt only ever sign things using RSA

iirc, 2017 for ECDSA sigining?

web browser (for example) can use the ECDSA key, if that’s what is in the certificate, to secure a connection to your server, even though it needs to use the RSA algorithm to check that your certificate is genuinely from Let’s Encrypt.

I’m chasing after the speed/security of the ECDSA, with an RSA fallback for the persistently antiquated (maybe …)

What’s “in” the cert & used for the comms after the RSA verification, then, is the algo defined by my key pair.

That clears it up. Thanks.


#6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.