What Chrome shows
The heading is the standard certificate warning, "Your connection is not private", with this paragraph underneath:
Attackers might be trying to steal your information from <SITE>
(for example, passwords, messages, or credit cards).
NET::ERR_CERT_AUTHORITY_INVALIDClick "Advanced" to reveal the code. This error is overridable, so a "Proceed to <SITE> (unsafe)" link is normally offered alongside "Back to safety".
The chain, and why it breaks
Browser trust works in a chain. Your browser ships with a list of root certificate authorities it trusts. Those roots are kept offline, so they do not sign website certificates directly. Instead they sign intermediate certificates, and the intermediates sign yours.
For the browser to trust your site, it has to follow that path: your certificate, then the intermediate, then the root it already knows. Your server is responsible for sending the intermediates along with your certificate. The root it already has.
If the server sends only your certificate, the chain stops one link short of anything the browser recognises. The certificate is completely genuine. Chrome still cannot verify it, so it treats the authority as unknown.
The four real causes
In order of how often we see them:
- →Missing intermediate certificate. Sometimes called "chain not served". The server was given only the site certificate instead of the full bundle. This is by far the most common cause and it is a five minute fix.
- →A self signed certificate. The certificate signs itself, so no authority vouches for it. Fine on a test server or a device on your own network, not fine on a public shop.
- →A private or company authority. Large organisations run their own internal authority and push its root out to company devices. On a company laptop the site works. On your own device it does not, because your browser has never heard of that root.
- →Antivirus or a workplace proxy inspecting traffic. Some security software decrypts and re inspects encrypted connections, then re signs them with its own certificate. If its root is not correctly installed, every site fails this way, including sites that are perfectly healthy.
Why it works for you but not for your visitors
This is the detail that wastes the most time.
When a chain is incomplete, some clients recover on their own. They may have cached the intermediate from another site, or they may fetch it automatically. So the site loads perfectly on your desktop and fails for a visitor on a phone, or fails on a payment provider that connects to your site from a server.
Never test this by loading your own site in your own browser. Test from outside, on a fresh device, or with a checker that makes a clean connection every time.
If it is your site: install the full chain
The chain is not something you generate. Your certificate authority gives it to you at issue time.
- 1.Go back to your certificate authority and download the full bundle, often named "fullchain", "chained", or offered as a separate "CA bundle" or "intermediate certificate" file.
- 2.Point your server at the right file. Apache uses SSLCertificateChainFile, or the chained file in SSLCertificateFile on newer versions. Nginx expects one file containing your certificate followed by the intermediates. Many control panels have a separate "CA bundle" box that people leave empty.
- 3.Reload the web server so it actually picks up the change. Editing the config alone does nothing.
- 4.Test from outside your own machine. Use the checker at the top of this page, or open the site on a phone using mobile data with a browser you have not used before.
- 5.If you use a CDN or load balancer, check each one. The chain has to be complete wherever the connection actually terminates, which may not be your origin server.
What our check reports
Our engine looks at the certificate the way a new visitor would, from outside, with no cached intermediates to rescue it. It reports the precise reason, including whether the certificate is not issued by a trusted authority, is self signed, has expired, or does not match this website address.
That is the difference between guessing and knowing. A self signed certificate and a missing intermediate produce the same Chrome code but need completely different fixes.
Frequently asked questions
Does this mean the site is fake?
Usually not. The most common cause is a server sending an incomplete certificate chain, which is a configuration mistake on an otherwise genuine site. Chrome cannot tell a misconfiguration from an impersonation, so it warns about the worst case. That said, until it is fixed the site's identity is unverified, so do not enter passwords or payment details.
Why do I only get this on my work laptop?
Company networks and some antivirus products inspect encrypted traffic by decrypting it and re signing it with their own certificate authority. Managed devices trust that authority, personal ones do not. If a site fails on the work laptop and works on your phone, the network or the security software is the cause, not the site.
My site works in my browser but visitors report this error. How?
Almost certainly a missing intermediate certificate. Your browser has probably cached the intermediate from another site, so it silently completes the chain for you. A first time visitor, or a phone, or a server to server connection has nothing cached and fails. Always test from outside your own machine.
Is a self signed certificate ever acceptable?
On something like a home router, a printer, or a development server, yes, because you already know who issued it. On a public website, no. Visitors have no way to verify it, and every one of them gets a full page warning. Free certificates from a trusted authority remove the problem entirely.
Can I click through to see the site?
Chrome does offer the option on this error, but treat it as a last resort. Proceeding means accepting a connection whose identity nobody has verified. Never do it on a site where you would type a password or card details. It is only reasonable on equipment you own and whose certificate you recognise.