Stackvora.tech

Diagnose 'NET::ERR_CERT_AUTHORITY_INVALID' Properly

The NET::ERR_CERT_AUTHORITY_INVALID error, often encountered in Chrome-based browsers (Firefox displays SEC_ERROR_UNKNOWN_ISSUER ), indicates that the…

The NET::ERR_CERT_AUTHORITY_INVALID error, often encountered in Chrome-based browsers (Firefox displays SEC_ERROR_UNKNOWN_ISSUER), indicates that the browser cannot establish a trusted path from the server's presented SSL/TLS certificate back to a recognized Root Certificate Authority (CA). This isn't just a minor nuisance; it's a critical security warning, signifying a failure in the browser's ability to verify the authenticity of the website. Properly diagnosing this error requires a systematic approach to identify whether the issue lies with the server's certificate configuration, client trust stores, network interception, or a combination thereof.

Understanding the certificate chain and trust anchors is fundamental. Every SSL/TLS certificate, except for self-signed roots, is issued by another certificate. This forms a chain: Server Certificate -> Intermediate CA Certificate(s) -> Root CA Certificate. Browsers ship with a pre-installed list of trusted Root CAs. If any link in this chain is broken, untrusted, or missing, the browser will refuse to trust the server's identity.

Initial Browser-Based Inspection

The first step in diagnosing NET::ERR_CERT_AUTHORITY_INVALID should always be a direct examination of the certificate presented by the server using the browser's built-in tools. This provides immediate clues about the certificate's origin and validity.

  1. Click the Padlock Icon (or "Not Secure"): In Chrome, click the padlock (or broken padlock/red triangle) icon to the left of the URL in the address bar.
  2. Select "Certificate is invalid" or "Certificate": This will open the certificate viewer.
  3. Review the "Details" Tab:
    • Issuer: Who issued the certificate? Is it a public CA like Let's Encrypt, DigiCert, or an internal CA?
    • Subject: Does the "Common Name" (CN) or "Subject Alternative Names" (SANs) match the domain you are trying to access? Mismatches cause NET::ERR_CERT_COMMON_NAME_INVALID, but can also contribute to authority issues if the wrong cert is served.
    • Validity Period: Check "Valid From" and "Valid To" dates. Is the certificate expired or not yet valid? (Expired certs typically yield NET::ERR_CERT_DATE_INVALID, but trust issues can compound).
    • Certificate Path (or Certification Path): This is crucial. It shows the entire chain.
      • Look for any certificates in the chain marked with a red cross or exclamation mark. This indicates an untrusted or invalid certificate in the path.
      • Ensure all intermediate certificates are present and correctly chained up to a trusted root. Often, servers omit sending intermediate certificates, leading to this error.

Example Certificate Path Issues

  • Missing Intermediate CA: The path shows only "Server Cert -> (Untrusted) Root Cert". The browser doesn't have the intermediate CA cert to bridge the trust gap.
  • Self-Signed Certificate: The path shows only "Server Cert (also Root Cert)". The issuer and subject are the same, and it's not signed by a recognized CA.
  • Untrusted Enterprise CA: The path shows "Server Cert -> Enterprise Intermediate CA -> Enterprise Root CA", but your browser doesn't trust the "Enterprise Root CA".

Network and Server-Side Verification with CLI Tools

Browser-based checks are useful but limited. Command-line tools offer deeper insights, especially for validating the full certificate chain and understanding server-side configuration.

Using openssl s_client

This is the definitive tool for inspecting an SSL/TLS connection from a client's perspective. It shows the exact certificate chain the server sends.


openssl s_client -connect www.example.com:443 -showcerts -verify 5 -servername www.example.com
  • -connect www.example.com:443: Specifies the host and port.
  • -showcerts: Displays all certificates in the chain sent by the server. Crucial for identifying missing intermediates.
  • -verify 5: Attempts to verify the certificate chain up to a depth of 5 and shows the verification status.
  • -servername www.example.com: Essential for Server Name Indication (SNI), ensuring the correct certificate is presented by servers hosting multiple domains.

Interpreting the output:

  • Look for -----BEGIN CERTIFICATE----- blocks. There should be at least two: the server's leaf certificate and at least one intermediate CA certificate. If only one appears, the intermediate is likely missing.
  • Examine the depth and verify return code lines. A successful verification will show verify return code: 0 (ok). Any other code indicates an issue. For instance, verify return code: 21 (unable to verify the first certificate) often points to a missing intermediate.
  • You can copy and paste each certificate block into a temporary file (e.g., cert.pem) and inspect it individually: openssl x509 -in cert.pem -text -noout.

Using curl for Basic Check

While not as detailed as openssl s_client for certificate chain issues, curl can quickly verify if a connection is possible and can be instructed to ignore certificate errors to proceed with data retrieval, useful for troubleshooting network paths.


curl -v https://www.example.com/

Look for lines like * SSL certificate problem: unable to get local issuer certificate or * SSL certificate problem: self signed certificate in the verbose output.

Common Causes and Resolutions

1. Missing Intermediate Certificate(s) on Server

This is a very frequent cause, especially with manually configured web servers (Apache, Nginx). The server must send the entire chain, from the leaf certificate up to (but not including) the trusted root.

  • Diagnosis: openssl s_client -showcerts will only display the leaf certificate, or the chain will break before reaching a recognized root.
  • Resolution:
    • Apache: Ensure your SSLCertificateChainFile (older versions) or SSLCertificateFile (modern versions, concatenated with intermediates) points to a file containing both your server certificate AND all intermediate certificates in the correct order (server cert first, then intermediates, root excluded). For Apache 2.4.8+, SSLCertificateFile should contain both the leaf and intermediates.
    • Nginx: The ssl_certificate directive should point to a file containing your server certificate followed by all intermediate certificates. 
      
# Nginx example
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate /etc/nginx/ssl/www.example.com_bundle.crt; # Contains leaf + intermediates
    ssl_certificate_key /etc/nginx/ssl/www.example.com.key;
    # ... other ssl directives ...
}
    • IIS: Usually handled by importing the full chain, but sometimes manual intervention is needed in the certificate snap-in to ensure intermediates are properly installed in the "Intermediate Certification Authorities" store.

2. Self-Signed Certificates

Often used in internal development, test, or small-scale internal environments where obtaining a public CA certificate is impractical or unnecessary.

  • Diagnosis: Browser certificate viewer shows "Issuer" and "Subject" as identical, and the certificate path only contains one entry. openssl s_client will show verify return code: 18 (self signed certificate).
  • Resolution:
    • For individual users: Manually import the self-signed certificate into the browser's or OS's trusted root store. This is not recommended for public-facing sites.
    • For internal corporate networks (managed devices): Deploy the self-signed certificate (or the root CA that signed it) to all managed machines' trusted root certificate stores via Group Policy (Windows AD), MDM (Mobile Device Management), or configuration management tools (e.g., Puppet, Ansible). This makes browsers and applications on those devices trust the certificate automatically.

3. Untrusted Enterprise/Internal CA

Similar to self-signed, but involves a properly structured internal PKI. Browsers on unmanaged devices won't trust your internal root CA.

  • Diagnosis: Certificate path shows your internal CA chain, but the root CA is marked untrusted.
  • Resolution: Same as self-signed for managed devices – deploy the internal root CA certificate to client machines' trusted root stores. For external users, this setup is inappropriate; a publicly trusted CA must be used.

4. HTTPS Interception (Proxies, Firewalls, Antivirus)

Many corporate networks, security appliances (e.g., Zscaler, Palo Alto Networks, Fortinet), or even local antivirus software perform "SSL inspection" or "HTTPS interception." They act as a Man-in-the-Middle (MitM), decrypting traffic, inspecting it, and then re-encrypting it with their own dynamically generated certificates.

  • Diagnosis:
    • The certificate issuer shown in the browser is the proxy/firewall appliance's CA (e.g., "FortiGate," "Zscaler Root CA," "ESET SSL Filter").
    • This issue usually affects all HTTPS sites, not just one.
  • Resolution:
    • For corporate environments: The enterprise's Root CA certificate (used by the inspection device) must be deployed to all managed client machines' trusted root stores. This is standard practice in secure corporate networks.
    • For personal machines/unmanaged devices: If you encounter this on a personal device, it might indicate network-level interception you're unaware of. If it's your own antivirus doing it, check its settings for "HTTPS scanning" or "SSL inspection" and consider disabling it if it causes too many issues (with security implications). If on a public Wi-Fi, exercise extreme caution.

Troubleshooting and Common Pitfalls

  • Incorrect Certificate Order: When concatenating certificates (e.g., for Nginx or Apache ssl_certificate), ensure the server's leaf certificate is first, followed by intermediate(s) in order towards the root. Reversing this order will cause trust issues.
  • Expired or Revoked Intermediates: Even if your leaf certificate is valid, an expired or revoked intermediate in the chain will break trust. Always check the validity of all certificates in the chain.
  • Browser Cache/OS Cache: Sometimes clearing browser cache or even rebooting can resolve transient issues, though rarely for fundamental certificate authority problems.
  • Time Skew: Client system clock being significantly out of sync with NTP can cause certificates to appear invalid, even if they are not. Ensure client time is accurate.
  • DNS Issues: While not a direct cause of NET::ERR_CERT_AUTHORITY_INVALID, if DNS is resolving to the wrong server, you might be getting a certificate for an entirely different domain, leading to trust issues. Verify DNS resolution (nslookup, dig).
  • Cloudflare / CDN Specifics: If using a CDN like Cloudflare, ensure your origin server is configured to serve a valid, non-expired certificate that Cloudflare can validate. For full end-to-end encryption, the origin certificate must also be trusted by Cloudflare or you must use Cloudflare's Origin CA certificates.

Back to the knowledge base · Ask the AI assistant