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 Invalid and the site shows a Security problem badge. The Security card reads "Something's wrong with your certificate — it looks damaged or uses outdated security."
• Visitors see a browser warning page, often without a specific error code (browsers vary in how they label this)
• openssl verify -untrusted fullchain.pem fullchain.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, and the signature proves the issuer signed it. If a browser can't verify the signature (because the signature data is corrupted, the algorithm isn't supported, or the issuing certificate doesn't match), it refuses to trust the certificate and turns visitors away. This is rarer than the other SSL issues. The usual cause is a configuration accident or a deprecated algorithm rather than active tampering.

Common causes

• The certificate uses a deprecated signature algorithm. All major browsers have distrusted SHA-1 signed certificates 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 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 an algorithm issue.

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 -untrusted fullchain.pem fullchain.pem again. It should return OK.
3. Open the site in an incognito window. The padlock should appear with no warnings.
4. Open the site in DomainDash. The next scheduled SSL check (every 6 to 24 hours, depending on your plan) picks up the new certificate, marks it Valid and clears the Security problem badge. If the problem had also taken the site Down, DomainDash re-checks the certificate as soon as the site recovers, so the badge clears within minutes.

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