How to Check an SSL Certificate for a Website

When people say “check the SSL certificate,” they usually mean one of these:

• is the certificate valid?
• when does it expire?
• who issued it?
• does it match the hostname?
• is the site serving the right chain?

Those are all slightly different checks.

The quick way to check a website certificate

Use Domain Lookup and inspect the SSL section first.

That gives you the fast outside-in view:

• issuer
• validity
• expiry
• hostname context

It is a good first pass before you get dragged into server config details.

What a useful certificate check should answer

At minimum:

• is HTTPS working?
• which certificate is being served?
• when does it expire?
• does it look valid for this hostname?

If one of those answers looks wrong, then you know where to dig next.

Common certificate problems

1. Expired certificate

Straightforward, but still common.

The site may still “work” for some users until caches, browsers, or edge layers catch up, which makes the problem feel inconsistent.

2. Hostname mismatch

The certificate is valid, but not for the hostname you requested.

That is where SAN coverage, wildcard assumptions, and virtual-host mistakes usually enter the story.

3. Incomplete chain

The certificate itself may be fine, but the server is not presenting the chain properly for some clients.

That can show up as partial trust failures or scanner warnings that only affect some environments.

4. Old certificate still showing

This usually means the deployment path is drifting:

• the server was not reloaded
• the wrong certificate file was used
• the edge is still serving an older copy

What to check after the first certificate result

If the first pass looks wrong, these are the best follow-ups:

• Why SSL Checker Says Incomplete Certificate Chain
• Why Browser Still Shows Old Certificate After Renewal
• SAN vs Common Name
• fullchain.pem vs cert.pem

Why a certificate check can feel inconsistent

This is especially common on sites behind CDNs or reverse proxies.

You may be checking:

• the edge certificate
• the origin certificate
• one hostname in a multi-host setup
• one regional edge that is not perfectly in sync with another

That does not mean the checker is wrong. It means the delivery path has layers.

A simple SSL checking workflow

1. check the visible certificate
2. confirm issuer and expiry
3. confirm hostname coverage
4. confirm the served chain
5. if needed, inspect edge vs origin behavior

That order catches a lot without turning the problem into a week-long TLS archaeology project.

The short version

An SSL certificate check should tell you whether the site is serving a valid, current certificate that matches the hostname and presents a usable chain.

If one of those pieces fails, the next step is not “SSL is broken” in the abstract.

It is figuring out which certificate problem you actually have.