Why Your Browser is Blocking the Connection
You’re trying to reach a website, but Chrome stops you dead with a NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM warning. This isn't a random glitch. Your browser has detected that the site's security certificate relies on SHA-1, a hashing algorithm that has been effectively broken for years.
Google officially deprecated SHA-1 in early 2017 after researchers demonstrated the "SHAttered" attack. This proof-of-concept showed that two different files could produce the same SHA-1 hash. Because of this vulnerability, modern browsers treat SHA-1 certificates as forged or untrustworthy. If your server presents a SHA-1 signature—or even if an intermediate certificate in the chain uses it—the connection will be blocked.
How to Resolve the Error
Fixing this requires a server-side update. You need to replace the outdated certificate with one signed using SHA-256. Follow these steps to identify and swap the certificate.
Step 1: Confirm the Weak Signature
Don't guess where the problem lies. You can use OpenSSL to check exactly which algorithm your server is broadcasting. Run this command in your terminal:
openssl s_client -connect yourdomain.com:443 | openssl x509 -text -noout | grep "Signature Algorithm"
If the result displays sha1WithRSAEncryption, you have found the culprit. A secure site should return sha256WithRSAEncryption or ecdsa-with-SHA256.
Step 2: Generate a New CSR with SHA-256
Most modern tools use SHA-256 by default, but it is best to be explicit when creating your Certificate Signing Request (CSR). Use a 2048-bit key as the minimum standard.
openssl req -new -newkey rsa:2048 -nodes -sha256 -keyout yourdomain.key -out yourdomain.csr
Once you have the .csr, submit it to your Certificate Authority (CA) to get a fresh, SHA-256-signed certificate.
Step 3: Update Internal Certificate Authorities
In corporate environments using Windows Certificate Services, the CA itself might be the bottleneck. If your private CA is still issuing SHA-1 certs, you must update its configuration. For example, on a Windows CA, you might need to run:
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
After changing the setting, you must restart the Active Directory Certificate Services and re-issue the Root and Intermediate certificates to all client machines via Group Policy.
Step 4: Audit the Intermediate Chain
Sometimes your primary certificate is fine, but the server is sending an old SHA-1 intermediate certificate. This often happens if you haven't updated your fullchain.pem or ca-bundle file in several years. Ensure your Nginx or Apache configuration points to a bundle containing only SHA-256 intermediate certificates.
For Nginx, combine your files like this:
cat yourdomain.crt intermediate.crt > fullchain.pem
Verification
Restart your web server and clear your browser cache. Then, verify the fix:
- Navigate to your site in Chrome.
- Click the Lock icon > Connection is secure > Certificate is valid.
- Open the Details tab.
- Check the Signature algorithm field. It should now read
PKCS #1 SHA-256 With RSA Encryption.
Proactive Security Measures
Security standards move fast. It is a good idea to audit your SSL/TLS configurations every 12 months. Beyond just fixing SHA-1, ensure you have disabled deprecated protocols like TLS 1.0 and 1.1, which are also blocked by modern browsers.
When I’m managing multiple certificates, I often need to double-check file hashes to ensure nothing was corrupted during a migration. I use the Hash Generator on ToolCraft for this. It’s a fast, browser-based tool that supports SHA-256 and SHA-512. Since it processes the data locally in your browser, your sensitive keys or certificate data never actually leave your computer.
One final warning: Avoid using the "thisisunsafe" bypass in Chrome. While it gets you past the error screen, it leaves your users exposed to potential man-in-the-middle attacks. Fix the certificate at the source instead.