SSL and HTTPS Problems

NET::ERR_CERT_AUTHORITY_INVALID (Website Repair)

Advanced Risk: medium

Last reviewed August 16, 2026

Hosting access may not be needed Database access usually not needed

Direct answer

NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID means Chrome cannot build a trusted certification path from the certificate your server presented to a root authority in the device’s trust store; install a publicly trusted certificate with the correct intermediate chain, or deploy the private CA root only to devices you intentionally manage.

This error is about certificate trust, not certificate dates or hostname coverage. Public sites most often serve a self-signed certificate, an origin-only certificate, or an incomplete chain after a migration. This Website Repair guide identifies which certificate visitors receive, restores the complete chain, and keeps private development trust out of public production.

Advanced

Key facts

Verifiable numbers and definitions — each claim links to its source.

Chrome groups certificate-authority failures under privacy/certificate errors and warns users not to proceed when the connection cannot be privately authenticated. (Google Chrome Help — common errors)
Let’s Encrypt explains that a server presents its end-entity certificate with one or more intermediates so a browser can validate signatures up to a root it trusts. (Let's Encrypt — Chains of Trust)
Cloudflare documents Origin CA certificates for encryption between Cloudflare and an origin server, while direct browser connections to that origin can show an untrusted-certificate error. (Cloudflare — Origin CA)

What the error means

TLS trust works as a chain: the site presents its leaf certificate and the intermediate certificates needed to connect it to a root certificate already trusted by the client. If Chrome cannot construct and verify that path, it reports NET::ERR_CERT_AUTHORITY_INVALID. A leaf can have correct dates and the exact hostname yet still fail because it was self-signed, issued by a private enterprise CA, installed without its intermediate bundle, or replaced in transit by antivirus or corporate TLS inspection. Cloudflare Origin CA certificates add another common trap: they are designed for the encrypted Cloudflare-to-origin connection and are not generally trusted by browsers connecting directly. This differs from NET::ERR_CERT_DATE_INVALID, which fails time validity, and name mismatch errors, which fail hostname identity.

Common symptoms

Chrome shows “Your connection is not private” with NET::ERR_CERT_AUTHORITY_INVALID
Certificate viewer lists an issuer the browser does not recognize or says the issuer is unknown
The site works through a CDN but fails when visitors or monitors connect directly to the origin
Some managed office devices work while personal phones and external checkers reject the certificate
A certificate checker reports an incomplete chain or missing intermediate
The warning began after a server migration, certificate renewal, proxy change, or manual PEM install
Local development uses a self-signed certificate that was accidentally deployed to production

Most likely causes

01 A self-signed certificate is installed on a public website
02 The web server serves the leaf certificate without one or more required intermediates
03 A private enterprise or development CA issued the certificate but its root is not trusted on visitor devices
04 A Cloudflare Origin CA certificate is exposed directly to browsers instead of only to Cloudflare
05 The wrong certificate bundle or virtual-host configuration was installed during migration
06 Antivirus, captive portal, firewall, or corporate TLS inspection substitutes a certificate from an untrusted local issuer
07 An outdated device trust store cannot recognize the chain offered by the site

What changed before the problem started

Certificate files were manually renewed or copied to a new web server
The fullchain file was replaced with a leaf-only certificate
Cloudflare proxying was disabled, exposing an origin-only certificate
A reverse proxy, load balancer, or hosting panel began terminating TLS
A local CA or self-signed development certificate reached production
Security software or a managed network enabled HTTPS inspection

Troubleshooting steps

01
Inspect the certificate actually presented
Open certificate details from the warning or use an external TLS checker. Record subject, issuer, serial/fingerprint, and every certificate in the served chain. Test the exact apex, www, and subdomain that fails. Success signal: you know whether the browser received a public, private, self-signed, or origin-only certificate.
02
Compare another device and network
Test a current phone on cellular data and a second browser. If only one managed computer or network fails, inspect its clock, root store, antivirus, captive portal, and TLS inspection before changing production. Success signal: the failure is classified as server-wide or client/network-specific.
03
Obtain a certificate from a publicly trusted CA
For a public site, issue through the host’s AutoSSL, Let’s Encrypt, or another browser-trusted CA after domain validation. Do not make a self-signed certificate public. Success signal: the new leaf names the live host and chains toward a recognized root.
04
Install the complete certificate chain
Configure the web server or panel with the CA-provided full chain, not only the leaf PEM. For Let’s Encrypt clients this is commonly the fullchain output. Reload the TLS terminator safely. Success signal: an external checker can build the path without fetching a missing intermediate.
05
Keep CDN origin certificates behind the proxy
If using Cloudflare Origin CA, ensure proxied DNS stays enabled and browsers receive Cloudflare’s edge certificate. If the origin must be directly reachable, install a publicly trusted certificate there instead. Success signal: both intended paths present certificates appropriate to their clients.
06
Retest without bypasses
Use a private window and external device to load every critical hostname. Confirm no interstitial, correct issuer and SANs, and a complete path. Remove temporary browser exceptions used during diagnosis.

Inspect the certificate actually presented

Open certificate details from the warning or use an external TLS checker. Record subject, issuer, serial/fingerprint, and every certificate in the served chain. Test the exact apex, www, and subdomain that fails. Success signal: you know whether the browser received a public, private, self-signed, or origin-only certificate.

Compare another device and network

Test a current phone on cellular data and a second browser. If only one managed computer or network fails, inspect its clock, root store, antivirus, captive portal, and TLS inspection before changing production. Success signal: the failure is classified as server-wide or client/network-specific.

Obtain a certificate from a publicly trusted CA

For a public site, issue through the host’s AutoSSL, Let’s Encrypt, or another browser-trusted CA after domain validation. Do not make a self-signed certificate public. Success signal: the new leaf names the live host and chains toward a recognized root.

Install the complete certificate chain

Configure the web server or panel with the CA-provided full chain, not only the leaf PEM. For Let’s Encrypt clients this is commonly the fullchain output. Reload the TLS terminator safely. Success signal: an external checker can build the path without fetching a missing intermediate.

Keep CDN origin certificates behind the proxy

If using Cloudflare Origin CA, ensure proxied DNS stays enabled and browsers receive Cloudflare’s edge certificate. If the origin must be directly reachable, install a publicly trusted certificate there instead. Success signal: both intended paths present certificates appropriate to their clients.

Retest without bypasses

Use a private window and external device to load every critical hostname. Confirm no interstitial, correct issuer and SANs, and a complete path. Remove temporary browser exceptions used during diagnosis.

When to stop troubleshooting

Escalate when you cannot identify which proxy terminates TLS, do not control the certificate or DNS account, the private CA root may be compromised, a payment or login site is being intercepted unexpectedly, or the correct full chain still fails across current external devices. Provide the hostname, issuer, fingerprints, served chain, network comparisons, and recent migration details.

Information to collect before requesting help

01 Exact Chrome error and failing hostname
02 Leaf subject, issuer, serial number, and SHA-256 fingerprint
03 Full list and order of certificates presented by the server
04 Whether apex, www, and subdomains differ
05 Results from a current external device and cellular network
06 CDN, load balancer, reverse proxy, and origin TLS layout
07 Certificate source: AutoSSL, Let’s Encrypt, commercial CA, private CA, or Cloudflare Origin CA
08 Recent renewal, migration, proxy, antivirus, or firewall changes

How a professional repairs the problem

Rescue 404 traces the certificate from browser to edge, proxy, and origin, identifies the untrusted or missing link, and installs the correct CA-issued full chain at the TLS endpoint visitors actually reach. We separate local interception from server faults, preserve strict validation, test every hostname externally, and repair renewal deployment so the next certificate does not regress to a leaf-only bundle.

Frequently asked questions

Is NET::ERR_CERT_AUTHORITY_INVALID the same as an expired certificate? +

No. Authority invalid means the trust path cannot reach a trusted root. Expiry is a date failure and normally maps to NET::ERR_CERT_DATE_INVALID.

Can the certificate be valid but the chain still be broken? +

Yes. The leaf can have correct dates and hostname while the server omits the intermediate certificate Chrome needs to connect it to a trusted root.

Why does the site work behind Cloudflare but not at the origin IP? +

The browser sees Cloudflare’s publicly trusted edge certificate through the proxy. Direct origin access may expose a Cloudflare Origin CA certificate that is intended for Cloudflare, not public browser trust.

Should visitors install my self-signed root certificate? +

Not for a public site. Use a publicly trusted CA. Private roots belong only on managed internal devices where you control policy and protect the CA.

Why does only my work computer show the error? +

Corporate inspection, antivirus HTTPS scanning, a captive portal, or a damaged local trust store may be replacing or rejecting the certificate. Compare the issuer and fingerprint on another network.

Will reinstalling WordPress fix the certificate authority error? +

No. TLS is normally terminated by the CDN, proxy, or web server before WordPress runs. Fix the certificate and chain at that layer.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

You will receive a clear explanation of the likely cause.
We will tell you if the issue falls outside our repair scope.
No additional work will be performed without approval.
A backup should be created whenever access and website condition allow it.

Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.