How to fix the weak certificate signature algorithm advisory

CertTracker fires the weak_sig_algorithm advisory when the leaf certificate is signed with a hash algorithm that modern browsers no longer trust: MD2, MD4, MD5, SHA-1, or RIPEMD. Unlike most TLS advisories, this one is a certificate-level issue, not a server-config issue — fixing it requires reissuing the certificate, not editing your web server.

What triggers the advisory

CertTracker inspects the Signature Algorithm field on the leaf certificate it pulls during the TLS handshake. If that field matches any of:

• md2WithRSAEncryption
• md4WithRSAEncryption
• md5WithRSAEncryption
• sha1WithRSAEncryption
• ecdsa-with-SHA1
• dsa-with-SHA1
• ripemd160WithRSA

…the advisory fires. SHA-256, SHA-384, and SHA-512 — including their ECDSA variants — are considered safe and do not trigger.

Current limitation: CertTracker only inspects the leaf certificate. A SHA-256 leaf chained to a SHA-1 intermediate (the sha1-intermediate.badssl.com pattern) won't trigger this advisory today. Full-chain walking is on the roadmap.

Why it matters

SHA-1 collisions have been demonstrated in practice (the SHAttered attack, 2017). Modern browsers reject SHA-1 leaf certificates from public CAs entirely; Chrome, Firefox, and Edge will display security warnings or hard errors. Public CAs stopped issuing SHA-1 leaves in 2016 — if you're seeing this advisory in 2026, the cert was likely issued by a private CA or an internal PKI that hasn't been updated.

MD5 and earlier hashes are catastrophically broken — practical collision attacks exist that can let an attacker mint a cert that browsers will treat as valid. If a real public CA is still using these, that's a much larger systemic problem; flag it.

Fix on a public-CA-issued certificate

If your certificate was issued by Let's Encrypt, DigiCert, Sectigo, GoDaddy, or any other public CA, you should never see this advisory. If you do, the cert is years old. Reissue:

1. Generate a new CSR using a SHA-256 or stronger signature algorithm.
2. Submit the CSR to your CA. Most CAs now refuse anything weaker than SHA-256 by default.
3. Install the new certificate (steps below).

Fix on a private-CA / internal-PKI certificate

This is by far the more common scenario. Your internal CA (Active Directory Certificate Services, a HashiCorp Vault PKI, an openssl-built CA) was likely created years ago when SHA-1 was the default. Two paths:

Option A: Reissue the leaf only, using SHA-256 explicitly.

If your CA can sign with SHA-256, just regenerate the cert with the correct algorithm. With OpenSSL:

openssl req -new -key server.key -out server.csr -sha256
openssl ca -config ca.cnf -in server.csr -out server.crt -md sha256

The -sha256 and -md sha256 flags force the signature algorithm. Without them, OpenSSL inherits the CA's default — which on a 2014-era config is probably SHA-1.

For Active Directory Certificate Services, update the certificate template's Cryptography tab to use SHA-256 as the request hash, then reissue the certs that were issued under the old template.

Option B: Rebuild the CA chain.

If your intermediate certs are also SHA-1, leaf reissuance alone isn't sufficient long-term — you're just deferring the problem. Schedule a CA hierarchy migration to SHA-256 chains. This is a larger project (root CA rotation, intermediate reissuance, every leaf cert reissuance) and out of scope for this article. Microsoft has an official guide for ADCS; HashiCorp has one for Vault's PKI engine.

Installing the new certificate

Apache

Replace the SSLCertificateFile (and SSLCertificateChainFile if the intermediate also changed) values in your vhost config, then:

sudo apachectl configtest && sudo systemctl reload apache2

Nginx

Update ssl_certificate (which should point to a fullchain.pem file) and ssl_certificate_key, then:

sudo nginx -t && sudo systemctl reload nginx

IIS

Use the IIS Manager → site → Bindings → Edit binding for port 443 → select the new certificate from the dropdown. If the new cert isn't in the list, import it into the Local Computer's Personal store first via certlm.msc.

HAProxy

Replace the file at the path referenced by your bind ssl crt <path> directive, then:

sudo systemctl reload haproxy

Verify the fix

1. Check the signature algorithm of the newly served leaf:

echo | openssl s_client -connect your-host.example.com:443 -servername your-host.example.com 2>/dev/null   | openssl x509 -noout -text   | grep "Signature Algorithm"

The output should show sha256WithRSAEncryption or ecdsa-with-SHA256 (or stronger). It should NOT show any reference to SHA-1, MD5, or earlier.

2. Re-scan in CertTracker. Trigger a re-scan from the CertTracker UI. The fastest path: open the monitor's detail modal (click the monitor row on the Monitors page), scroll to the Active Advisories section, and click the orange ⟳ Re-scan button on the right side of the section header. The status line below the header will confirm the cert re-poll and TLS audit are queued; the next 5-minute poller tick (within ~5 minutes) runs both, and the advisory clears if your fix took. See Where to find these buttons in the UI for visual landmarks.

Common pitfalls

• Cached intermediate — some clients (notably older Java versions) cache intermediate certs aggressively. If a client report-back says "still broken" even though your cert is reissued, clear their TLS cache.
• Multiple certs per host — if the server is configured with SNI and multiple certs, all of them need to be reissued. CertTracker polls one (hostname, port) combo; other listeners may still serve an old leaf.
• Wrong CSR signed — if you submitted a SHA-1 CSR to a CA that supports both, some CAs will sign with the requested algorithm. Always specify -sha256 on the CSR generation.

Related advisories

• Weak cipher or deprecated protocol — sometimes appears with this when an old config is in play across the board.
• Excessive validity period — same reissuance flow is usually the fix.

Back to the TLS hardening hub.