NetEngToolkit

How to Troubleshoot TLS Certificate Errors

DNS and web · Last updated 12 October 2026 · 5 min read

Identify why a browser or client rejects a certificate (expired, wrong name, incomplete chain, untrusted issuer, protocol mismatch) and fix it, using openssl, curl, and certificate checks.

The problem

A browser shows a full-page security warning, or an application fails with a message such as "unable to get local issuer certificate". TLS authenticates the server by checking its certificate in three ways: the certificate must be valid in time, it must cover the name the client asked for, and it must chain to a certificate authority the client trusts. Almost every certificate error is a failure of exactly one of these checks, so the work is to find which one.

Step 1: Read the exact error

Error wording points straight at the cause. Browsers use different names for the same problem:

Meaning              Chrome-family                  Firefox-family
Expired / not yet    NET::ERR_CERT_DATE_INVALID     SEC_ERROR_EXPIRED_CERTIFICATE
Name not covered     NET::ERR_CERT_COMMON_NAME_INVALID  SSL_ERROR_BAD_CERT_DOMAIN
Untrusted issuer     NET::ERR_CERT_AUTHORITY_INVALID    SEC_ERROR_UNKNOWN_ISSUER
Protocol/cipher      ERR_SSL_VERSION_OR_CIPHER_MISMATCH SSL_ERROR_NO_CYPHER_OVERLAP

Command-line clients are just as specific. Common curl messages:

curl: (60) SSL certificate problem: certificate has expired
curl: (60) SSL certificate problem: unable to get local issuer certificate
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'
(illustrative)

"Unable to get local issuer certificate" means the client could not build a path to a trusted authority, which is either an incomplete chain sent by the server or a private CA the client does not trust (see steps 4 and 5).

Step 2: Check the certificate from the outside

Run the SSL/TLS Checker for the hostname. It reports whether a trusted HTTPS connection can be made right now, the validity dates and days remaining, the subject and issuer, and the list of names (Subject Alternative Names) the newest matching certificate covers. A status of Expired, Expiring Soon, or a hostname missing from the SAN list usually identifies the problem in seconds. Note its limits: it cannot show the negotiated TLS version or cipher, so use openssl for those.

Step 3: Inspect what the server actually presents

With OpenSSL you can see the certificates a server sends, exactly as a client receives them. Always pass -servername so the correct certificate is selected on servers that host many names:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

# Just the key facts about the leaf certificate:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

In the output, look at three things. The chain list (0 s:, 1 s: ...) should show the server certificate followed by one or more intermediates. The dates (notBefore, notAfter) must include today. The SAN list must contain the exact hostname. At the end, Verify return code gives the verdict:

Verify return code: 0 (ok)
Verify return code: 10 (certificate has expired)
Verify return code: 18 (self signed certificate)
Verify return code: 20 (unable to get local issuer certificate)
Verify return code: 21 (unable to verify the first certificate)
(illustrative)

Step 4: Match the symptom to the cause and the fix

The certificate has expired
Renew it. If you use automated issuance (ACME), find out why renewal failed: a changed DNS record or firewall rule blocking the validation challenge, an expired account credential, or a renewal job that stopped running. After renewing, reload the web server or load balancer; many servers keep the old certificate in memory until reloaded. In a cluster, check every node.
The name is not covered (hostname mismatch)
Compare the requested name with the SAN list. Remember that a wildcard *.example.com covers exactly one label: it matches www.example.com but not example.com and not a.b.example.com. Other causes: browsing to an IP address instead of a name, a typo, or a server that returns its default certificate because the virtual host for the name is not configured.
The chain is incomplete
The server must send its certificate and the intermediate certificates (not the root). Use the full-chain file from your certificate authority, not just the leaf certificate. A tell-tale sign: it works in some desktop browsers, which can fetch a missing intermediate themselves, but fails in curl, Java applications, mobile apps, or on other devices.
Untrusted issuer, self-signed, or private CA
The client does not have the issuing authority in its trust store. For an internal CA, install the CA certificate on the clients (or supply it explicitly, for example curl --cacert ca.pem). For a public site, replace a self-signed certificate with one from a public CA.
The client's clock is wrong
A device with the wrong date sees valid certificates as expired or not yet valid. Check the date and time before anything else when only one machine is affected.
Protocol or cipher mismatch
The server and client share no acceptable TLS version or cipher. TLS 1.0 and 1.1 are deprecated (RFC 8996), so very old clients cannot connect to correctly configured servers. Test versions with openssl s_client -tls1_2 and -tls1_3.
Different certificates on different servers
If the result changes between attempts, a load balancer is sending requests to nodes with different certificates; fix the node that is out of date.
Issuance is blocked
A CAA record can forbid your certificate authority from issuing for the domain. Review it with the DNS Security Checker.

Step 5: Rule out interception and local factors

Inside some organizations, a security proxy re-signs HTTPS traffic with the company's own certificate authority. On those networks a public site may show an issuer name belonging to your employer, which is expected where the company CA is installed on the device and a genuine problem where it is not. Antivirus products and some enterprise software behave the same way. If a site works on a home connection and fails at the office (or the reverse), compare the issuer shown in each place.

Preventing the next outage

  • Automate renewal, and monitor expiry independently of the automation, so that a silently broken renewal job is noticed weeks before it matters. Alert at 30 and at 14 days remaining.
  • Inventory every certificate, including those on load balancers, mail servers, VPN gateways, and internal services, which are the ones that are forgotten.
  • Watch Certificate Transparency logs for your domains so that unexpected issuance is noticed; searching the domain at crt.sh is a free way to start.
  • Test changes from outside your network and with a client other than your browser.

Security considerations

  • Do not click through certificate warnings on sites you do not control, and never ask users to. A warning on a site that previously worked is exactly the symptom of an interception attempt.
  • Do not "fix" application errors by disabling verification (curl -k, verify=False, InsecureSkipVerify). It removes the protection TLS provides. If you must work around a problem temporarily in a lab, never carry the setting into production.
  • An expired certificate is an availability and trust problem; a certificate that is valid for the wrong name is more serious and should be investigated rather than only renewed.

Tools used in this guide

  • SSL/TLS Checker — Verify that a domain establishes a working HTTPS connection.
  • HTTP Headers Checker — Inspect response headers, including key security headers like HSTS and CSP.
  • DNS Security Checker — Analyze SPF, DMARC, DKIM, DNSSEC, and CAA configuration for a domain, with each finding explained.
  • HTTP Status Checker — Check the live HTTP status code, response time, and redirect chain for any URL.

References and further reading

References are primary sources (standards and official documentation). Commands and sample output are illustrative; behavior can vary by operating system and software version.

Keep reading