Every SSL/TLS certificate contains a public key, usually either RSA or ECDSA (elliptic curve). Both are secure at recommended sizes, but ECDSA keys are much smaller and faster for the server. This guide compares ECDSA vs RSA certificates and shows how to use them.
Before you start
- A Linux server with Nginx or Apache and Certbot (or another ACME client).
- On shared cPanel hosting, AutoSSL chooses the key type; this guide is for servers you manage.
RSA vs ECDSA compared
| RSA 2048 | RSA 3072/4096 | ECDSA P-256 | ECDSA P-384 | |
|---|---|---|---|---|
| Approx. security level | ~112-bit | ~128 / ~140-bit | ~128-bit | ~192-bit |
| Public key size | 256 bytes | 384–512 bytes | 64 bytes | 96 bytes |
| Server signing cost | Moderate | High | Low | Low–moderate |
| Client compatibility | Universal | Universal | All modern clients | All modern clients |
In a TLS handshake the server signs with its private key. ECDSA signing is much cheaper than RSA at comparable strength, which helps busy servers, and smaller certificates mean smaller handshakes.
Which should you use?
- ECDSA P-256 is a strong default for modern websites and APIs.
- RSA 2048 remains fine and is still needed for some very old clients and embedded devices.
- Both (dual certificates) gives ECDSA to modern clients and RSA to legacy ones.
Issue certificates with Certbot
- ECDSA (default in recent Certbot versions):
sudo certbot certonly --webroot -w /var/www/example.com -d example.com --key-type ecdsa --elliptic-curve secp256r1 --cert-name example.com-ecdsa - RSA:
sudo certbot certonly --webroot -w /var/www/example.com -d example.com --key-type rsa --rsa-key-size 2048 --cert-name example.com-rsa
Check a certificate's key type with openssl x509 -in cert.pem -noout -text | grep 'Public Key Algorithm'.
Serve both on Nginx
ssl_certificate /etc/letsencrypt/live/example.com-ecdsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com-ecdsa/privkey.pem;
ssl_certificate /etc/letsencrypt/live/example.com-rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com-rsa/privkey.pem;Nginx picks the certificate matching what each client supports. Include ECDSA cipher suites (ECDHE-ECDSA-...) in ssl_ciphers if you set a custom list.
Serve both on Apache
Add two pairs of SSLCertificateFile and SSLCertificateKeyFile lines in the virtual host – one for each key type. Apache 2.4 with OpenSSL selects the appropriate one per client.
What to check afterwards
- Force ECDSA:
openssl s_client -connect example.com:443 -sigalgs ECDSA+SHA256– look for the server's certificate key type. - Force RSA: repeat with
-sigalgs RSA-PSS+SHA256:RSA+SHA256. - Confirm both renew:
sudo certbot renew --dry-run.
Troubleshooting
- Old devices fail to connect: they may not support ECDSA – add an RSA certificate.
- Handshake errors after adding ECDSA: your cipher list contains only
ECDHE-RSAsuites. - Wrong certificate renewed: keep distinct
--cert-namevalues for each key type.
FAQ: ECDSA vs RSA
Is ECDSA more secure than RSA?
At recommended sizes both are secure today. ECDSA gives equivalent security with much smaller keys.
Does key type affect TLS 1.3?
TLS 1.3 works with both; the certificate key type affects only the signature algorithm used for authentication.
What about post-quantum certificates?
Post-quantum key exchange is being deployed in browsers and servers, but publicly trusted post-quantum certificates are not yet standard practice. RSA and ECDSA remain the norm.