Public Key Strength

Public Key Strength inspects the cryptographic key in the leaf certificate served on your apex hostname (the check intentionally skips www and auxiliary hosts to avoid double-counting CDN PoP variance). Modern WebPKI accepts RSA 2048 and above, ECDSA on common NIST curves (P-256, P-384, P-521), and the Edwards-curve algorithms Ed25519 / Ed448. Weak keys (RSA 1024 or below) fail. Intermediate or unrecognized parameters get partial credit because modern browsers often still accept them.

How the check works

Per sampled apex host, the check reads the leaf cert's public key and assigns one of these bands:

• rsa_strong (1.0): RSA at 2048 bits or larger.
• rsa_weak (0.0): RSA at 1024 bits or below. Reason: ct_key_strength_weak.
• rsa_intermediate (0.88): RSA between 1025 and 2047 bits. Rare; usually a misconfiguration. Reason: ct_key_strength_indeterminate.
• edwards_modern (1.0): Ed25519 or Ed448.
• ecc_strong (1.0): ECDSA on a recognized strong curve (secp256r1/prime256v1/P-256, secp384r1/P-384, secp521r1/P-521).
• ecc_strong_inferred_from_key_size (1.0): ECDSA where the curve name was unparseable but the key bit size matches the strong curve set (256, 384, 521).
• ecc_unknown_curve (0.88): ECDSA on a curve the check does not recognize. Reason: ct_key_strength_indeterminate.
• unknown_key_type (0.88): algorithm could not be classified. Reason: ct_key_strength_indeterminate.

The composite blends the mode score (most-frequent key signature across sampled hosts, weighted 90%) with the min score (10%). Special-cased short-circuits: every host in a strong band scores 1.0; two or more hosts all on the same intermediate-RSA signature scores 1.0 (treated as intentional consistent setup). Verdict via the standard CT composite mapping.

How the verdict maps to evidence

• Pass: all sampled hosts on RSA 2048+, Ed25519/Ed448, or ECDSA P-256/P-384/P-521.
• Warn: intermediate or unknown key parameters that drop the blended score below pass.
• Fail: any host on RSA 1024 or below, or worst-case key parameters dragging the blend.

Evidence shows key_profiles per host (algorithm, key_size, curve, band, score, mode_signature) plus the composite breakdown (mode_score, min_host_score, blended_score).

Special states

• Unavailable: no HTTPS samples could be obtained. Fix Web Assessability or HTTPS Consistency first.

Fix: re-issue certs with strong keys

Key strength is set at certificate issuance. There is no way to upgrade the key on an existing cert; you have to issue a new cert with the desired key parameters and serve it. Most ACME clients let you specify the key type and size.

Let's Encrypt with certbot

sudo certbot certonly --nginx \
  -d yourdomain.tld -d www.yourdomain.tld \
  --key-type ecdsa --elliptic-curve secp384r1

# Or RSA 4096 if the client base needs RSA only:
sudo certbot certonly --nginx \
  -d yourdomain.tld \
  --key-type rsa --rsa-key-size 4096

ECDSA certs negotiate faster TLS handshakes and use less CPU per connection than RSA. P-256 is the most-compatible ECDSA option; P-384 is preferred for higher security margin. Stay below P-521 unless you have a specific compliance requirement; P-521 is rarely needed and slightly less compatible.

Caddy

yourdomain.tld {
    tls ops@yourdomain.tld {
        # Defaults to ECDSA P-256. Override if needed:
        # key_type rsa4096
        # key_type p384
    }
    reverse_proxy localhost:8080
}

AWS ACM

ACM-issued certs default to RSA 2048. To get ECDSA, request a new cert with the ECDSA P-256 or ECDSA P-384 key algorithm option in the request flow. Existing RSA certs cannot be converted; request a new ECDSA cert and replace the binding on your distribution or load balancer.

Cloudflare

Universal SSL on Cloudflare uses ECDSA P-256 by default for compatible clients (modern browsers) and may also include an RSA cert for legacy compatibility. No configuration needed; if your apex is behind Cloudflare proxy and the score is failing here, check whether the apex is being served by a different origin path.

Commercial CAs (DigiCert, Sectigo, GlobalSign)

Specify ECDSA P-256 or P-384 in the CSR. CSR generation:

openssl ecparam -genkey -name secp384r1 -out yourdomain.key
openssl req -new -key yourdomain.key -out yourdomain.csr \
  -subj "/CN=yourdomain.tld"

# For RSA 4096:
openssl genrsa -out yourdomain.key 4096
openssl req -new -key yourdomain.key -out yourdomain.csr \
  -subj "/CN=yourdomain.tld"

Verify the fix

• openssl s_client -connect yourdomain.tld:443 -servername yourdomain.tld < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'Public Key Algorithm|Public-Key|NIST CURVE'. Look for RSA Public-Key: (2048+ bit), id-ecPublicKey + secp256r1/secp384r1, or ED25519.
• ssllabs.com/ssltest reports the cert key in the Server Key and Certificate section.
• Re-run the RedScore lookup. The score moves immediately on the next scan; no DNS or browser cache wait.

Common pitfalls

• Apex-only check, but you fixed www. The check intentionally probes apex only. Fix the cert on the apex hostname; www and other subdomains do not affect this score.
• Cert renewed but old cert still loaded. Reverse proxies cache certs in memory until reload. Reload your web server after issuing a new cert with stronger key parameters.
• RSA 4096 not always better than RSA 2048. RSA 4096 is roughly 5x slower at handshake than 2048 and gives only a marginal security improvement. ECDSA P-256 is faster than RSA 2048 with stronger security; prefer ECDSA where supported.
• Mixed apex pool with different key types. If your apex is served by multiple machines (CDN PoPs, multi-region origin) with different key types, the mode-blend handles it gracefully. But truly inconsistent setups produce confusing scores; standardize.
• Browser compatibility for ECDSA. Anything from the last decade supports ECDSA P-256. P-384 and Ed25519 may not be universally supported on very old IoT or embedded TLS stacks. Check your client base.
• ACM cannot upgrade an existing cert. Issue a new ACM cert with the desired algorithm and update the listener binding; you cannot retroactively change the key on an issued cert.