The fix, in one snippet
certbot certonly --key-type ecdsa --elliptic-curve secp256r1 -d example.comIllustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now extracts the public key from the leaf certificate and from each intermediate in the chain and records the algorithm and size. RSA keys of 2048 bits or more pass, as do ECDSA keys on the P-256 or P-384 curves. An RSA key below 2048 bits is flagged (medium), and any DSA key is flagged because no browser accepts DSA-signed server certificates. The result lists the key type and length for each certificate in the chain, so a weak intermediate from a private CA is visible too. Scan.now does not attempt anything against the key; this is a metadata read. Related transport checks: the signature algorithm used to sign the certificate, and the cipher suites the server is willing to negotiate.
Why it matters
The security of RSA rests on the difficulty of factoring the modulus. NIST SP 800-131A disallowed 1024-bit RSA for digital signatures after 2013, and the CA/Browser Forum Baseline Requirements have prohibited public CAs from issuing certificates with RSA keys under 2048 bits since 2014, so a weak key today almost always comes from an internal CA, an appliance's factory certificate, or a very old key pair that was re-signed rather than replaced. Chrome and Firefox refuse RSA keys shorter than 1024 bits outright and treat 1024-bit keys as weak. If the key is factored, an attacker can impersonate the site and decrypt any TLS 1.2 session that used RSA key exchange, since those sessions have no forward secrecy. The SSL and TLS guide covers key types and what each protects.
How to fix it
Generate a new key pair and re-issue the certificate. RSA 2048 remains the compatible default; ECDSA P-256 gives equivalent security with smaller handshakes. With Certbot, ECDSA is one flag:
sudo certbot certonly --nginx -d example.com --key-type ecdsa --elliptic-curve secp256r1Generating keys by hand with OpenSSL:
# RSA 3072
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out example.key
# ECDSA P-256
openssl ecparam -genkey -name prime256v1 -noout -out example.keyThen point the server at the new files (nginx ssl_certificate_key, Apache SSLCertificateKeyFile) and reload. nginx can serve an RSA and an ECDSA certificate side by side by listing two ssl_certificate / ssl_certificate_key pairs, letting the client choose. Cloudflare's edge certificates already use 2048-bit RSA or P-256 ECDSA; if the finding is against your origin, replace the origin certificate. While you are there, make sure any Diffie-Hellman parameters used for TLS 1.2 DHE suites are at least 2048 bits (ssl_dhparam in nginx), since short DH groups have the same weakness (Logjam).
Where this fits
Certificate key strength is check 6 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits HTTP redirects to HTTPS (high), where port 80 serves page content instead of redirecting to HTTPS, or the redirect chain is wrong. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Certificate key strength closes one route in. Immediately below it: Certificate signature algorithm, where a certificate in the chain is signed with SHA-1, MD5 or another broken hash; Strict-Transport-Security (HSTS), where the HTTPS response carries no Strict-Transport-Security header, or its max-age is too short to protect returning visitors; Weak cipher suites accepted, where the server is willing to negotiate legacy cipher suites such as RC4, 3DES, export-grade, NULL or anonymous suites, or offers TLS 1.2 suites without forward secrecy.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Certificate key strength (medium severity)
Scanner check id: certificate-key-strengthThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
