Troubleshoot TLS certificates from browser error to root cause

TLS errors are often presented as a single browser warning, but the message usually points to a specific boundary. An expired certificate is different from a hostname mismatch. An unknown issuer is different from a protocol version failure. A connection that works in one client and fails in another may indicate a trust-store difference, an intermediate certificate omission, or an older cipher and protocol policy. Record the exact hostname, port, client, time, and error code before changing the server. A certificate can be valid for one hostname and invalid for the alias a user actually opened.

Separate name resolution from certificate presentation. DNS can point a hostname at the wrong load balancer, and a shared endpoint can present a default certificate when the client does not send the expected Server Name Indication. Resolve the hostname from the affected network, connect to the returned address with the hostname preserved, and inspect the certificate subject alternative names. Testing an IP address directly can produce a mismatch even when the public hostname is configured correctly.

A certificate has a not-before and not-after time expressed in UTC. A client with a fast or slow clock can reject an otherwise valid certificate, especially on embedded devices and freshly provisioned servers. Compare the client time with a trusted time source and check the certificate's dates independently. Do not extend a certificate's validity by changing a machine clock in production; fix time synchronization and renew the certificate through the issuing authority.

Renewal automation can fail before the certificate expires because an HTTP challenge is routed to the wrong service, a DNS challenge record is published in the wrong zone, or an account credential is unavailable. Monitor days until expiry and renewal job outcomes, not only the final certificate. Keep an overlap window so a failed renewal is visible while the current certificate still works. Store the last successful renewal time and the next scheduled attempt in an operator-friendly dashboard.

Modern certificates use Subject Alternative Name entries to list valid DNS names. The common name is not a substitute for checking the full SAN list. Wildcards match one label, so a certificate for *.example.com does not cover example.com or a.b.example.com. Internationalized names are represented in a normalized form, and a typo in an alias can look like a CA problem when it is actually a naming problem.

SNI lets one IP address serve different certificates for different hostnames. A proxy, load balancer, or service mesh must pass the requested name to the correct backend. Use a TLS client that sets the hostname while connecting to each edge address. If one edge presents a different certificate, compare listener configuration and deployment versions. A partial rollout can make the problem appear intermittent because DNS or client connection reuse sends users to different edges.

Servers normally send the leaf certificate plus the intermediate certificates needed to build a chain to a trusted root. They should not send the private key or usually the root certificate. Some clients can fetch a missing intermediate from the network, while others fail immediately. This is why a site can work in one browser and fail in a mobile app. Inspect the chain from the actual server, not only the files on disk, and verify that each certificate is issued by the next certificate in the chain.

When replacing a certificate, check whether the hosting platform expects a full-chain bundle or separate files. Concatenating certificates in the wrong order can produce confusing errors. Verify key compatibility between the leaf certificate and the configured private key by comparing public key fingerprints. A certificate from the right CA with the wrong key is still unusable. Keep a documented mapping from hostname to certificate resource so an emergency operator does not guess which file belongs to which listener.

An unknown issuer means the client does not trust the presented chain, which may be caused by a private CA, a missing intermediate, or an outdated trust store. A protocol error means the client and server could not agree on TLS versions, cipher suites, or extensions. Test with a current client and a supported older client to find the compatibility boundary. Do not weaken the server to accommodate an obsolete client without understanding the security and product impact.

Certificate revocation checks can also affect behavior. Some clients use OCSP stapling, some query a revocation endpoint, and some operate in a soft-fail mode. A stapling misconfiguration may cause warnings even though the chain is otherwise valid. Treat revocation as a separate signal from expiry and trust. Record which client policy produced the failure because the remediation may belong in the client fleet rather than the public endpoint.

A small certificate monitor can check every public hostname for expiry, SAN coverage, issuer, chain completeness, and protocol support. Run it from more than one network when regional routing matters. Alert at multiple thresholds, such as thirty days and seven days, and alert immediately when the active certificate changes unexpectedly. Keep the monitor independent from the same deployment pipeline that renews certificates so a shared failure does not hide the problem.

During an incident, capture the certificate fingerprint, edge address, DNS answer, and client error. A DNS inspection tool helps confirm where the hostname resolves, while a TLS inspection command shows what each edge presents. Do not paste private keys or full client certificates into a ticket. Once fixed, add a regression check for the exact failure mode. TLS is infrastructure, but it deserves the same evidence-based debugging discipline as application code.

Test the certificate from the same hostname, port, proxy, and client family that production users reach. Check the served chain, negotiated protocol, SNI behavior, redirect target, and renewal date from outside the cluster. A certificate can look correct on one listener while an old load-balancer endpoint still serves an expired chain. Keep the external check in a scheduled monitor and attach the result to the certificate owner so renewal failures become an actionable alert rather than a support surprise.

Inspect the certificate from the public hostname while preserving SNI, then compare the served chain with the certificate resource configured at the edge. Test every hostname and edge address that DNS can return. Keep renewal configuration, ownership, expiry thresholds, and rollback certificate identifiers in a searchable inventory.

Separate expiry, hostname, trust-chain, protocol, and revocation failures. Capture the client clock, SAN list, issuer chain, negotiated protocol, edge address, and exact error. Test with a current browser, an older supported client, and an external network. If only one edge fails, compare listener configuration and revision rather than replacing every certificate blindly.

Alert at multiple expiry thresholds and on unexpected certificate fingerprint changes. Renew with an overlap window, validate the new chain before activation, and retain the previous certificate until the new revision is proven. If renewal fails, route traffic to the known-good edge or restore the previous certificate resource; never disable hostname verification or upload a private key to a ticket.

Use the relevant CA Baseline Requirements, RFC 5280 for certificate and CRL profiles, and the hosting platform's certificate-renewal documentation. Keep the public hostname-to-certificate mapping under operational ownership.