The fix, in one snippet
openssl x509 -in cert.pem -noout -text | grep 'Signature Algorithm'Illustrative 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 reads the signatureAlgorithm of the leaf certificate and of each intermediate the server sends. sha256WithRSAEncryption, sha384WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384 and RSASSA-PSS with a SHA-2 digest pass. sha1WithRSAEncryption, md5WithRSAEncryption, md2WithRSAEncryption and ecdsa-with-SHA1 are flagged. The self-signature on the root certificate is ignored, because roots are trusted by identity in the trust store, not by their signature, and many older roots are legitimately SHA-1 self-signed. The output names the offending certificate so you can tell a leaf problem from an intermediate one. The strength of the key itself is a separate check, certificate-key-strength.
Why it matters
The signature is what a browser verifies to know that the CA really issued this certificate. If the hash underneath can be collided, an attacker can obtain a legitimate certificate for one name and craft a second certificate, with a different name or CA-flag, that carries the identical signature. MD5 was exploited this way in 2008 to create a rogue intermediate CA. SHA-1 collisions became practical in 2017 (the SHAttered result from Google and CWI) and chosen-prefix collisions followed in 2020. Chrome 56 and Firefox 51 stopped accepting SHA-1-signed certificates in early 2017, so a finding here means visitors on modern browsers already see errors; the certificate almost certainly comes from a private CA, an old appliance or a hardware load balancer whose default certificate was never replaced. Details are in the certificate errors guide.
How to fix it
Re-issue the certificate from a public CA; all of them sign with SHA-256 or stronger by default, so no flag is needed with Certbot or any ACME client. If the certificate comes from an internal CA that you control, re-sign with a SHA-2 digest. Signing a CSR with OpenSSL:
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 180 -sha256 -out server.crtCheck what a certificate on disk, or one served by a host, is signed with:
openssl x509 -in server.crt -noout -text | grep 'Signature Algorithm'
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep 'Signature Algorithm'Then install the new file: nginx ssl_certificate, Apache SSLCertificateFile, and reload. If the SHA-1 certificate belongs to an intermediate, ask the CA for their current SHA-256 intermediate and replace it in the chain file. Behind Cloudflare, the edge certificate is already SHA-256; the finding refers to your origin certificate, which Cloudflare Origin CA can replace in a minute.
Where this fits
Certificate signature algorithm is check 7 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 Certificate key strength (medium), where the certificate's public key is weaker than current guidance: An RSA key shorter than 2048 bits, or a DSA key. 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 signature algorithm closes one route in. Immediately below it: 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; TLS 1.3 support, where the server negotiates TLS 1.2 at best and does not offer TLS 1.3.
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 signature algorithm (medium severity)
Scanner check id: certificate-signature-algorithmThe 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.
