ERR_CERT_AUTHORITY_INVALID means the browser read your certificate successfully but could not trace it back to a certificate authority it trusts. The certificate is not expired, not for the wrong hostname, and not corrupt. The chain leading from it to a trusted root is broken, and on a public website the overwhelmingly common reason is that the server is not sending the intermediate certificate.
This article explains the trust chain the browser is trying to build, gives you the three questions that identify which kind of failure you have, covers the server-side fix that resolves most cases, and explains why this error has a reputation for appearing on some devices while working perfectly on others.
What the browser is actually checking
A certificate on its own proves nothing. What makes it trustworthy is a chain: your certificate is signed by an intermediate certificate, the intermediate is signed by a root certificate, and the root is one of a few hundred that ship pre-installed in every operating system and browser. The browser walks that chain from your certificate upward, and if it reaches a root in its own trust store, the connection is trusted. If the walk stops before reaching a trusted root, you get this error.
There are only three ways the walk can stop. The certificate is self-signed, so there is no chain at all. The chain is incomplete, because the server sent your certificate but not the intermediate that links it to the root. Or the chain terminates at a root the browser does not trust, which happens with private internal certificate authorities, with roots that have been distrusted by browser vendors, and with security software that intercepts traffic using a root of its own. Everything else you might read about this error is a variation on one of those three. For the wider family of certificate problems and how they differ, our guide to SSL errors covers what each one is telling you.
The three questions that identify your case
Is the certificate self-signed? If you generated it yourself with OpenSSL for a development environment, an internal tool, or a device on your own network, the error is correct behaviour rather than a bug. Browsers are supposed to distrust certificates that vouch for themselves. The options are to install the certificate in the trust store of the machines that need it, to use an internal certificate authority whose root you distribute through device management, or to get a publicly trusted certificate from a real authority, which is free and takes minutes.
Does it work in one browser but not another? This is the signature of a missing intermediate. Some clients cache intermediate certificates they have seen before, and some fetch a missing one automatically using the authority information access field. Others do neither. The result is a certificate that works flawlessly on the developer's laptop, which has encountered that intermediate a hundred times, and fails on a customer's fresh phone, which has never seen it. Any bug report of the form it works for me on a certificate problem should be treated as a missing intermediate until proven otherwise.
Does it fail only on corporate or managed devices? Antivirus products and corporate network appliances that inspect HTTPS traffic do so by issuing their own certificates from their own root, which is installed on managed machines. When that root is missing or misconfigured on a particular device, every HTTPS site fails with this error rather than one site failing. Failure everywhere points at the device; failure on one site points at that site.
Fixing the missing intermediate
The fix is to configure the server to send the full chain rather than only the end certificate. Certificate authorities issue a bundle for exactly this purpose, and the correct file is the one containing your certificate followed by any intermediates, in that order, with the root omitted because clients already have it. In nginx this is the file referenced by the certificate directive, which should be the combined chain rather than the certificate alone. In Apache the chain historically lived in its own directive, and in current versions the certificate file itself is expected to contain the chain. Load balancers, CDNs, and managed platforms each have their own field for it, usually labelled certificate chain or bundle.
The reason this mistake is so common is that nothing appears to be wrong after you make it. The certificate installs, the padlock appears in your browser, and the site works. The incomplete chain only surfaces on clients that cannot paper over it, which means the error reaches your customers before it reaches you. This is precisely what a third party checker is for. Running the hostname through our SSL checker shows you the chain as a neutral client receives it, with nothing cached and nothing assumed, which is the only view that tells you the truth about what your server is sending.
The cases where the error is doing its job
It is worth saying plainly that this error is often correct. A browser refusing to trust a certificate it cannot verify is the entire security model working as designed, and the instinct to click past it or to disable the check is the instinct that makes interception attacks possible. When you see this error on a site you do not control, on public wifi, or on a network you do not fully trust, the appropriate response is to stop rather than to proceed.
The internal case deserves a different answer than the public one. Organisations running internal services on private certificate authorities should distribute the root through device management so that trust is established once, centrally, rather than by asking every employee to click through a warning. Teaching a workforce to ignore certificate errors on internal tools is how they learn to ignore them everywhere. If a service needs to be reachable from unmanaged devices, it needs a publicly trusted certificate, and the cost of one is now zero.
Common mistakes in fixing ERR_CERT_AUTHORITY_INVALID
Testing only in your own browser. Your machine may have cached the intermediate your server is failing to send. A certificate that works for you and fails for customers is almost always an incomplete chain rather than an intermittent fault.
Installing the certificate without the bundle. Certificate authorities supply the chain file for a reason. Configuring the server with the end certificate alone is the single most common cause of this error on public sites.
Including the root certificate in the chain. Clients already hold the roots they trust. Sending it adds bytes to every handshake and can confuse some validation paths, so the chain should stop at the last intermediate.
Telling users to click through the warning. Training people to bypass certificate errors removes the protection the error exists to provide. Fix the chain, or distribute an internal root properly, rather than normalising the bypass.
Assuming a free certificate is the problem. Certificates from free authorities are trusted by the same root stores as paid ones. If a free certificate produces this error, the chain configuration is wrong, not the certificate.
FAQ
What is the difference between ERR_CERT_AUTHORITY_INVALID and an expired certificate error?
Expiry produces a different message, because the browser understood the certificate and found it out of date. This error means the browser could not establish that the certificate came from an authority it trusts at all, which is a chain problem rather than a date problem.
Why does the site work on my laptop but not on my phone?
Your laptop has probably cached the intermediate certificate from a previous visit to another site using the same authority, while the phone has not. That difference points at an incomplete chain being sent by the server.
Can I fix this from the visitor's side?
Only when the cause is local, such as a wrong system date, an out of date device trust store, or security software intercepting traffic with its own root. If the server is sending an incomplete chain, the fix belongs to whoever runs the server.
Does a self-signed certificate always cause this error?
For any client that has not explicitly been told to trust it, yes. Self-signed certificates are perfectly usable for internal and development purposes provided the certificate or its issuing root is installed in the trust stores of the machines that need it.
Closing thought
Almost every public instance of this error is the same mistake: a server sending its certificate without the intermediate that proves where it came from. The reason it survives so long in production is that it does not fail for the person who installed it, and a problem that spares its author is a problem that reaches customers first. Check the chain from outside, every time, on every certificate you deploy.
That principle extends past the day of installation. Chains change when authorities rotate intermediates, renewals occasionally reinstall a certificate without its bundle, and a configuration that was correct in March can be wrong in September. Odown revalidates your certificates on a daily cycle and alerts on expiry at thirty, ten, and seven days out, watching the chain and the date rather than trusting a check you ran once. If a broken chain should reach you before it reaches your customers, SSL monitoring is included from twelve dollars a month with a fourteen day trial and no card required.
