A TLS error is easier to fix when you identify which condition failed. The certificate may name the wrong host, an intermediate certificate may be missing, the client's clock may be wrong, or the server may negotiate an incompatible connection. These failures can look similar in a browser's warning page.
Start with the exact hostname and the client that reported the error. Then inspect the presented certificate, trust chain, validity times and negotiated connection. Avoid replacing a certificate merely because a dashboard shows a warning without explaining its source.
Know where the handshake originates
The TLS certificate inspector makes a connection from the site server. Its trust result reflects that Node runtime, its trust configuration and the destination reached from that server. It is not a direct measurement of the TLS connection between your browser and the target.
The service restricts outbound checks to validated public IPv4 destinations and default web ports. A target available only through IPv6, a private network or a nonstandard port may therefore fall outside its scope. An unavailable result should not be reinterpreted as proof that the target's certificate is invalid.
Record the requested hostname, connection time and perspective with the result. If the user's browser still fails while the server-side check passes, compare the two environments rather than assuming one observation invalidates the other.
Check the requested identity first
Certificate identity validation compares the intended service name with the certificate's applicable subject alternative names under the relevant rules. A certificate for example.com does not automatically cover www.example.com, and a wildcard has specific matching limits.
Server Name Indication helps a server choose the certificate for the requested hostname when several sites share an address. Connecting to an IP address without the intended server name can produce a default certificate that ordinary hostname-based clients would not receive.
Preserve the hostname throughout the test. DNS resolves it to an address, but the intended identity remains the hostname. A troubleshooting command that substitutes an IP everywhere can accidentally test IP identity instead and create a misleading mismatch.
| Failure | Evidence | Next action |
|---|---|---|
| Hostname mismatch | Requested name and subject alternative names | Deploy the correct certificate or correct the destination |
| Expired or not-yet-valid certificate | Validity interval and client time | Check renewal and clocks |
| Untrusted chain | Presented intermediates and trust error | Review chain installation and trust store |
| Handshake negotiation failure | Protocol and connection error | Compare client and server capabilities |
| Different edge results | Resolved addresses and presented certificates | Check load balancer or CDN deployment consistency |
Inspect the certificate chain
A server normally presents its leaf certificate and the intermediate certificates needed for clients to build a path to a trusted root. The client's trust store supplies trust anchors. Sending an unrelated root or omitting a required intermediate can produce inconsistent results across clients.
Some clients can obtain or cache missing intermediates, while others cannot. That can explain why a site works on one machine and fails on a clean device. Install the proper chain instead of depending on a particular client's cached state.
Private enterprise roots introduce another difference. A managed work device may trust an internal authority or an inspecting proxy that a public diagnostic server does not trust. Identify the presented issuer and the intended environment before treating the difference as an unexplained certificate defect.
Check both validity times and the relevant clock
A certificate has a not-before and not-after interval. A newly issued certificate can fail if the client clock is behind, while an expired certificate can remain visible on one forgotten edge after the main service renews successfully. Record the exact UTC times rather than only a rounded days-remaining label.
Renewal has several stages: obtaining the certificate, saving it, deploying it and reloading the service that presents it. A successful renewal job does not prove the running process picked up the new file. Compare the live certificate's serial or fingerprint with the expected deployment.
Monitor before expiry with enough time to repair DNS validation, account issues or deployment failures. The appropriate margin depends on the service's renewal process. An alert that fires only after the certificate expires cannot prevent the user-facing interruption.
Diagnose a renewal that succeeded but did not deploy
Suppose a certificate management service reports renewal complete, but visitors still see an expiry warning. Query the live endpoint using the intended hostname and SNI. Compare the presented validity interval and certificate identity with the newly issued certificate.
If the live endpoint still presents the old certificate, inspect the load balancer, reverse proxy and application reload process. The certificate may have been written to a path the running service does not use. A container may also hold an old mounted file or require a controlled restart.
Check every relevant edge or address family. An IPv4 endpoint can be updated while IPv6 remains stale, or one load-balanced node can retain the old chain. A single successful handshake proves only the endpoint reached during that test.
After deployment, repeat the check from representative clients and verify the application response. Keep the old and new certificate identifiers in the incident record. This establishes that the change reached the serving layer rather than merely the certificate storage system.
Do not confuse one negotiated connection with a full scan
The inspector reports the protocol and cipher negotiated for one handshake. That result shows what this client and server selected together. It does not enumerate every protocol version or cipher the server accepts, nor does it establish the configuration of every edge.
If you need a configuration audit, use a suitable authorised TLS assessment tool and define its scope. Keep that separate from this focused certificate diagnostic. A TLS 1.3 connection from one client does not prove the server has disabled every older protocol.
Certificate revocation is another distinct question. This tool does not perform an independent comprehensive revocation assessment. Read the result within its documented scope rather than treating a trusted chain label as evidence of every possible certificate-status check.
Keep the intended trust boundary intact
For a production client, do not solve a certificate error by disabling verification. That removes the identity check the connection relies on. Use a controlled diagnostic only to collect evidence, then fix the hostname, chain, clock or trust configuration responsible for the failure.
If an internal service uses a private authority, distribute trust through the organisation's managed process and verify the expected certificate identity. Installing an arbitrary certificate as trusted because a page suggested it would bypass the very question you need to answer.
For public support reports, include hostnames and certificate metadata relevant to the issue. Avoid attaching private keys or unrelated internal network details. A certificate's public information can be shared without exposing the secret key that controls the service's identity.
Check the clock before replacing a valid certificate
If many unrelated sites suddenly report validity errors on one device, inspect that device’s date and time before changing server certificates. Compare its clock with an appropriate trusted time source and note any managed time policy. A certificate that is valid now can appear not yet valid or expired to a badly set clock. Preserve the original error and retest after correcting the client environment.
Frequently asked questions
Does a trusted certificate mean the website is safe?
It supports an authenticated encrypted connection under the client's trust rules. It does not evaluate the site's content, business practices or application security. A malicious site can obtain a valid certificate for a domain it controls, so destination intent remains a separate consideration.
Why does the checker pass while my browser fails?
The checks can use different trust stores, network paths, address families, clocks or proxy settings. Compare the presented certificate and exact error in both environments. The server-side result does not describe every browser's connection to the same hostname.
Does a wildcard cover the bare domain?
A wildcard such as *.example.com does not by itself cover example.com and does not represent arbitrary deeper label levels. Inspect the certificate's complete name list and the applicable identity rules. Request explicit coverage for every hostname your service actually uses.
Should I include the root certificate in the server chain?
Clients generally rely on their own trusted roots, while the server supplies the leaf and necessary intermediates. Follow the server and issuer's chain-installation guidance. Sending a root does not make an untrusted root trusted and does not compensate for a missing intermediate.
Can this inspect an internal hostname?
The public network checker deliberately restricts its destinations and perspective. Use an authorised diagnostic inside the relevant private environment for internal services. A refused target here is a scope limitation, not a certificate verdict about a system the checker did not reach.
Why is the remaining lifetime rounded?
A display may show complete days for readability, but the certificate has exact validity timestamps. Use those timestamps for incident decisions near a deadline. A rounded number can hide hours that matter during a renewal or clock-related failure.
What confirms the repair?
A fresh handshake using the intended hostname should present the expected certificate and chain, pass the relevant client's checks and reach the working application. Verify representative edges and clients when the service has multiple paths. A successful certificate issuance alone is not the final deployment check.