Certificate signed by an untrusted authority

Your SSL certificate chains up to a root that browsers don't recognise. The certificate itself may be technically valid, but without a trusted root, browsers refuse the connection.

Symptom

• DomainDash marks the SSL check as Down with error code untrusted_root
• Visitors see a browser warning like NET::ERR_CERT_AUTHORITY_INVALID
• Running openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null shows a certificate chain that ends in a root your browser doesn't recognise, or an incomplete chain that doesn't end in a root at all

What it means

SSL certificates rely on a chain of trust: your server certificate is signed by an intermediate, which is signed by a root, and browsers ship with a list of root CAs they trust. If any link in that chain is missing or unrecognised, the browser can't verify your certificate. This is different from a self-signed certificate — here, you have a chain, but it doesn't lead anywhere browsers trust.

Common causes

• The intermediate certificate is missing from your server config. This is the most common cause. Many CAs issue a separate intermediate certificate that has to be installed alongside the leaf certificate; if you only installed the leaf, the chain is broken.
• The chain leads to a private or internal CA. Common in enterprise environments where an internal CA signs internal certificates. Fine for internal services, but breaks for anything public.
• A previously-trusted root has been distrusted. Browser vendors occasionally remove roots they no longer trust (this happened to several CAs after security incidents in recent years).
• The chain points to an old root that's been replaced. Some CAs cross-sign with a newer root; if your chain still references the old one, newer browsers may reject it.
• The certificate uses the wrong intermediate. Some CAs offer multiple intermediates (e.g. Let's Encrypt's R3 vs E1). If your server config references the wrong file or path, the wrong intermediate is served.

How to fix

1. Inspect the chain being served. Run:

   openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "^(Certificate chain|s:|i:|---)"

   You'll see each cert in the chain with s: (subject) and i: (issuer). The chain should end with a cert whose subject is a well-known root CA (Let's Encrypt ISRG Root X1, DigiCert, Sectigo, etc.).

2. If the chain is incomplete (only your leaf certificate is shown, with no intermediate), install the intermediate. For Let's Encrypt with certbot, the renewer normally installs the full chain automatically. If it didn't, re-issue:

   sudo certbot --nginx -d example.com -d www.example.com --force-renewal

3. If the chain ends at an unrecognised CA, you're using a non-public CA. Either switch to a public CA (Let's Encrypt is free), or — if this is an internal-only service — install the internal CA's root cert into your browsers (not a fix for public visitors).

4. Make sure the certificate file your web server references contains the full chain. For nginx:

   ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

   The fullchain.pem file contains both the leaf and intermediate; pointing at cert.pem alone is a common mistake.

5. For hosted providers, trigger a re-issue from the dashboard. Most will install the correct chain automatically.

How to verify

1. Re-run the chain inspection from step 1. Confirm the chain ends in a recognised root.
2. Use SSL Labs (https://www.ssllabs.com/ssltest/) for a thorough independent check. A "Chain issues" warning means there's still a problem.
3. Open the site in an incognito window — padlock should appear cleanly.
4. Open the site in DomainDash, go to SSL, and click "Check now". The status should flip from Down to Healthy — and the certificate card should show a recognised issuer in the chain.

Related

• Self-signed certificate — when there's no chain at all
• Certificate signature is invalid — chain is present but cryptographically broken
• Visitors see a security warning — symptom-driven entry point
• SSL certificates — how DomainDash checks SSL