Getting dual RSA and ECC certs with certbot


I’ve found numerous resources that show how to get ECC certs with LE, but as far as I can see they do not integrate with certbot (requiring multiple manual openssl commands instead) and cause problems with auto-renew etc. By default certbot manages key creation and CSR generation, but with ECC it appears I have to create keys manually and generate a CSR manually too. What’s more, it also breaks getting RSA certs as well, because if I use the --csr option to specify a custom CSR, that is signed by only one key, either RSA or ECC, which won’t match the other cert type, and LE will not let me make multiple requests for the same cert in a short period (especially if the domains in the cert do not change). Is there a guide somewhere that shows an optimal config of how to use dual keys and CSRs with certbot without reverting to doing everything manually?


The rate limit is 5 certificates for the same set of names per week. You can issue two – or five – simultaneously, if you like.

I usually use Certbot, but if you want ECDSA, the easiest option is probably a different client with first class ECDSA support. (Until Certbot gets it too, anyway.)

There are probably a number of good clients with good ECDSA support, but the one i use is It makes ECDSA and RSA equally easy to use, though i don’t think it has special support for dual certificates. (In other words, you’d have to run the command twice, once with ECDSA and once with RSA. But that’s easy enough.)


I agree with @mnordhoff’s suggestion for the time being. We’re having some design meetings about improving the support in Certbot for dual-mode keys, but these changes are still a ways off.

I don’t think Let’s Encrypt should actually stop you from making a second request for a second key type; there’s no rate limit that should be preventing this (including using Certbot). If you continue having trouble with that, maybe you can share some more details and we can try to figure out what the problem is.


Thanks for the pointers. does look like a better solution for this. I’m concerned that given two requests for the same domain, it might overwrite the previous cert (I’ve not seen anything to suggest it uses the key type to generate a different save path, though I’ve not tried it yet), leading me into a whole can of worms in moving files between requests, which complicates renewals etc.


If you use --csr then you don’t get a certificate saved in /etc/letsencrypt at all.

However, apart from that, there is an option --duplicate which means that a fresh certificate lineage should be created in /etc/letsencrypt even if the domains in the certificate are apparently duplicates of those in an existing one.



Is there a feature request for ECC Support in Certbot?

With IoT Devices I prefer to use ECC Certs as they are smaller and tend to have less processing overhead

I am using a client that has these or creating my own CSRs but there are good reasons why it might be bumped.

Could this be something potentially volunteers can contribute?

@Synchro there are a few clients which support ECC certs and run on linux. First 5 certificates managed are free.



There are definitely a number of feature requests for improved ECC support in Certbot, and we’re working on it!


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