ECC Certificates?


Do you support ECC certificates? If you support them, how can I generate one? If not, are there any plans to add it? I already found a post about it, but it’s from 2015 and it’s closed since 2016, so I’ll ask it again now.

ECC certificates are supported by the CA, but not by all client software. I don’t think Certbot supports them yet (?) but I’ve successfully obtained ECC certificates with by following these instructions.

An example post that describes this and also uses such a certificate on the site itself is at

Maybe the thread you saw was this one?

It seems like some people in that thread were successful at the time. As @jmorahan says, you might not be able to do it easily with every client application. (I believe in Certbot you still need to use an externally-generated CSR in order to get such a certificate, for example.)

Yes, it was. I didn’t read it all, just read some posts of it, as it’s too long.

Every imporant desktop client supports it and I don’t think it will be that on serverside. You’re marked as a “Certbot Engineer”. Do you know anything about plans of an implementation in certbot?

1 Like

ECC should be the default.

[EDIT] what I meant is RSA is still the default - but I am all for replacing it with ECC.
ECC is much smaller thus faster too.

I tested it on a letsencrypt certificate and it is using RSA. But the ceritificate is already some months old. Is it new?

ALSO: Are there any plans to sign with an ECC root and chain?

I would ask @bmw about the status of ECC support in Certbot.

No, it’s not new. But most or all clients probably default to RSA.

Yes. The current ETA is March; there’s a lot of red tape involved.


For future-people looking at this thread, here’s how to make certbot use ECC keys:

First, generate an ECC key

openssl ecparam -out privkey.pem -name prime256v1 -genkey

Make a req.conf file with contents like so (things you need to replace are in `<angle brackets>`)
[ req ]
prompt = no
encrypt_key = no
distinguished_name = req_distinguished_name
req_extensions = req_ext

[ req_distinguished_name ]
CN = <first domain>

[ req_ext ]
subjectAltName = DNS: <first domain>, DNS: <second domain>

The subjectAltName fields just holds as many domains as you want to issue for, just like multiple -d flags on Certbot. With Certbot, the first -d flag is the “first domain” in my example. It doesn’t actually matter which is first.

Then, generate a CSR

openssl req -new -key privkey.pem -out req.csr -sha256 -config req.conf

Finally, generate the certificate

certbot certonly --csr req.csr --webroot -w <web root for first domain> -d <first domain> -w <web root for second domain> -d <second domain>

1 Like

One thing some people don’t realize at first is that certbot renew isn’t able to renew certificates that were created using an external CSR. Therefore, people who use this path will need to find another solution for automated or manual renewal before their certificates expire.


Huh, that makes sense, definitely good to know! Will subsequent uses of certonly with a CSR like this continue the same lineage, or start a new one with each renewal?

It doesn’t create a lineage at all. It just places the files in the current directory. (Edit: Or elsewhere, if you pass the right options, I think.)

--csr is really barebones.

1 Like

Unfortunately, support for ECC certificates in Certbot is blocked on me and I’m currently working on other things that have a stricter deadline. I hope to get to it in the next ~3 months, but basically I need to design how we will store ECC certificates on disk, if we will do anything to differentiate them from RSA certs to avoid confusion, and how we will support installing dual RSA/ECC certificates. The issue has been a bit contentious, but you read more about it and watch its progress at


My branch of that pull request could be used as a very not official and outdated version of certbot with ECC support.

I haven’t merged any further updates of the master branch because of a new job with a lot less spare time, but the current version of my branch should be stable. (Although lacking new features and bug fixes.)


For this, there are several examples of scripts online which can help with automatic renewal. I implemented dual certificates (ECC and RSA) for my domains, and have them setup to auto renew with a systemd timer.

If anyone’s interested, I’ve put my version in a gist here. That config and the setup instructions from @jared.m should be enough to get automatic ECC/RSA renewal working.


I did some tests with letsencrypt certificates. The public/private key is rsa, but the exchange is made via ECDHE, how is this possible?

You might be conflating the algorithms used for authentication with the ones used for key agreement.

During a TLS handshake, the certificate algorithm, usually RSA or ECDSA, is usually only used to authenticate the server, and sometimes the client, in cases of client certificate authentication. The actual symmetric key algorithm used to encrypt the connection would be negotiated using a key exchange or key agreement protocol, usually Diffie-Hellman or Elliptic Curve Diffie-Hellman. There are multiple cryptographic algorithms in use during various parts of the connection. A particular combination is referred to as a cipher suite.

For a particular example, the TLS connection between my browser (Firefox) and this forum:

Connection Encrypted (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2)

That breaks down into a few basic sections:

For more info on TLS cipher suites, I’d refer you to the TLS 1.2 RFC (RFC5246) and for more info on the Elliptic Curve Diffie-Hellman portion, I refer you to the TLS ECC RFC (RFC4492).


The Diffie-Hellman key exchange usually doesn’t involve public/private keys. That’s why ECDH is perfectly possible with non-ECC keys.

The bot I wrote, acmebot handles both RSA and ECDSA (ECC) certificates in parallel (i.e. you get both kinds of certificate by default), among a handful of other features useful in advanced setups. Note that it doesn’t modify your server configuration.