Certificate signature is invalid

The cryptographic signature on your SSL certificate failed verification. Browsers treat this as a serious trust failure and refuse to connect.

Symptom

• DomainDash marks the SSL check as Down with error code bad_signature
• Visitors see a browser warning page, often without a specific error code (browsers vary in how they label this)
• openssl verify -CAfile chain.pem cert.pem returns error 7 at 0 depth lookup: certificate signature failure

What it means

Each certificate is signed by its issuer using a cryptographic algorithm. The signature is the proof that the issuer really did sign it. If the signature can't be verified — because the signature data was corrupted, the algorithm isn't supported, or the issuing certificate doesn't actually match — browsers refuse to trust the certificate. This is rarer than the other SSL issues, and when it happens it's usually a configuration accident or a deprecated algorithm rather than active tampering.

Common causes

• The certificate uses a deprecated signature algorithm. SHA-1 signed certificates have been distrusted by all major browsers since 2017. If you have a very old certificate still in service, it may be served but rejected.
• Wrong intermediate served. The chain claims one issuer but the intermediate served doesn't actually have the matching key, so the signature on your leaf cert can't be verified.
• Certificate file corruption. Rare, but a damaged PEM file (truncated, corrupted during copy) can produce a cert that's structurally valid but whose signature data is wrong.
• Encoding issues. Some certificate exports between platforms (e.g. PFX → PEM via the wrong tool) can re-encode the signature in a way that invalidates it.
• Algorithm not supported by clients. Cutting-edge signature algorithms (e.g. Ed25519) may produce certs that work with some clients but fail signature verification on others. Less common in 2026 but still possible with strict clients.

How to fix

1. Identify the signature algorithm. Run:

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

   If you see sha1WithRSAEncryption, the algorithm is the problem.

2. Verify against the intermediate. Download your chain (typically fullchain.pem) and run:

   openssl verify -untrusted fullchain.pem fullchain.pem

   A failure here points to a chain issue rather than algorithm.

3. Re-issue with a modern algorithm. For Let's Encrypt with certbot:

   sudo certbot certonly --nginx -d example.com -d www.example.com --force-renewal --key-type ecdsa

   This produces an ECDSA-signed cert. (You can omit --key-type to keep the default RSA + SHA-256.)

4. If the cert file is corrupted, delete it and re-download from the CA or re-issue. Don't try to repair PEM files by hand.

5. For hosted providers, trigger a re-issue. Modern providers default to SHA-256 + RSA or ECDSA, which won't trip this error.

How to verify

1. Re-run the signature algorithm check from step 1. Confirm it's a modern algorithm (sha256WithRSAEncryption, ecdsa-with-SHA256, or stronger).
2. Run openssl verify -CAfile chain.pem cert.pem — should return OK.
3. Open the site in an incognito window — padlock should appear cleanly.
4. Click "Check now" in DomainDash. Status should flip to Healthy.

Related

• Certificate signed by an untrusted authority — different chain-of-trust issue
• Certificate has been revoked — explicit CA invalidation
• TLS handshake failed — generic TLS issues
• SSL certificates — how DomainDash checks SSL