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.
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.
Not your privkey in the cert. Public key in the cert. Very important not to get those muddled 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.
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.
Nobody needs your private key except you (and your web server or whatever). Nobody. Not me, not even Let’s Encrypt.