Certificate key strength and signature algorithm

TL;DR: Every TLS cert has two cryptographic knobs — the public key (algorithm + size) and the signature the CA used to sign it. In 2026, ECDSA P-256 + SHA-256 is the modern default, RSA 2048 + SHA-256 is acceptable but on NIST’s rotation list for 2030, and anything below 2048 bits or anything signed with SHA-1 is a hard fail that modern browsers already reject.

What is it?

When a browser inspects your TLS certificate, two pieces of crypto identity are doing the work:

The public key. This is the half of an asymmetric keypair that the cert binds to your domain. The browser uses it (or, in TLS 1.3, uses a signature made with the matching private key) to prove the server actually controls the cert. Public keys come in flavors — RSA, ECDSA, Ed25519 — and each has a size or curve that determines how strong it is.
The signature algorithm. This is the algorithm the CA used when it signed your cert with its own private key. The browser verifies that signature against the CA’s public key (which it trusts via the root store) to confirm the cert wasn’t forged. The algorithm is a pairing — a hash function (SHA-256, SHA-384, SHA-512) plus the CA’s own key type.

Public key types

RSA. The most common. Strength scales with key size in bits. 2048-bit is the floor for any publicly-trusted cert (CA/Browser Forum minimum since 2014), 3072-bit is what NIST recommends for keys that need to stay strong past 2030, 4096-bit is overkill for most people but harmless.
ECDSA. Elliptic-curve signatures. Much smaller keys for equivalent strength — a 256-bit ECDSA key is roughly equivalent to a 3072-bit RSA key. The standard curves are P-256 (a.k.a. secp256r1, prime256v1), P-384 (secp384r1), and P-521 (secp521r1). Faster handshakes, smaller cert files, smaller network packets.
Ed25519 / Ed448. Modern by construction — designed to avoid the implementation pitfalls that have bitten ECDSA over the years (notably nonce reuse). Fast and small. The catch: browser and OS support is still patchy in 2026, so most public sites can’t ship Ed25519 leaf certs without breaking visitors. Mostly used inside internal PKI today.

Signature algorithms

SHA-256, SHA-384, SHA-512. All modern, all safe. SHA-256 is by far the most common — it’s the default for almost every public CA. SHA-384 and SHA-512 are sometimes paired with stronger ECDSA curves to keep the hash strength “matched” to the key strength.
SHA-1. Considered cryptographically broken since 2017 (when Google and CWI published the first practical collision, “SHAttered”). Every modern browser refuses to trust a SHA-1-signed leaf cert. CA/Browser Forum has prohibited SHA-1 issuance since 2016. You should never see this on a publicly-trusted cert today, but it still occasionally turns up on old internal CAs or appliances that nobody has touched in a decade.
MD5. Don’t.

Why does it matter?

Cryptographic strength is a function of two things: how big the key is and how hard the underlying math is to break. Both of these have to be in modern shape, because TLS is only as strong as the weakest link.

Key size matters because computers keep getting faster. RSA-1024 was considered safe in the late 1990s. Today it’s brute-forceable by a well-funded adversary in a reasonable amount of time, which is why the public CA ecosystem moved off of it. NIST’s SP 800-131A formalizes the rotation cadence: it recommends migrating RSA-2048 to RSA-3072 (or to ECDSA P-256+) before 2030, on the same logic — Moore’s law plus algorithmic progress keeps pushing the brute-force bar lower.

Signature algorithm matters because hash collisions break the chain of trust. If an attacker can find two different inputs that hash to the same SHA-1 value, they can in principle forge a cert that the CA never actually signed. SHA-1 collisions are now practical at attacker-affordable cost. SHA-256 isn’t.

ECDSA matters because it’s faster. At equivalent security, an ECDSA P-256 key is ~12x smaller than an RSA-3072 key, the handshake math is faster, and the cert itself is smaller on the wire. For mobile clients on constrained networks, that’s a real perf win. Many CAs and ACME issuers now default to ECDSA where the client will accept it.

Real-world analogy

Think of your cert’s key as the combination on a combination lock, and the signature algorithm as the type of glue holding the lock to the door.

RSA-1024 is a 4-digit combo. 10,000 possibilities, brute-forced in seconds by anyone with a laptop. This hasn’t been allowed for public certs in over a decade.
RSA-2048 is something like a 20-digit combo. Acceptable today — nobody is brute-forcing a random 2048-bit key with off-the-shelf hardware — but in 20 years, computers will be fast enough that you should plan to upgrade before then. That’s why NIST flags it for 2030 rotation.
RSA-3072 / ECDSA P-256 is a 30-digit combo, or alternatively a different lock entirely with much shorter combos for the same effective strength. Forward-looking through the 2030s.
SHA-256 is industrial-grade glue. SHA-1 is the chewing gum someone used in 2008 — looks fine, falls off if you actually pull on it, and the safety inspector is going to fail your audit for using it.

A short tour of the most common combos

These are the cert configurations you’ll actually run into:

RSA 2048 + sha256WithRSAEncryption. The Let’s Encrypt default before they went ECDSA, still the default at many paid CA portals. Acceptable today. NIST flags it for rotation by 2030.
RSA 3072 + sha256WithRSAEncryption. Modern RSA, forward-looking through the 2030s. A reasonable choice if your stack doesn’t fully support ECDSA yet.
RSA 4096 + sha256WithRSAEncryption. Slightly slower than 3072, no real security upside for the marginal cost. Common in security- conscious orgs that picked “the biggest number” without doing the math. Harmless.
ECDSA P-256 + ecdsa-with-SHA256. The modern default. Fast, small, supported by every ACME issuer (Let’s Encrypt, ZeroSSL, Google Trust Services, Buypass) and every browser shipped this decade. Recommended.
ECDSA P-384 + ecdsa-with-SHA384. Higher security tier — used in regulated environments (US federal Suite B, some healthcare and finance). Still universally supported.
Ed25519. Modern by construction, fastest of the bunch, but browser/OS support is still patchy in 2026. Check your client matrix before deploying — fine for internal services, risky for public web.

How WQI measures this

We grade cert key strength and signature algorithm as factor WEBQ-89 in the Security category. We parse the leaf certificate’s subjectPublicKeyInfo (key algorithm + size, EC curve) and signatureAlgorithm OID directly from the ASN.1 bytes captured during the TLS handshake.

Result	What it means
Pass (100)	RSA ≥ 3072 with SHA-256+, OR ECDSA on P-256/P-384/P-521 with SHA-256+, OR Ed25519/Ed448.
Warn (60)	RSA exactly 2048 with SHA-256 — acceptable today, NIST flags for 2030 rotation.
Fail (0)	RSA < 2048, ECDSA on a weak curve (P-224 or smaller), or any SHA-1 signature.

The warn tier exists specifically because RSA-2048 + SHA-256 is the single most common cert configuration on the public web today. We don’t want to fail the majority of sites for a configuration that’s still cryptographically sound — we just want to nudge operators toward a rotation before the 2030 deadline gets uncomfortably close.

What good looks like

ECDSA P-256 + SHA-256 is the modern default. It’s faster than RSA at equivalent security, smaller on the wire, supported by every mainstream client, and free from every ACME issuer. If you’re provisioning a fresh cert today, this is the answer.

If you’re in a regulated environment that mandates a higher curve (US federal, some banking standards), step up to P-384 + SHA-384. The performance hit is small and the compatibility story is identical.

If your stack genuinely can’t speak ECDSA yet (very old Java clients, some legacy IoT firmware), RSA 3072 + SHA-256 is the strong RSA fallback.

How to fix it

Request an ECDSA cert from your CA. Most ACME clients support it directly:

# certbot
certbot certonly --key-type ecdsa --elliptic-curve secp256r1 \
  -d example.com

# acme.sh
acme.sh --issue -d example.com --keylength ec-256

For paid CAs (DigiCert, Sectigo, GlobalSign), you generate an ECDSA CSR with OpenSSL and submit it through their portal:

openssl ecparam -name prime256v1 -genkey -noout -out ecdsa.key
openssl req -new -key ecdsa.key -out ecdsa.csr -sha256 \
  -subj "/CN=example.com"

If you’re on RSA 2048 today, you’re fine for the moment, but plan a rotation before 2030 — either to ECDSA P-256 or to RSA 3072. The longer you wait, the more likely you are to be the last one on RSA-2048 when browsers start warning on it.

If you’re on RSA < 2048 or any SHA-1 signature, reissue immediately. Your cert is being rejected by every modern browser — it’s only working today on legacy clients, and probably not even those. The fix is the same: request a fresh cert from any modern CA, which will issue at the modern minimums by default.

Verify what you have with OpenSSL:

openssl s_client -connect example.com:443 </dev/null 2>/dev/null \
  | openssl x509 -text -noout \
  | grep -E "Public Key Algorithm|Public-Key|Signature Algorithm"

You should see something like Public Key Algorithm: id-ecPublicKey, Public-Key: (256 bit), and Signature Algorithm: ecdsa-with-SHA256. If you see sha1WithRSAEncryption anywhere, that cert is on borrowed time.

Common pitfalls

IoT devices that don’t speak ECDSA. Older embedded TLS stacks (some pre-2018 firmware) only know RSA. If your domain serves both browsers and a fleet of legacy IoT clients, you may be stuck on RSA. Check before you migrate, or run a dual-cert setup if your terminator supports it.
Old Java clients. Java 7 and earlier had spotty ECDSA support in the default trust manager. If you’re integrating with an old enterprise Java system that you can’t upgrade, RSA may be the pragmatic answer.
Paid CA portals that default to RSA 2048 silently. Many of the legacy CA buying flows (especially for OV / EV certs) still default to RSA 2048 + SHA-256 unless you explicitly request ECDSA. The CSR you submit determines the key — generate it with ECDSA from the start, or you’ll get RSA back.
Mismatched hash strength. Pairing ECDSA P-384 with SHA-256 is technically fine but a bit of a code smell — the hash is the weak link in that pair. Match the hash to the curve (P-256 + SHA-256, P-384 + SHA-384, P-521 + SHA-512) for cleanest configuration.
Keeping the same private key across renewals. Some operators reuse the same RSA private key for years through many renewals. This is allowed but bad hygiene — every renewal is a chance to rotate the key material. ACME clients rotate by default; paid CA portals often don’t.