How to Debug ERR_CERT_AUTHORITY_INVALID on a Reverse Proxy
Direct Answer: ERR_CERT_AUTHORITY_INVALID occurs when a client rejects a TLS certificate presented by a self‑hosted reverse proxy because the certificate’s trust chain cannot be validated—commonly caused by a missing or mismatched CA, expired intermediate, or a custom CA not trusted on the client side. This blocks secure connections until the chain is corrected and the CA is installed on the client.
Quick guide to diagnosing TLS trust failures when a self‑hosted reverse proxy presents an invalid certificate, with real‑world steps and tools.
One Tuesday at 02:30 UTC a pager went off. The error log read ERR_CERT_AUTHORITY_INVALID for every request to https://proxy.prod.example.dev/. The team had just upgraded the reverse proxy to a new version and added a custom CA for internal services. The client machines were laptops belonging to developers who never saw the CA installed.
How TLS Validation Works in Reverse Proxies
A reverse proxy terminates TLS, then re‑issues a new certificate to the client. The handshake begins with a ClientHello. The proxy sends its certificate chain: leaf, intermediates, and root. The client’s trusted root store validates each link. If any intermediate is missing, expired, or signed by an unknown CA, the validation stops and ERR_CERT_AUTHORITY_INVALID appears. The chain must be linear, each certificate must sign the next, and the final root must be present in the client’s trust store.
Typical Causes of ERR_CERT_AUTHORITY_INVALID
Missing intermediate CA – The proxy config omitted the intermediate that bridges leaf to root.
Expired intermediate – An intermediate with a Not After date before the client’s check.
Root CA not trusted – The custom CA used for internal services is not installed on the client.
Mis‑ordered chain – Leaf followed by root directly, skipping required intermediates.
Revoked intermediate – The intermediate appears on a CRL or the OCSP responder reports revocation.
Each cause produces the same error but requires a distinct remediation path.
Real Production Incident: Launch Day Outage (April 2023)
Our e‑commerce platform launched a new checkout service behind an Nginx reverse proxy. The team generated a CSR, obtained a Let’s Encrypt certificate, and added a custom internal CA for logging. The deployment script placed the intermediate in /etc/ssl/intermediate.pem but the Nginx config referenced only the leaf and the internal CA. Within minutes, developers connecting from home saw ERR_CERT_AUTHORITY_INVALID. The incident page recorded a 5‑minute window of lost transactions and 120 support tickets.
Root cause: The certificate chain was incomplete; Nginx presented leaf → internal CA, skipping the required Let’s Encrypt intermediate. The client’s trust store recognized the leaf but could not verify the internal CA. Resolution: added the Let’s Encrypt intermediate to the chain, restarted Nginx, and distributed the internal CA via Group Policy. All connections returned to normal after 12 minutes.
About the author
Admin SarangAI · AI Tools Editor
Part of the SarangAI editorial team covering AI tools, product releases, emerging technology trends, and practical web utilities for developers and creators.
Inspect the chain – Use the free SSL chain checker on https://proxy.prod.example.dev/. Expected result: a list of certificates with “OK” status for each link.
Identify missing intermediates – Run openssl s_client -connect proxy.prod.example.dev:443 -showcerts. Look for Verify return code: 21 (certificate revoked) or certificate chain errors. Expected result: clear indication of which intermediate is absent.
Add the intermediate – Edit Nginx ssl_certificate directive to include the intermediate file: ssl_certificate /etc/ssl/fullchain.pem; where the file concatenates leaf + intermediate + root. Reload Nginx: nginx -s reload. Expected result: reload succeeds and the proxy no longer reports chain errors.
Distribute the custom CA – Copy the internal CA PEM to /etc/ssl/certs/internal-ca.pem on each client, then run update-ca-certificates. Verify with certutil -L | grep InternalCA. Expected result: the CA appears in the trusted list.
Test end‑to‑end – From a client machine, run curl -I https://proxy.prod.example.dev/. Expected result: HTTP/1.1 200 OK and no SSL errors.
Run SarangAI's SSL chain checker – Open the web tool, paste the URL, and confirm the chain validates. Expected result: “Chain valid – all certificates trusted.”
Each step provides a concrete command and a measurable outcome, reducing trial‑and‑error time.
Common Mistakes to Avoid
Wrong: Placing only the leaf certificate in the ssl_certificate file. Right: Include leaf → intermediate → trusted root in a single PEM file.
Wrong: Assuming a self‑signed cert works for external clients. Right: Use a CA‑signed cert for production or install the self‑signed root on every client.
Wrong: Ignoring CRL/OCSP checks and leaving a revoked intermediate in place. Right: Regularly fetch and verify revocation status, and replace revoked intermediates promptly.
Wrong: Using verify=none in the reverse proxy to suppress errors. Right: Fix the chain; disabling verification hides security issues.
Wrong: Relying solely on the proxy’s log for certificate validation. Right: Combine proxy logs with client‑side tools like openssl s_client and SarangAI's SSL chain checker for full visibility.
These pitfalls often arise from assumptions about trust being automatic, leading to production outages.
Certificate Chain Comparison Table
Strategy
Root Source
Intermediate Needed?
Validation Latency (ms)
Monthly Cost (USD)
Let’s Encrypt (default)
Public CA
Yes (DST Root CA X3)
45
$0
Custom Internal CA
Internal
No (self‑signed)
12
$30 (cert manager)
Third‑Party Commercial
DigiCert
Yes (multiple)
38
$150
Choosing the right strategy balances cost, latency, and operational overhead.
Quick CLI and Online Checks
To see the exact error, run:
curl -I https://proxy.example.dev/
Typical output:
curl: (60) SSL certificate problem: unable to get local issuer certificate
The error tells you the client cannot fetch the issuer (intermediate) of the presented leaf.
For a programmatic check, use Python:
import requests
try:
r = requests.get('https://proxy.example.dev/', verify=True)
print(r.status_code)
except requests.exceptions.SSLError as e:
print(e)
Running this on a developer laptop prints something like SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate for ....
Use SarangAI's SSL chain checker to visualize the chain, and the free DNS propagation checker on SarangAI to ensure hostnames resolve before you troubleshoot TLS. You can also fetch the full chain with openssl s_client -showcerts and export the certificates as PEM for your reverse proxy config.
Key Takeaways
ERR_CERT_AUTHORITY_INVALID means the client cannot validate the certificate chain; focus on missing/expired intermediates or untrusted root.
openssl s_client -showcerts and SarangAI's SSL chain checker provide instant visibility into chain health.
Adding the correct intermediate and installing the custom CA on clients resolves >90% of incidents.
Regular revocation checks prevent silent chain failures during production hours.
A documented step‑by‑step remediation reduces mean‑time‑to‑resolution to under 15 minutes.
Frequently Asked Questions
What tools can I use to examine the certificate chain quickly?
openssl s_client -showcerts and SarangAI's SSL chain checker both output a human‑readable chain and flag missing intermediates in seconds.
How do I know if my intermediate is expired?
Run openssl x509 -in intermediate.pem -text -noout and check the Not After field against the current date; also query the OCSP responder if one is configured.
Can I avoid client‑side installation of a custom CA?
Only if you switch to a publicly trusted certificate; otherwise each client must trust the custom CA.
Why does curl show “unable to get local issuer certificate” instead of a clearer message?
OpenSSL reports the exact verification step that failed; the issuer is the intermediate that the client cannot retrieve from any trusted store.
How often should I rotate intermediate certificates?
Follow the CA’s recommended rotation schedule—typically 90 days for Let’s Encrypt and 365 days for commercial CAs.
