# SSL Certificate Check

> Check when a domain's TLS certificate expires.

SSL certificate checker tells you when a domain's TLS certificate expires, who issued it, which hostnames it covers, and whether the chain is trusted, by opening a real TLS connection to the host and reading the certificate it presents.

Also: ssl checker, ssl certificate expiry, when does my ssl certificate expire, tls certificate checker, check ssl certificate online, certificate expiration checker, ssl expiry date.

## What it does

An expired certificate takes a site down completely — every client refuses the handshake, and there is no partial degradation to warn you first. The usual cause is not negligence but invisibility: nobody owns the renewal, and nothing tells you the clock is running. This reads the live certificate the way a browser or an SDK would, and reports the expiry date, the days left, and anything about the chain that would break a client before that date arrives.

## When to use it

- You need to know how long is left before a certificate expires and takes the site with it.
- A client is failing the TLS handshake and you want to see what the server is actually presenting.
- You inherited a domain and want to know who issues its certificate and when it renews.
- You want to confirm a renewal actually deployed, rather than trusting the dashboard that issued it.
- You need to check which hostnames a wildcard or multi-domain certificate really covers.

## What you give it

| Input | Meaning |
| --- | --- |
| Domain | A hostname such as api.example.com. The connection is always made over HTTPS, so any scheme or path you paste is trimmed. |

## What you get back

| Output | Meaning |
| --- | --- |
| Days until expiry | Whole days remaining, or days elapsed when the certificate has already expired. |
| Validity window | The not-before and not-after instants, in UTC, exactly as the certificate states them. |
| Issuer and subject | Which authority signed the certificate, the common name it was issued to, and every subject alternative name it covers. |
| Trust verdict | Whether the chain validated, and the specific reason when it did not — expired, self-signed, incomplete chain, or hostname mismatch. |
| Negotiated connection | The TLS version and cipher suite the handshake actually settled on. |

## How it works

- Postman opens a TLS connection to the host on port 443 and completes the handshake.
- The certificate the server presents is read from the connection, along with the negotiated protocol and cipher.
- Days remaining are computed from the certificate's not-after date against the time of the check.
- The chain is validated against a standard trust store, and any failure reason is reported verbatim.

## Key terms

- **Not-after date** — the instant a certificate stops being valid. There is no grace period — clients reject it the moment it passes.
- **Certificate chain** — the sequence from the server's certificate up through one or more intermediates to a trusted root. A server that omits an intermediate breaks clients that cannot fetch it themselves, even though the certificate itself is perfectly valid.
- **Subject alternative name** — the list of hostnames a certificate is actually valid for. The common name alone is not authoritative — modern clients only look at the SAN list.
- **Self-signed certificate** — a certificate signed by its own key rather than by a recognised authority. Useful internally, rejected by every browser and most SDKs.

## Questions

### Does it check the whole certificate chain or just the leaf?

The handshake validates the full chain against a standard trust store, so a missing intermediate or an untrusted root is reported. The details shown describe the leaf certificate the server presented.

### Why does it show a SHA-1 fingerprint rather than SHA-256?

SHA-1 is the fingerprint the underlying runtime reports for the presented certificate. It is labelled honestly rather than presented as a SHA-256 digest it is not. Use it to confirm which certificate is deployed, not as a security control.

### Can it check a certificate on a port other than 443?

No. The check connects over HTTPS on the default port. A service on another port needs a request you can configure, which is what the REST API Client is for.

### Can it check an internal or localhost host?

No. The connection is made by Postman rather than by your browser, so it can only reach hosts that are publicly resolvable.

### Will it warn me before the certificate expires?

Not on its own. This is a single check run when you ask for it. Repeated checks on a schedule with alerting are what Postman monitors are for.


## Privacy

The domain you enter is sent to Postman so the TLS connection can be made from a server rather than from your browser, which is the only way to read a certificate at all. No account is needed, and the certificate details are not stored.

## Links

- [Use the tool](https://www.postman.com/tools/ssl-certificate-check) — the interactive version of this page.
- [Postman Tools](https://www.postman.com/tools) — every free tool in this set.
- [Monitors docs](https://learning.postman.com/docs/monitoring-your-api/intro-monitors/) — Postman documentation.
