For most new public sites, choose ECDSA with the common P-256 curve, which current Certbot uses by default, and keep RSA where an old client forces it. Existing certificates keep their key type until you change it, so switching is a deliberate step you should test first.
What the choice is
A certificate binds a public key to your names. That key can be RSA or elliptic curve (ECDSA). Both work in TLS. ECDSA keys are much shorter for comparable strength, which means smaller handshakes. RSA has the longest compatibility history. The question is mainly about which clients you must support.
What the tooling does today
The Certbot documentation lists these defaults:
- Key type: ecdsa
- Elliptic curve: secp256r1
- RSA key size, if you pick RSA: 2048
Certbot also says existing certificates continue to renew with their existing key type unless you request a change. Let's Encrypt issues ECDSA subscriber certificates from its ECDSA intermediates and RSA ones from RSA intermediates, so you pick the path when you pick the key.
How to switch one certificate
certbot renew --key-type ecdsa --cert-name example.com --force-renewal
To make ECDSA the default for all future issuance and renewals, add this line to Certbot's configuration file:
key-type = ecdsa
Certbot warns that if you use ECDSA keys you should not downgrade to a version before 1.10.0.
Decision guide
| Situation | Lean toward |
|---|---|
| New public web app, modern clients | ECDSA P-256 |
| Must serve very old embedded or legacy clients | RSA 2048 or higher, tested |
| Mixed audience | Test ECDSA against your oldest real clients first |
| Internal services you control | ECDSA |
If you are unsure what your clients support, look at real traffic logs for the oldest TLS libraries and devices, and run a test connection from each against a staging certificate. See how to test with staging.
How to test compatibility
- Issue a staging certificate with the new key type.
- Connect from every client class you support: browsers, mobile apps, command line tools, language runtimes and any appliance that calls your API.
- Record failures with the TLS library version, since the library decides what it understands.
- Roll out to a small slice of traffic and watch handshake errors before switching everything.
- Keep a documented way to go back, such as the old RSA certificate kept ready.
Key choice and key hygiene
The algorithm matters less than how you guard the private key and how often you replace it. ECDSA signing has its own pitfalls in poorly written libraries, covered in ECDSA nonce reuse and why Ed25519 avoids it. Keep your crypto libraries patched.
Where Safeguard fits
Safeguard scans dependencies and SBOMs for known vulnerabilities, including those in the TLS and crypto libraries your projects pull in, and you can try it with the free scan at gold.safeguard.sh/scan.
Quick check
Will my existing RSA certificate turn into ECDSA at renewal?
No. Certbot keeps the existing key type unless you request a change.
What RSA size does Certbot use by default?
2048 bits.
Sources
Last reviewed: 19 October 2026.
