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 Invalid with error code untrusted_root, and the certificate's Chain shows as Not trusted
• 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 and turns visitors away. This is different from a self-signed certificate: here, you have a chain, it just doesn't lead anywhere browsers trust.

By a long way, the most common cause is a missing intermediate certificate. Your server sends only the leaf certificate, so the client has nothing to build the chain up to a trusted root. Browsers that have cached the intermediate from another site may load fine while others (and command-line clients) fail, which is why the problem often looks intermittent. The fix is to serve the full chain (leaf plus every intermediate, concatenated in order) rather than the leaf alone. It's a one-line config change and is quick to put right.

Common causes

• The intermediate certificate is missing from your server config. This is the most common cause by far. Many CAs issue a separate intermediate certificate (sometimes two) that has to be served alongside the leaf certificate; if you only installed the leaf, the client can't build the chain to a trusted root and rejects it. The fix is to point your web server at a file containing the leaf followed by the intermediate(s). For Let's Encrypt that's fullchain.pem, and for other CAs you concatenate the leaf and the CA-supplied bundle yourself (see How to fix).
• 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

   For a CA that gives you separate files (most commercial CAs, including Network Solutions and InCommon), build the full-chain file yourself by concatenating the leaf followed by the intermediate bundle (order matters, leaf first):

   cat example.com.crt intermediate-bundle.crt > fullchain.crt

   Then point ssl_certificate at fullchain.crt (see step 4).

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.

Common "not trusted" cases

These are the cases people search for by name. They look like special problems but they're all the same missing-intermediate issue: the server isn't sending the certificate that links the leaf to the trusted root.

• Network Solutions certificate "not trusted". Network Solutions issues your certificate with a separate intermediate bundle (CA bundle). If you install the leaf but skip the bundle, the chain stops at the leaf and clients can't reach the root. Concatenate the Network Solutions intermediate bundle onto your certificate (leaf first) and serve the combined file, as in step 2.
• InCommon RSA Server CA "not trusted". InCommon (run through Sectigo) signs leaf certificates with the InCommon RSA Server CA intermediate, which chains up to a Sectigo/USERTrust root that browsers do trust. The warning appears when the server sends only the leaf and not the InCommon RSA Server CA intermediate. Add the InCommon intermediate to the chain you serve. The root itself is already trusted, so you don't need to touch client trust stores.

In both cases, inspect the served chain with the openssl s_client -showcerts command in step 1: if the i: (issuer) of your leaf names an intermediate that never appears as an s: (subject) further down, that intermediate is missing and needs adding.

"The certificate chain was issued by an authority that is not trusted"

This exact wording (The certificate chain was issued by an authority that is not trusted) comes from .NET and SQL Server clients (it's a Windows/SChannel message, surfaced by SqlException, HttpClient, and similar). It's the same missing-or-untrusted-chain problem seen from a .NET client rather than a browser, and it has two common causes:

• A missing intermediate on the server. This is exactly the case above. Browsers may have cached the intermediate and load fine while the .NET client, which builds the chain from scratch, fails. Fix it on the server by serving the full chain.
• A missing root in the Windows trust store. The chain is complete but the machine running the client doesn't trust the root. This happens with internal/private CAs and on minimal or older Windows images. Install the root into the Windows certificate store (Local Computer → Trusted Root Certification Authorities) on the client machine.

Check the served chain first with the step 1 command. If the chain is complete and ends in a well-known public root, the problem is on the client (missing root in the trust store), not your server.

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 and go to the Security tab. DomainDash re-checks on its normal schedule; once the next check runs, the certificate's Chain should read Trusted and the SSL status should flip from Invalid back to Valid, with a recognised issuer shown under Issued by.

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