# NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM: SHA-1 or MD5 signature

> NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM means the certificate or an intermediate is signed with SHA-1 or MD5. Reissue it with SHA-256 or better.

Source: https://ssl.sh/errors/net-err-cert-weak-signature-algorithm/
Last updated: 2026-11-10

**NET::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](https://ssl.sh/tools/ssl-checker/):

```bash
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:

```bash
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](https://ssl.sh/tools/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):

```bash
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](https://ssl.sh/tools/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](https://ssl.sh/tools/certificate-decoder/): every certificate except the root should show `sha256WithRSAEncryption` or an ECDSA-SHA256/384 signature.