Browser errors
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: SHA-1 or MD5 signature
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHMNET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM means a certificate the server sent is signed with SHA-1 or MD5, algorithms that can be forged. Chrome refuses such certificates because an attacker could create a different certificate with the same signature. The fix is a newly issued certificate signed with SHA-256 or stronger.
Is it the site or your device?
Usually the site or device uses an old certificate; a SHA-256 result from an outside check points to interception. Check the signature algorithms with the SSL checker:
curl ssl.sh/example.com
- The checker shows SHA-1 or MD5 on the leaf or an intermediate: the site or device must be updated.
- The checker shows SHA-256 everywhere: your device or network is presenting a different certificate, probably from an old HTTPS-scanning product or proxy. Update or disable it.
Causes
1. Old internal CA
A Windows AD CS or OpenSSL CA set up long ago may still sign with SHA-1. Check the leaf:
echo | openssl s_client -connect intranet.example.com:443 -servername intranet.example.com 2>/dev/null \
| openssl x509 -noout -text | grep "Signature Algorithm" | head -1
sha1WithRSAEncryption or md5WithRSAEncryption confirms it.
2. SHA-1 intermediate in the chain
The leaf is fine, but the server still sends a legacy intermediate signed with SHA-1. Replace the chain file; the chain builder picks current intermediates.
3. Appliances with factory certificates
Older printers, switches, UPS cards and KVMs ship SHA-1 certificates. Update firmware or upload a new certificate.
4. Outdated interception software
Old security products may still re-sign traffic with SHA-1. Every HTTPS site then fails in Chrome.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Chrome / Edge | "Your connection is not private" with NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM |
| Firefox | "Warning: Potential Security Risk Ahead" with SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED |
| Safari | "This Connection Is Not Private" |
| OpenSSL 3.x | ca md too weak at default security level |
How site owners fix it
A new certificate and chain signed with SHA-256 fixes it.
1. Generate a new key and CSR (SHA-256 is the default in current OpenSSL):
openssl req -new -newkey rsa:2048 -nodes -sha256 \
-keyout example.com.key -out example.com.csr \
-subj "/CN=example.com" -addext "subjectAltName=DNS:example.com"
The CSR generator does the same in the browser.
2. Reissue from a public CA, or for internal CAs set the hash algorithm to SHA-256 (in AD CS: certutil -setreg ca\csp\CNGHashAlgorithm SHA256, then restart the CA service).
3. Replace intermediates with the CA's current SHA-256 chain.
4. Verify with curl ssl.sh/example.com and the certificate decoder: every certificate except the root should show sha256WithRSAEncryption or an ECDSA-SHA256/384 signature.
FAQ
Is SHA-1 still allowed anywhere?
Not for publicly trusted TLS certificates. Some closed internal systems still run SHA-1 certificates, but modern Chrome, Firefox and Safari reject them, and so do current OpenSSL security levels.
My root CA is SHA-1. Do I need to replace it?
Not because of its own signature: browsers trust a root because it is in the store, not because of how it signed itself. But the certificates it issues must be signed with SHA-256 or better, so the CA software must be configured accordingly.
What does Firefox show for the same problem?
Firefox reports SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED on its "Warning: Potential Security Risk Ahead" page.
Can I keep an old device that only offers a SHA-1 certificate?
Keep it off the internet and reach its admin page only from a trusted management network. Check the vendor for firmware that can import a new certificate; many devices accept an uploaded PEM certificate and key, which you can issue from an internal CA with SHA-256. If the device cannot be updated at all, plan to replace it, because current browsers will not open its HTTPS interface.
Does the hash in the CSR decide the certificate signature?
No. The CSR is signed by your own key to prove possession; the certificate signature is chosen by the CA. A SHA-1 CSR sent to a modern public CA still produces a SHA-256 certificate. With an internal CA, configure the CA itself to use SHA-256.