How to Fix NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM in Google Chrome & Web Servers in Pakistan

When accessing an enterprise web portal, internal corporate dashboard, or government site in Google Chrome, users and systems engineers may be confronted by the strict security interstitial:

Your connection is not private
Attackers might be trying to steal your information from intranet.example.pk.
NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

Unlike certificate expiration warnings or hostname mismatches, NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM is an unequivocal cryptographic block. Chromium’s security architecture detected that either the server’s leaf certificate or an intermediate Certificate Authority (CA) in the trust chain was signed using a cryptographically broken hashing algorithm—typically SHA-1 (sha1WithRSAEncryption) or MD5 (md5WithRSAEncryption).

Following the practical demonstration of collision attacks against SHA-1 (such as the SHAttered attack), Google Chromium completely eliminated trust for weak hash algorithms. Any certificate issued or signed using SHA-1 or MD5 is rejected unconditionally.

In this guide, we audit your certificate chain with OpenSSL, identify the offending certificate in the hierarchy, and re-issue the credentials using SHA-256 or ECDSA P-256 on enterprise Dedicated Servers and Dedicated Servers in Pakistan.

---

1. Cryptographic Background: The Collapse of SHA-1

Digital certificates rely on cryptographic hash functions to generate digital signatures. The issuing Certificate Authority computes the hash of the certificate’s TBSCertificate (To-Be-Signed) structure and encrypts that hash using its private key.

+--------------------------------------------------------------+
|                     Certificate Chain                        |
|                                                              |
|  [Root CA: SHA-256]                                          |
|         | (Signs Intermediate)                               |
|         v                                                    |
|  [Intermediate CA: sha1WithRSAEncryption] <--- [BROKEN LINK] |
|         | (Signs Leaf)                                       |
|         v                                                    |
|  [Leaf Certificate: sha256WithRSAEncryption]                 |
+--------------------------------------------------------------+
Result: Chrome blocks with NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

Even if the leaf certificate was issued yesterday with SHA-256, if any intermediate certificate in the presented chain utilizes SHA-1, Chrome treats the entire chain as compromised.

---

2. Auditing the Live Certificate Chain with OpenSSL

To determine which certificate in the hierarchy is triggering the error, connect to the server using OpenSSL and print the signature algorithms of every link in the chain:

# Connect and dump the full presented certificate chain
openssl s_client -connect example.pk:443 -servername example.pk -showcerts </dev/null 2>/dev/null > /tmp/chain_dump.pem

Now, parse each certificate block in /tmp/chain_dump.pem:

awk -v c=0 '
  /-----BEGIN CERTIFICATE-----/ { c++ }
  c { print > ("/tmp/cert_" c ".pem") }
  /-----END CERTIFICATE-----/ { c=0 }
' /tmp/chain_dump.pem

# Inspect the signature algorithm of each extracted certificate
for f in /tmp/cert_*.pem; do
  echo "=== $f ==="
  openssl x509 -in "$f" -noout -subject -issuer
  openssl x509 -in "$f" -noout -text | grep "Signature Algorithm" | head -n 1
done

Look for any instance of:

• Signature Algorithm: sha1WithRSAEncryption
• Signature Algorithm: md5WithRSAEncryption

If either appears, that specific certificate must be retired and replaced immediately.

---

3. Re-Issuing Certificates with SHA-256 or ECDSA

Fixing OpenSSL Command Line Generation

If you are generating a Certificate Signing Request (CSR) for an enterprise service or internal PKI, explicitly declare -sha256 or -sha384:

# Generate 2048-bit or 4096-bit RSA Private Key
openssl genrsa -out /etc/ssl/private/example.pk.key 2048

# Generate CSR explicitly mandating SHA-256 hashing
openssl req -new -key /etc/ssl/private/example.pk.key -out /tmp/example.pk.csr -sha256 -subj "/C=PK/ST=Punjab/L=Lahore/O=Nextgen Systems/CN=example.pk"

To sign the certificate with your internal root CA using SHA-256:

openssl x509 -req -in /tmp/example.pk.csr \
    -CA /etc/ssl/ca/rootCA.pem \
    -CAkey /etc/ssl/ca/rootCA.key \
    -CAcreateserial \
    -out /etc/ssl/certs/example.pk.crt \
    -days 365 \
    -sha256 \
    -extfile /etc/ssl/ca/v3_ext.cnf

Upgrading Let’s Encrypt / Certbot Automated Chains

If using Certbot on Linux, older installations may still be serving legacy Cross-Signed intermediates (such as the expired IdentTrust DST Root CA X3 chain).

Update Certbot and force a renewal to the modern ISRG Root X1 chain:

certbot renew --force-renewal --preferred-chain "ISRG Root X1"

---

4. Modernizing Web Server SSL Configuration

In Nginx, ensure the virtual host points to the newly signed, SHA-256 certificate and intermediate bundle:

server {
    listen 443 ssl http2;
    server_name example.pk;

    # Point to modern fullchain with SHA-256 signatures
    ssl_certificate /etc/letsencrypt/live/example.pk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.pk/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5:!RC4;
}

Reload Nginx:

nginx -t && systemctl reload nginx

Once reloaded, test your endpoint with SSL Labs or OpenSSL:

openssl s_client -connect example.pk:443 -servername example.pk </dev/null 2>/dev/null | openssl x509 -noout -text | grep "Signature Algorithm"

It should now return: Signature Algorithm: sha256WithRSAEncryption or ecdsa-with-SHA256.

Compare this with other browser-level certificate diagnostics in our guides on Fixing NET::ERR_CERT_INVALID in Chrome and Fixing SEC_ERROR_OCSP_TRY_SERVER_LATER in Firefox.

---