How to Fix the NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM Error

Chrome shows NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM when a site presents a certificate signed with a hashing algorithm the browser no longer accepts. In practice, that algorithm is SHA-1.

The error reads like a server misconfiguration, but it is narrower than that. A signature algorithm is written into a certificate at the moment the Certificate Authority signs it, and nothing you change afterwards on the server, in the browser, or on your own device can alter it. The certificate itself has to be replaced.

This guide shows you how to read the signature algorithm out of a certificate, how to tell which certificate in the chain is the offender, and what to do about each case.

Quick answer:

NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM means the certificate the server sent, or one of the intermediate certificates above it, is signed with SHA-1. The only fix is to reissue that certificate with SHA-256, because the signature algorithm is fixed at issuance and cannot be changed in place. Public Certificate Authorities have been barred from issuing SHA-1 certificates since January 1, 2016, so if you hit this error today you are almost certainly looking at an internal Certificate Authority, a self-signed certificate, or an appliance nobody has updated in years. A SHA-1 signature on a self-signed root certificate is not the cause: browsers do not check it.

What NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM actually means

In Chromium’s error list, this is network error -208, described as a server that “responded with a certificate that is signed using a weak signature algorithm.” Chrome, Edge, Brave, Opera, and every other Chromium browser share that code, so they all fail the same way.

One caveat about current versions. The code is still defined, but Chromium’s own source questions whether the certificate status behind it is still in use, and the modern verifier is configured to reject weak digests through a different path. A recent Chrome may therefore report the same certificate as NET::ERR_CERT_INVALID instead. Nothing below changes if it does: the certificate is signed with SHA-1, and reissuing it with SHA-256 is the fix either way.

To understand what is being rejected, it helps to know what a Certificate Authority actually does when it issues a certificate. It takes the certificate’s contents, runs them through a hash function to produce a short fingerprint of that data, then signs that fingerprint with its own private key. The hash function used in that first step is recorded inside the certificate as its signature algorithm, and that recorded value is what the browser is objecting to.

SHA-1 is the problem. It produces a 160-bit hash, and it is vulnerable to collisions, where two different inputs can be made to produce the same hash. Applied to certificates, a collision is the ability to forge one. Browser vendors committed to dropping SHA-1 before that became practical rather than waiting, and the timing vindicated them: Chrome 56 shipped without SHA-1 support at the end of January 2017, and researchers published the first real SHA-1 collision a few weeks later in February 2017.

Firefox reports the same underlying condition as SEC_ERROR_CERT_SIGNATURE_ALGORITHM_DISABLED. Different wording, identical cause, identical fix.

Note that this is a distinct error from ERR_CERT_WEAK_KEY, which is network error -211 and refers to a certificate containing a key that is too small, such as a 1024-bit RSA key. A certificate can have a perfectly strong key and still be signed with SHA-1, and that combination produces the error in this guide.

Which certificate in the chain triggers the error

This is the detail most troubleshooting advice gets wrong, and getting it right will save you from replacing the wrong certificate.

A server does not send one certificate, it sends a chain of trust: your server certificate (the leaf), then one or more intermediate CA certificates, and at the top a root certificate. The browser checks the signature on each certificate using the public key of the one above it.

The SHA-1 restriction applies to the leaf and to the intermediates. It does not apply to the self-signature on the root. Google’s announcement of the policy states it plainly, describing the restriction as covering sites that have a SHA-1-based signature as part of the certificate chain, “not including the self-signature on the root certificate.” Chromium’s verification code does the same thing, iterating the chain while “excluding the final one (which is presumably the trust anchor).”

The reason is that a root certificate signs itself, so its signature proves nothing. Trust in a root comes from the fact that its public key is already in the operating system or browser trust store, put there deliberately. The self-signature is decoration, and a weak algorithm on it changes no security property.

The practical consequence: plenty of perfectly healthy sites chain to old roots that carry SHA-1 self-signatures, and they load without complaint. If you inspect your chain, find SHA-1 on the root, and start planning a migration, you are chasing something that is not broken. Look at the leaf and the intermediates instead.

Why this is almost always a private certificate

Three separate deadlines closed off the public web to SHA-1, and all of them are long past.

• January 1, 2016. The CA/Browser Forum Baseline Requirements barred Certificate Authorities from issuing any new subscriber or subordinate CA certificate using SHA-1. Every publicly trusted CA has been unable to sell you one since.
• Chrome 56, end of January 2017. Chrome stopped trusting SHA-1 certificates that chain to a public CA, showing an interstitial warning instead.
• Chrome 57, March 2017. The same treatment extended to certificates chaining to locally installed roots, meaning enterprise and internal PKI.

Chrome briefly offered an escape hatch for enterprises, the EnableSha1ForLocalAnchors policy, introduced in Chrome 54. It is gone. Chromium’s own documentation said it “will eventually be removed in the first Chrome release after January 1st 2019,” and it was. The same page warns that the policy had no effect anyway when the host operating system’s cryptographic library had already disabled SHA-1, in which case such certificates “will be unconditionally blocked.”

Put together, that means there is no supported configuration in which a current browser accepts a SHA-1 signed leaf or intermediate certificate, from any source, public or private. So when this error appears now, it is realistically one of the following:

• An internal Certificate Authority, often Microsoft AD CS, still signing with SHA-1 because nobody changed the defaults it was built with.
• A self-signed certificate generated years ago by a script that never specified a digest.
• A network appliance, printer, IPMI or iDRAC board, NAS, or industrial controller shipping a factory certificate from a firmware generation that predates the deadline.
• A device or virtual machine that was shelved years ago with its configuration frozen, and has just been brought back online.

If the site is genuinely public and you own it, the diagnosis is simpler still: your certificate is so old that it also expired years ago, and you need a current one. No CA can issue you a SHA-1 replacement even if you ask.

Diagnose it: read the signature algorithm out of the certificate

Before changing anything, confirm which certificate is signed with SHA-1. The browser tells you an algorithm is weak but not which link in the chain carries it, and OpenSSL answers that in one command.

Check a certificate file

If you have the certificate on disk, point OpenSSL at it:

openssl x509 -in certificate.crt -noout -text | grep -i "signature algorithm"

A healthy certificate returns something like this:

    Signature Algorithm: sha256WithRSAEncryption
    Signature Algorithm: sha256WithRSAEncryption

The value appears twice by design. It is stored once inside the signed body of the certificate and once alongside the signature itself, and the two must match, which is a check against tampering. A certificate that triggers this error shows sha1WithRSAEncryption or ecdsa-with-SHA1 instead. Anything in the SHA-2 family, such as sha256WithRSAEncryption, sha384WithRSAEncryption, or ecdsa-with-SHA256, is fine.

On Windows, without OpenSSL installed, the built-in equivalent is:

certutil -dump certificate.cer

Check what a live server sends

To read the certificate straight off a running server, without needing a copy of the file:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -i "signature algorithm"

The -servername flag sets the hostname sent via SNI, which is how a server hosting several sites on one IP address knows which certificate to return. Since OpenSSL 1.1.1 the tool fills that in from the address you passed to -connect, so the flag is explicit rather than strictly required. It is worth keeping when the hostname you want to test differs from the one you are connecting to.

Check every certificate in the chain

This is the check that actually settles it, because the weak signature may be on an intermediate rather than on your own certificate. The first command splits everything the server sends into separate files, the second prints the subject and signature algorithm of each:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | awk '/-----BEGIN/{f="cert" ++n ".pem"} f{print > f} /-----END/{close(f); f=""}'

for f in cert*.pem; do
  openssl x509 -in "$f" -noout -subject
  openssl x509 -in "$f" -noout -text | grep -m1 -i "signature algorithm"
done

Read the output from the top down. The first certificate is your leaf, the last is the root. Here is what a chain looks like when the root carries a SHA-1 self-signature but the site still works perfectly:

subject=CN=example.com
        Signature Algorithm: sha256WithRSAEncryption
subject=C=US, O=Example CA, CN=Example TLS Issuing CA
        Signature Algorithm: sha256WithRSAEncryption
subject=C=US, O=Example CA, CN=Example Root CA
        Signature Algorithm: sha1WithRSAEncryption

Nothing here needs fixing. The leaf and the intermediate are SHA-256, and the SHA-1 on the last line is the root signing itself, which browsers skip. If instead either of the first two lines reads sha1WithRSAEncryption, you have found your culprit.

Check it without the command line

For a publicly reachable site, run a scan with our free SSL Checker. It reports the signature algorithm along with the chain, the expiry date, and configuration problems the padlock icon will not show you. An internal host that the tool cannot reach has to be checked with the OpenSSL commands above.

How to fix the NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM error

Every route below ends in the same place: a new certificate signed with SHA-256. Which route you take depends on who issued the one you have.

1. A publicly trusted certificate: get a current one

There is no configuration step here. Request a reissue or a replacement from your Certificate Authority and install it. Every publicly trusted CA has signed with SHA-256 or stronger since 2016, so a new certificate solves the problem by default and there is no option to get it wrong.

You will need to submit a CSR (Certificate Signing Request) and pass validation again, the same process as renewing an SSL certificate. Our CSR generation tutorials cover the exact commands per platform.

A certificate signed with SHA-1 is also long past its expiry date, so whatever process was supposed to replace it has not run in years. Fixing that process matters as much as reissuing the certificate, and ACME certificate automation is the reliable way to do it.

2. A self-signed certificate: regenerate it with SHA-256

Old OpenSSL builds defaulted to SHA-1, which is how most of these certificates came to exist. Regenerating with an explicit -sha256 flag fixes it:

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 -nodes \
  -keyout server.key -out server.crt -subj "/CN=server.internal" \
  -addext "subjectAltName=DNS:server.internal" \
  -addext "basicConstraints=critical,CA:FALSE" \
  -addext "extendedKeyUsage=serverAuth"

The three -addext options are not optional extras. Without them the command still produces a SHA-256 certificate, but one that fails in other ways. A certificate with no Subject Alternative Name is rejected on the hostname, because clients match against that field and ignore the Common Name. A certificate left marked as a CA, which is what this command does by default, is one Firefox refuses to accept as a server certificate. And macOS requires extendedKeyUsage to be present before it will treat a certificate as valid for server authentication.

Install the new server.crt and server.key in place of the old pair, restart the service, and confirm with the file check above. Be aware that a self-signed certificate solves the weak signature but not trust: browsers will still warn that the issuer is unknown, which is a different error covered in our guides to MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT and NET::ERR_CERT_AUTHORITY_INVALID.

3. An internal Certificate Authority: change the CA’s hash algorithm, then reissue

If an internal CA signs with SHA-1, fixing one certificate is not enough, because the next one it issues will be SHA-1 too. Change the CA first.

On a Microsoft AD CS server, run these from an elevated command prompt on each CA in the hierarchy:

certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvc
certutil -getreg ca\csp\CNGHashAlgorithm

Two things to understand about this change. It applies only to certificates issued after it, so every existing certificate keeps its SHA-1 signature until it is re-enrolled. And it does not re-sign the CA’s own certificate: to move a subordinate CA certificate to SHA-256 you renew it from the parent, and for a root you renew with the same key from the Certification Authority console.

Work top down. Renew the issuing CA certificates first, then re-enroll the server certificates underneath them, then verify each one with the chain check above. If the root’s self-signature stays SHA-1 after all this, leave it. As covered earlier, browsers do not look at it.

For a private CA managed with OpenSSL instead, the equivalent is passing the digest when you sign. One thing to watch: signing with x509 -req does not carry extensions over from the CSR, so on its own it produces a certificate with no Subject Alternative Name, and browsers reject that on the hostname no matter how it was signed. Put the extensions in a small file first:

cat > server.ext <<'EOF'
subjectAltName = DNS:server.internal
basicConstraints = critical,CA:FALSE
extendedKeyUsage = serverAuth
EOF

Then sign the request against that file:

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -sha256 -days 365 -extfile server.ext -out server.crt

If you sign through openssl ca, set default_md to sha256 in the configuration file so the default applies to everything issued from then on.

4. A weak intermediate: install the correct chain

If the chain check flags an intermediate rather than your leaf, your own certificate is fine and the bundle installed next to it is stale. Download the current intermediate bundle from your CA and replace the one on the server, then restart the service.

There is a deadline attached to this one. Under CA/Browser Forum ballot SC-097, the Baseline Requirements retire all remaining use of SHA-1 in certificates and CRLs as of September 15, 2026, and require CAs to revoke any unexpired subordinate CA certificate still carrying a SHA-1 signature before that date. If a publicly trusted intermediate in your chain is the one flagged, it is on its way to being revoked regardless, so replace the bundle now rather than waiting for the revocation to break the site a second way.

This happens most often on servers that were migrated by copying files across, carrying a bundle assembled a decade ago along with them. Our guide to the expired intermediate SSL certificate error covers the same class of problem.

5. An appliance or device you cannot reissue from

Hardware with a factory certificate is the hardest case, and worth being direct about. Try, in order:

1. Update the firmware. Vendors that are still shipping updates replaced their SHA-1 certificate generation years ago, and a firmware update commonly regenerates the device certificate on first boot.
2. Regenerate the certificate from the device’s own admin interface. Many appliances have a “regenerate certificate” action that will produce SHA-256 once the firmware is current.
3. Upload your own certificate. If the device accepts a custom certificate, issue one from your internal CA and install it.
4. Put a reverse proxy in front of it. Terminate TLS on a proxy with a modern certificate and let it reach the device on the back end. This keeps browsers happy while the weak certificate stays off the network path they see.

If none of those are possible, the device is out of support and the honest answer is that it needs replacing. A management interface no browser will open is on a short clock regardless of this particular error.

What does not fix this error

A lot of advice about this error is copied from generic browser troubleshooting lists, and none of it can work here. The signature algorithm is a fixed property of a file the server sends. No setting on the visitor’s machine reaches into that file and rewrites it. Specifically:

• Correcting the date and time does nothing. A wrong clock causes a different error, NET::ERR_CERT_DATE_INVALID, because it makes a valid certificate look expired or not yet valid. It has no bearing on which hash function signed the certificate. If your clock is genuinely wrong, fix it, but expect a different error message to be the one that clears.
• Clearing the SSL state (the Clear SSL state button in Windows Internet Properties) only empties a cache of client certificate selections and cached validation results. Re-fetching the same certificate produces the same SHA-1 signature and the same error.
• Clearing the browser cache discards stored pages and cookies. Certificates are exchanged fresh on every TLS handshake and are not served from that cache.
• Resetting network settings or flushing DNS changes how your machine finds and routes to the server. It has no effect on what the server sends once it is found.
• Disabling antivirus or firewall software is worth a moment’s thought only in one narrow case: some security products intercept HTTPS by reissuing certificates locally. If such a product signs with SHA-1, it, and not the website, is the source. Check by comparing the issuer in your browser against the real one. Otherwise, leave your protection enabled.

Updating your browser deserves its own note, because the usual advice has it backwards. An outdated browser is not what causes this error, it is what prevents it. SHA-1 was accepted until Chrome 56 in early 2017, so a browser old enough to still allow it would load the site without complaining. Updating can only make the error more likely to appear, never less. Keep your browser current for every other reason, but do not expect it to clear this warning.

Finally, do not click through the warning and do not leave the certificate in service while you decide. Chrome may offer Advanced and a proceed link, and on a site protected by HSTS it will not offer even that. Either way, proceeding means accepting a certificate whose signature can be forged, which is precisely the attack the check exists to stop. It also hides the problem from you while leaving every other visitor blocked.

If you are visiting someone else’s site and see this error, there is nothing on your side to change. Report it to the site owner.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors, including Your Connection Is Not Private and NET::ERR_CERT_SYMANTEC_LEGACY.