ECDSA 384 Issuance

Does Let's Encrypt issue ECDSA 384 Certificate? If so, is it possible to convert my ECDSA 256 to 384?

"Yes" and "probably".

Although "convert" is probably not the correct phrasing, you'd need to issue a new certificate containing a P-384 key.

1 Like

I think you have some of your digits mixed up, but yes Let's Encrypt supports both P-256 and P-384 keys. Just configure your ACME client to use them. For certbot, use --elliptic-curve secp384r1


Okay. What is there that I need to do different? I am using Amazon Linux 2023.

So, I just run that command and get a new certificate?

Exact instructions depend on how you got your previous cert.

Certbot is a popular command-line client, but there are many other options.


And wheter you should is another question entirely.

The answer is "no, unless you want to pay an enormous performance cost"


What is the motivation to have the more secure cert?


Considering the power of modern CPUs I haven't found that to be a burden.

That should be all the reason anyone needs.


It's not slower. It's massively slower:

$ openssl speed rsa2048 rsa3072 rsa4096 ecdsap256 ecdsap384
Doing 2048 bits private rsa's for 10s: 11046 2048 bits private RSA's in 10.00s
Doing 2048 bits public rsa's for 10s: 375451 2048 bits public RSA's in 10.00s
Doing 3072 bits private rsa's for 10s: 3708 3072 bits private RSA's in 10.00s
Doing 3072 bits public rsa's for 10s: 184340 3072 bits public RSA's in 10.00s
Doing 4096 bits private rsa's for 10s: 1608 4096 bits private RSA's in 10.00s
Doing 4096 bits public rsa's for 10s: 105166 4096 bits public RSA's in 10.00s
Doing 256 bits sign ecdsa's for 10s: 329756 256 bits ECDSA signs in 9.94s
Doing 256 bits verify ecdsa's for 10s: 113849 256 bits ECDSA verify in 10.00s
Doing 384 bits sign ecdsa's for 10s: 9352 384 bits ECDSA signs in 10.00s
Doing 384 bits verify ecdsa's for 10s: 11325 384 bits ECDSA verify in 9.99s
version: 3.0.2
built on: Wed May 24 17:12:55 2023 UTC
options: bn(64,64)
compiler: gcc -fPIC -pthread -m64 -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -ffile-prefix-map=/build/openssl-Z1YLmC/openssl-3.0.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_TLS_SECURITY_LEVEL=2 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_BUILDING_OPENSSL -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2
CPUINFO: OPENSSL_ia32cap=0xfed83203078bffff:0x209c01a9
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.000905s 0.000027s   1104.6  37545.1
rsa 3072 bits 0.002697s 0.000054s    370.8  18434.0
rsa 4096 bits 0.006219s 0.000095s    160.8  10516.6
                              sign    verify    sign/s verify/s
 256 bits ecdsa (nistp256)   0.0000s   0.0001s  33174.6  11384.9
 384 bits ecdsa (nistp384)   0.0011s   0.0009s    935.2   1133.6

I need it for the additional security. It is required. I used certbot for my Amazon Linux 2023 it produced a ECDSA 256. I need it to be ECDSA 384.

I'm gonna go back and change all 348s to 384s - they are making me dizzy! - LOL


--key-type ecdsa --elliptic-curve=secp384r1


as to whether 384 is overkill or not...

LetsEncrypt uses it for its own E1 and X2 signing certificates so apparently someone thought it wasn't overkill


That's a ca/b requirement

And those don't sign that much. There are rate limits for that.

Your clients have to verify those signatures, tho. So using p384 yourself isn't that much of a difference for them. Your webserver might complain.


The poster asked a reasonable question, which has been answered. Please remember to be kind and don't jump on people for the reasonable, supported choices they're making.


At the time the roots were generated/submitted to root programs, there was no requirement to use P-384 root keys (let alone intermediates). I haven't checked the current regs, but the choice to use P-384 was intentional.

There was some discussion about the choice of algorithms back when the hierachy was still being discussed: Let's Encrypt new hierarchy plans

The (major) speed difference between P-256 and P-384 in OpenSSL comes from the fact that OpenSSL ships a highly optimized P-256 implementation, but only offers a generic plain-C implementation for P-384. Mileage with other crypto libraries may differ. A certain drop is expected everywhere though: There's more to compute, and EC H/W acceleration (where available) typically won't go beyond including P-256.

Still much better than a webserver that has to sign 4096-bit RSA :slight_smile:.


I might have misremembered the requirement on the signature algorithm.


I am using Amazon Linux 2023? From what I understand I am supposed to run this and then re-issue a cert using certbot? Command not found?

Also, thank you all for your input. It is much appreciated!

Well, those are the flags to add to a certbot command, but without knowing more about your setup it's hard for people here to give you more specific advice. Can you provide the output of

certbot certificates


certbot --version

And then maybe someone here can assist in how to replace/renew your certificates using a P-384 key.