Originally published on the Bug Circuit blog.
If your own website shows NET::ERR_CERT_AUTHORITY_INVALID, the cause is on your server, not your visitor's browser — and it's almost always one of three things: a missing intermediate certificate, a Let's Encrypt renewal that silently failed, or the wrong certificate installed for that domain. All three are fixable in under 30 minutes without special tools.
Who this is for
This is written for the person who owns the site — not a visitor wondering whether it's safe to click "Advanced" and proceed. If that's you, skip the reassurance and go straight to the diagnosis below. You'll come away knowing exactly which of the three causes you have and the commands or settings to fix it, whether you're running WordPress on shared hosting, a Shopify custom domain, or your own Nginx/Apache server.
What this error actually means
Every SSL/TLS certificate is issued by a Certificate Authority (CA) — a company like Let's Encrypt, DigiCert, or Sectigo that browsers agree to trust. NET::ERR_CERT_AUTHORITY_INVALID means Chrome couldn't verify that chain of trust: either it can't find the CA that supposedly issued your certificate, or the certificate is self-signed (issued by your own server, not a real CA). Google's own explanation of Chrome connection errors covers this family of warnings and why the browser blocks the page instead of just showing a note (Chrome Help: Fix connection errors).
This is different from a hostname mismatch, which throws NET::ERR_CERT_COMMON_NAME_INVALID instead — more on that below, since owners often mix the two up after a migration.
Cause 1: Missing intermediate certificate
This is the most common cause by far. Your certificate isn't signed directly by a root CA that's built into every browser — it's signed by an intermediate certificate, which is in turn signed by the root. If your server only serves your certificate and skips the intermediate, browsers and command-line tools can't complete the chain, even though the certificate itself is perfectly valid.
How to check:
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
If this hangs, errors, or a fuller openssl s_client run reports Verify return code: 21 (unable to verify the first certificate), your chain is incomplete.
How to fix it:
-
Nginx — your config must point to the fullchain file, not the bare certificate:
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;(notcert.pem). Reload withsudo nginx -t && sudo systemctl reload nginx. -
Apache — make sure
SSLCertificateChainFile(older Apache) or a combinedSSLCertificateFilethat includes the intermediate is set, then runsudo apachectl configtest && sudo systemctl reload apache2. - cPanel / shared hosting — go to WHM → SSL/TLS → Install an SSL Certificate and paste the full bundle your CA gave you (certificate + intermediate), or simply re-run AutoSSL under WHM → Manage AutoSSL.
- Managed WordPress hosts (SiteGround, Kinsta, WP Engine, Bluehost) — toggle SSL off and back on in the hosting dashboard. These hosts manage the chain for you, and forcing a re-issue usually clears it within minutes.
Cause 2: Your Let's Encrypt certificate didn't renew
Let's Encrypt certificates are only valid for 90 days by design, specifically so renewal gets automated instead of forgotten (Let's Encrypt: why ninety-day lifetimes). If the renewal cron job or systemd timer silently broke — a common cause is a firewall change, a moved webroot, or a full disk — the old certificate simply expires and the browser correctly refuses it.
How to check:
sudo certbot certificates
This lists every certificate Certbot manages and its expiry date. If it's expired or marked "INVALID," that's your answer.
How to fix it:
- Run a dry run first so you don't hit issuance rate limits:
sudo certbot renew --dry-run - If that succeeds, renew for real:
sudo certbot renew - Reload your web server:
sudo systemctl reload nginx(orapache2) - Confirm the renewal timer is actually active:
systemctl list-timers | grep certbot
On shared hosting you likely don't run Certbot yourself — the host does. Contact support or re-trigger the SSL section of your control panel; a stuck AutoSSL job is the shared-hosting equivalent of a broken cron job.
Cause 3: Wrong certificate for the domain (a related, easily confused error)
If you recently migrated hosts, added www, or moved to a new server, and the installed certificate doesn't actually list your current domain, Chrome shows NET::ERR_CERT_COMMON_NAME_INVALID — a sibling error, not the same one, but people search for them interchangeably. This is exactly the "connection not private after renewing hosting" scenario: the new host issued a certificate before DNS had fully pointed at it, or issued one for the wrong subdomain, and visitors end up seeing a certificate meant for a different server.
How to check: open your site in Chrome, click the "Not secure" warning, then "Certificate is not valid," and compare the domain names listed on the certificate to the domain in your address bar.
How to fix it:
- Confirm DNS is fully propagated to the new host before re-issuing (
dig yourdomain.comshould return the new host's IP everywhere you check). - Re-issue the certificate explicitly for every hostname you serve, including both
yourdomain.comandwww.yourdomain.comif visitors reach both. - Check for a CAA DNS record blocking issuance — if one exists, it must explicitly allow your CA, e.g.
yourdomain.com. CAA 0 issue "letsencrypt.org".
Cause 4: A leftover self-signed or staging certificate
If a developer, migration script, or a default Nginx/Apache install left a self-signed certificate active — or you tested with Let's Encrypt's staging environment and forgot to switch to production — the certificate is technically valid but issued by something no browser trusts. Re-issue a real production certificate and remove the placeholder; there's no configuration fix for a self-signed cert other than replacing it.
Quick diagnostic checklist
- [ ] Run the
openssl s_clientcommand above — does the chain complete without errors? - [ ] Run
sudo certbot certificates(or check your host's SSL panel) — is the certificate expired? - [ ] Open the certificate details in Chrome — does the "Issued to" domain match your actual domain?
- [ ] Check the "Issued by" field — is it a real CA (Let's Encrypt, DigiCert, Sectigo) or does it show your own server name?
- [ ] Check DNS with
dig— does your domain currently point at the server you believe issued the certificate?
| Symptom | Likely cause | Fastest fix |
|---|---|---|
Verify return code: 21 in openssl |
Missing intermediate cert | Serve fullchain.pem, not cert.pem
|
| Certificate expired today or recently | Failed Let's Encrypt renewal |
certbot renew, check the systemd timer |
| Certificate lists a different domain | Wrong cert for new host/domain | Re-issue after DNS fully propagates |
| Issuer shows your own server name | Self-signed/staging leftover | Replace with a real production cert |
After you fix it: confirm it actually worked
Don't just trust that your own browser stopped complaining — it may have cached the old certificate. Test from a clean environment with the Qualys SSL Labs test, which shows the full chain, expiry, and any remaining issues a browser would catch. It's free and doesn't require an account.
While you're checking your site's security setup, it's worth a broader pass — a missing intermediate certificate is exactly the kind of small, easy-to-miss configuration gap that tends to show up alongside other issues, like missing security headers. Our free website security headers checker flags those in about ten seconds, and our guide to spotting hackable configuration issues covers the other common gaps we see on small business sites.
Key takeaways
- NET::ERR_CERT_AUTHORITY_INVALID means the browser can't verify who issued your certificate — check the chain, the expiry date, and the domain it was issued for, in that order.
- A missing intermediate certificate is the single most common cause; make sure your server serves
fullchain.pem(or the equivalent combined bundle), not the bare certificate. - Let's Encrypt certificates expire every 90 days on purpose — confirm
certbot renew --dry-runactually succeeds and the renewal timer is running, rather than assuming it is. - After a host migration, re-issue the certificate only once DNS has fully propagated, and cover every hostname (
wwwand non-www) your visitors actually use. - Verify the fix with an independent tool like SSL Labs, since your own browser may still be showing you a cached, broken certificate.
If you'd rather have a human double-check the whole setup — not just the certificate, but the configuration issues that tend to travel with it — a Circuit audit is a one-time $49 manual review of your entire site with a full written report, or run a free passive check first if you just want a quick yes/no on anything critical.
