SSL certificate uses outdated cryptography

SeverityHigh

ScopeWhole site

EffortSmall

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_cert_weak_key

Short answer

Your certificate is signed with SHA-1 or MD5, or its public key is too short (RSA below 2048 bits, elliptic curve below 224 bits). Public certificate authorities have not been allowed to issue such certificates for years, so this one is usually self-made, internal or very old. Reissue it with an ECDSA P-256 or RSA 2048-bit key and a SHA-256 signature; every current CA does this by default.

Why it matters

Short RSA keys and SHA-1 or MD5 signatures are within reach of practical attacks: SHA-1 collisions have been demonstrated publicly, and MD5 collisions were once used to forge a working CA certificate. Someone who can forge what your certificate relies on can impersonate your site. In practice, current browsers already refuse SHA-1 server certificates, so this finding often means some visitors cannot connect at all. There is no direct ranking effect, but a certificate that browsers reject has the same consequences as an invalid one.

How Glimana detects it

Glimana reads the signature algorithm and public key of the certificate your server presents (the leaf certificate, not the intermediates). The check fails with high severity if the signature algorithm uses SHA-1 or MD5, if the key is RSA shorter than 2048 bits, or if it is an elliptic-curve key shorter than 224 bits. RSA 2048 or larger, ECDSA P-256 or P-384, and SHA-256 or stronger signatures pass.

How to fix it

Watch out

Generate a new private key when you reissue; do not reuse the old short one. After installing the new certificate, reload or restart the web server, because Apache and Nginx keep the old certificate in memory until then. If you switch to ECDSA, confirm that any very old clients you must support (legacy terminals or integrations) can handle it; otherwise RSA 2048 is the safe default.

Find the finding in Glimana. Open Security; this check is in the Certificate and HTTPS group, with the evidence from the last scan under its title. The same problem is listed under Issues › SSL certificate uses outdated cryptography.
Apply the fix on your platform.

CertbotHosting panelManual (OpenSSL)

Certbot 2.0 and later creates ECDSA keys by default. To switch an existing certificate: sudo certbot renew --cert-name example.com --key-type ecdsa --force-renewal (or --key-type rsa --rsa-key-size 2048). Certbot requires --cert-name together with --key-type as confirmation when the key type changes. Then reload the web server.

cPanel AutoSSL and Plesk SSL It! issue certificates with RSA 2048 or ECDSA keys and SHA-256 signatures. In cPanel, remove the weak certificate under SSL/TLS › Manage SSL sites and let AutoSSL issue a new one; in Plesk, reissue it with SSL It!. For a certificate bought from a commercial CA, generate a new CSR in the panel with a key size of 2048 bits or more and request a reissue, which most CAs provide free of charge.

New ECDSA P-256 key and CSR: openssl ecparam -genkey -name prime256v1 -out example.com.key, then openssl req -new -key example.com.key -out example.com.csr -subj "/CN=example.com". For RSA: openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com". Submit the CSR to your CA and install the certificate you get back. Inspect any certificate with openssl x509 -in cert.pem -noout -text | grep -E "Signature Algorithm|Public-Key".
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

Press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes when the check passes.