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 acme.sh 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?
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>
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.
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 https://github.com/certbot/certbot/pull/2660.
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.
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:
- ECDHE - The session key was negotiated using Elliptic Curve Diffie-Hellman key exchange.
- RSA - The public key algorithm used to authenticate the server, matches the certificate algorithm.
- AES_128_GCM - The symmetric cipher of the session key used to encrypt the traffic.
- SHA256 - The hash algorithm used to ensure data integrity.
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.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.