Status of and instructions for EC certification generation using CertBot?

Using certbot, I can generate certs using standalone/webroot with no issues.

Afaict from the docs page (, there’s no option for EC cert signing. I can of course get rsa certs with various key sizes (–rsa-key-size )


It states both

ECDSA Intermediates

    ETA: Before March 31, 2017

Let’s Encrypt only signs end-entity certificates with RSA intermediates. We will add the ability to have end-entity certs signed by an ECDSA intermediate.


ECDSA Signing Support

    Enabled: February 10, 2016

Added the ability for Let’s Encrypt to sign ECDSA keys with Let’s Encrypt’s RSA intermediates. Support for signing ECDSA keys with a full ECDSA cert chain will be added later.

And here

ECDSA testing on staging
    If I remember correctly, you can use ECDSA keys using the --csr flag, but not in any mode where certbot generates the certificate for you

All suggest it’s already doable, but not in automated fashion.

Is that still the case? That certbot automation does NOT support automated generation/retrieval of ECDSA SignatureAlgorithm certs?

Is there current documentation on howto best generate ECDSA certs?

I do not know if there is a nice guide somewhere, here is what I did to get it working:

Generate the private key:

openssl ecparam -genkey -name secp384r1 > privkey.pem

Generate a certificate signing request:

openssl req -new -sha384 -key privkey.pem -subj "/" -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\")) -outform der -out csr.der

Check the certificate request:

openssl req -inform der -in csr.der -noout -text

And send it to letsencrypt:

./letsencrypt-auto certonly --text --agree-tos --email --csr csr.der --webroot --webroot-map '{"": "/var/www/html"}'

Not pretty, but it works. Yes, I should probably switch to certbot, but I chose to post what I use.

So no built-into-certbot support yet? That’s still a question for me.

Your instructions help, thanks.

I do get cert & chain generated.

Not yet sure whether the chain == the “fullchain.pem” that certbot generates.

Also missing the nicety of the generated symlinks to {cert,key,fullchain,chain}.pem


looks like *2 chains are generated

0000_chain.pem --> chain.pem
0001_chain.pem --> fullchain.pem

I have worked on including EC leaf certificates for certbot, but there is some delay because as of yet, you can only choose one algorithm: your cert.pem is either RSA or ECDSA. Not two certificates at the same time. And there's discussion about how to implement both RSA and ECDSA, but there isn't a decision yet.

So for ECDSA leaf certificates you'll have to be patient I'm afraid.

Just thinking out loud …

If we were voting, and I understand we’re not, I’d personally much rather have an ESDSA-only, automated certbot option now – and wait for eventual 2-cert-type support than have no option.

That’d simply prevent the effort – I’m sure it’s being done & re-done – by users to manually script the ECDSA generation, installation, updating, etc.

That & alternative-port support for --standalone would certainly speed up our (clients’) roll-out/adoption.

I suspect the concern is that for every smart, capable person like you who thinks it’s annoying to need to knock up a CSR to get this to work, there will turn out to be ten, or more, who think ECDSA sounds modern and exciting and don’t realise there’s any downside to just picking it instead of RSA.

Right now a noticeable fraction of questions on this site end up being about non-certificate crypto choices that have made their site unexpectedly worse than they anticipated. They have switched off TLS < 1.2 and now Windows XP doesn’t work, they disabled most of the cipher suites, or they enabled HSTS then wanted to go back to plaintext HTTP.

Some of those people (and it doesn’t have to be lots to flood this place) will say to themselves “Ooh, ECDSA, that’s cool” and won’t go “I bet that has poorer compatibility and I shouldn’t deploy it for my site”. And then they’ll write confusing questions like “Why doesn’t site work for friend in Canada?” because they don’t know they mean “I enabled ECDSA and that doesn’t work with my friend’s archaic Amiga web browser” or whatever. So for that reason I understand cerbot’s caution.

It ends up being a race between delivering dual-certificate options and the most incompatible older browsers naturally dying out. We don’t worry about stuff that can’t work with Windows 95 for example, and we stopped worrying about servers that can’t do SNI (they still exist, but nobody is offering bulk hosting with them or anything like that).

By the way you can have alternate port support today IF you are redirecting somewhere to the right port number, for example you have a symmetric NAT or some load balancer setup that can’t work with the default port on the servers. The chances of getting non-default ports permitted for the actual remote validation step is almost nil. Google’s fairly influential rep to the CA/B forum thinks that’s an awful idea because of how easy it will be for some minor employee to start up an unnoticed server on an obscure port and get certificates issued, which violates the principle of least surprise for the domain’s owner. If anything more gets OK’d, expect it to be port 25 somehow.


5 posts were split to a new topic: CA/Browser Forum Ballot 169 (Domain Validation methods)

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