Certificate signed by an untrusted authority

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

Symptom

• DomainDash marks the SSL check as Invalid, the certificate's Chain shows as Not trusted, and the site shows a Security problem badge. The Security card reads "Your certificate can't be verified as trustworthy. It may be missing part of its chain."
• 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. A self-signed certificate has no chain at all. Here you have a chain, but it doesn't lead anywhere browsers trust.

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) in place of the leaf alone, which is a one-line config change.

Common causes

• The intermediate certificate is missing from your server config. Many CAs issue a separate intermediate certificate (sometimes two) that has to be served alongside the leaf. Point your web server at a file containing the leaf followed by the intermediate(s). For Let's Encrypt that's fullchain.pem. 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 RSA and ECDSA intermediates). 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

People search for these cases by name. Both are the missing-intermediate issue described above.

• 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. A .NET client builds the chain from scratch, so it fails where a browser with a cached intermediate loads fine. 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, your server is fine and the client's trust store is missing the root.

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 an independent check. A "Chain issues" warning means there's still a problem.
3. Open the site in an incognito window. The padlock should appear with no warnings.
4. Open the site in DomainDash and open the Security page. After the next scheduled SSL check (every 6 to 24 hours, depending on your plan), the certificate's Chain should read Trusted, the SSL status should change from Invalid to Valid with a recognised issuer under Issued by, and the Security problem badge clears. If the problem had also taken the site Down, DomainDash re-checks the certificate as soon as the site recovers, so this happens within minutes.

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