Why Key Type Matters
When you generate a TLS certificate, the first decision is the key type. This choice affects handshake speed, certificate size, security margin, and compatibility. There's no single best answer -- it depends on what you're building and what clients you need to support.
getaCert supports five key types: RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384, and Ed25519. Here's how to choose between them.
RSA: The Reliable Default
RSA has been the backbone of TLS since the 1990s. It's based on the difficulty of factoring large prime numbers. RSA keys are big, but they work everywhere.
RSA 2048
The current minimum for production use. NIST considers RSA 2048 safe through 2030, and most estimates extend that to the mid-2030s at least.
openssl genrsa 2048
- Key size: 2048 bits
- Security strength: ~112 bits
- Signature size: 256 bytes
- Compatibility: Universal. Works with every TLS client ever made.
RSA 2048 is what Let's Encrypt issues by default. If you have no specific requirements, this is a safe starting point.
RSA 4096
Double the key size, but not double the security. RSA 4096 provides ~140 bits of security strength versus RSA 2048's ~112 bits. The real cost is performance and bandwidth.
openssl genrsa 4096
- Key size: 4096 bits
- Security strength: ~140 bits
- Signature size: 512 bytes
- Compatibility: Universal, but slower handshakes on constrained devices.
RSA 4096 makes the TLS handshake noticeably slower, especially on mobile devices and IoT hardware. The larger certificates also consume more bandwidth. For most use cases, ECDSA P-256 provides better security than RSA 4096 with a fraction of the overhead.
ECDSA: More Security, Less Data
Elliptic Curve Digital Signature Algorithm (ECDSA) achieves equivalent security to RSA with much smaller keys. This translates directly to faster handshakes and smaller certificates.
ECDSA P-256
The sweet spot for most modern deployments. P-256 (also called prime256v1 or secp256r1) provides 128 bits of security strength -- more than RSA 2048 -- with dramatically smaller keys.
openssl ecparam -genkey -name prime256v1
- Key size: 256 bits
- Security strength: ~128 bits
- Signature size: 64 bytes
- Compatibility: Supported by all modern browsers and TLS libraries. Android 4.0+, iOS 5+, Windows Vista+.
P-256 is what Cloudflare, Google, and most CDNs use. It's the pragmatic choice for any service that doesn't need to support ancient clients.
ECDSA P-384
A higher-security elliptic curve for environments with stricter requirements.
openssl ecparam -genkey -name secp384r1
- Key size: 384 bits
- Security strength: ~192 bits
- Signature size: 96 bytes
- Compatibility: Broadly supported, same as P-256 in practice.
P-384 is commonly required by government standards (NSA's CNSA suite mandates it). For commercial web services, P-256 is sufficient and faster. Choose P-384 when compliance demands it.
Ed25519: The Modern Option
Ed25519 uses the Edwards curve Curve25519. It was designed to avoid the implementation pitfalls of ECDSA (like nonce reuse vulnerabilities) and provides fast, constant-time signatures.
openssl genpkey -algorithm ED25519
- Key size: 256 bits
- Security strength: ~128 bits (equivalent to P-256)
- Signature size: 64 bytes
- Compatibility: Limited for TLS certificates. Supported in OpenSSL 1.1.1+, but not by all CAs or all clients.
The Catch
Ed25519 is excellent for SSH keys and code signing, but TLS support is still maturing. As of 2026, no major public CA issues Ed25519 TLS certificates. Browser support exists but isn't as battle-tested as ECDSA. It's a fine choice for internal services and testing, but not yet the default recommendation for public-facing TLS.
Comparison Table
| Key Type | Key Size | Security Bits | Signature Size | TLS Handshake | Compatibility |
|---|---|---|---|---|---|
| RSA 2048 | 2048 bit | ~112 | 256 bytes | Baseline | Universal |
| RSA 4096 | 4096 bit | ~140 | 512 bytes | ~2-4x slower than RSA 2048 | Universal |
| ECDSA P-256 | 256 bit | ~128 | 64 bytes | ~5-10x faster than RSA 2048 | Modern clients (95%+) |
| ECDSA P-384 | 384 bit | ~192 | 96 bytes | ~3-5x faster than RSA 2048 | Modern clients (95%+) |
| Ed25519 | 256 bit | ~128 | 64 bytes | ~5-10x faster than RSA 2048 | Limited (OpenSSL 1.1.1+) |
Handshake times refer to the signature verification step. In real-world conditions, network latency usually dominates, but the difference becomes significant at high connection rates or on constrained hardware.
Performance in Practice
On a modern server handling thousands of new TLS connections per second, key type has a measurable impact:
# Approximate sign operations per second (single core, modern x86)
RSA 2048 sign: ~1,500 ops/sec
RSA 4096 sign: ~200 ops/sec
ECDSA P-256 sign: ~30,000 ops/sec
ECDSA P-384 sign: ~10,000 ops/sec
Ed25519 sign: ~50,000 ops/sec
The verification side (what clients do) shows a similar pattern, though RSA verification is relatively fast compared to RSA signing. ECDSA and Ed25519 are fast on both sides.
Certificate size also matters. An RSA 4096 certificate chain can be 4-5 KB larger than an ECDSA P-256 chain. Over millions of handshakes, that adds up. It also means more data in the initial TCP window, which can push the handshake to require an extra round trip on slow connections.
Decision Framework
Choose RSA 2048 when: - You need to support legacy clients (Windows XP, old Java, embedded devices). - Your CA only issues RSA certificates. - You have no performance concerns.
Choose RSA 4096 when: - Compliance requires it (some PCI DSS auditors insist on 4096). - You need a longer key lifetime and want extra security margin. - You've tested and confirmed the performance impact is acceptable.
Choose ECDSA P-256 when: - You're deploying a modern web service or API. - Performance and bandwidth matter (high-traffic sites, mobile-heavy audiences). - You don't need to support clients older than ~2012.
Choose ECDSA P-384 when: - Government or military compliance requires CNSA suite. - You want a higher security margin than P-256 without the overhead of RSA 4096.
Choose Ed25519 when: - You're running internal services with controlled client environments. - You want the strongest implementation security (no nonce pitfalls). - You're experimenting or future-proofing for internal infrastructure.
A Note on Post-Quantum
None of these algorithms are quantum-resistant. A sufficiently powerful quantum computer could break RSA and elliptic curve cryptography. Post-quantum TLS is in active development (ML-KEM/ML-DSA in TLS 1.3 drafts), but it's not production-ready for certificates yet. For now, choosing between these key types is about today's practical trade-offs, not about quantum threats.
Try It Yourself
Generate a certificate with any key type at getaCert.com. Select your preferred algorithm, generate the cert, and then decode it to see the key details in the certificate output. Comparing the actual output across key types is the fastest way to internalize the differences.