When HTTPS stops working, the certificate is often one of the first things to investigate. An SSL checker can answer a focused question quickly: what certificate does the public endpoint present, and is it currently inside its validity period? What WebLens checksWebLens resolves the supplied…

When HTTPS stops working, the certificate is often one of the first things to investigate. An SSL checker can answer a focused question quickly: what certificate does the public endpoint present, and is it currently inside its validity period?

What WebLens checks

WebLens resolves the supplied hostname to a public address, establishes a TLS connection on port 443, reads the peer certificate, and reports its common name, validity dates, issuer, and whether the current time falls inside the certificate validity window. The checker is designed around hostnames because certificates are normally issued for domain names.

How to run the check

  1. Enter the domain you want to inspect.
  2. Review SSL status, common name, issuer, start date, and expiration date.
  3. Compare the hostname you entered with the certificate identity shown by the endpoint.
  4. If the certificate is valid but the site still fails, use the Website Status Checker and HTTP Headers Checker.

Understanding the dates

A certificate has a start and end time. WebLens marks it valid when the current time falls between those values. An expired certificate can cause browsers to block or warn about the connection. A certificate that has not yet become valid can produce a similar trust failure.

Expiration is easy to detect, but it is not the only certificate problem. A certificate can be within its dates and still fail hostname or chain validation for a client.

Common name versus hostname coverage

The checker reports the certificate’s common name. Modern certificates can also use Subject Alternative Name entries to cover multiple hostnames. If a hostname mismatch is suspected, the full SAN set should be inspected with a dedicated TLS inspection tool or the server’s certificate configuration.

Why a valid certificate can still produce an HTTPS problem

A site can have a current certificate while presenting the wrong certificate for a hostname, omitting part of an expected chain, or failing TLS negotiation for a particular client. A WebLens result showing a valid certificate is useful evidence, but it does not establish that every browser and protocol combination will accept the connection.

Certificate renewals and deployment

Automated renewal can obtain a new certificate before the old one expires. The operational step that matters is deployment: the web server, reverse proxy, or CDN must actually start presenting the renewed certificate. If renewal succeeds but the public endpoint still serves the old certificate, investigate deployment and configuration.

Limits of the check

WebLens does not present a full cipher-suite report, complete certificate-chain audit, or historical certificate timeline. Multiple endpoints can also produce different certificates when a domain uses a CDN or load balancer.

Check the public endpoint now: open the WebLens SSL Checker and inspect the certificate dates and issuer for the hostname you care about.

What to investigate when the certificate looks wrong

If the common name or certificate dates are unexpected, check which public endpoint is serving the certificate. A CDN, load balancer, reverse proxy, and origin can each have separate TLS configuration. Updating the origin certificate will not fix a client-facing certificate if TLS terminates at the edge.

If the certificate is current but users still see warnings, investigate hostname coverage, the certificate chain, system clock accuracy, and whether different network paths reach different endpoints. WebLens can provide a useful external observation, but a full browser or TLS diagnostic may expose details outside this checker.

Operational certificate hygiene

Certificate problems are easiest to avoid when renewal is treated as an operational process rather than a one-time fix. Keep track of which system terminates TLS, how certificates are renewed, and how deployment is verified. After renewal, check the public hostname rather than only the certificate files on the server. The certificate users receive is the one that matters.