🔒 SSL / TLS Certificate & Security Inspector
An SSL certificate checker with an honest limit: a browser can prove the handshake succeeded, not read the certificate. What that does and does not prove.
This tests one thing: whether your browser can complete an HTTPS connection to the host. It cannot read the certificate — no browser API exposes a remote peer's certificate — so issuer, expiry, chain and protocol version need a server-side checker. Links to those are below.
For the things a browser cannot see
- Qualys SSL Labs Server Test — full certificate chain, expiry, protocol and cipher support, graded.
- hstspreload.org — whether a domain is on the browser HSTS preload list.
- crt.sh — every certificate publicly issued for a domain, from Certificate Transparency logs.
What SSL / TLS Certificate & Security Inspector Does
This tool tests whether your browser can complete an HTTPS connection to a domain. If the connection succeeds, the browser validated the certificate itself — hostname, expiry date, signature and chain to a trusted root — because it refuses the connection when any of those fail.
It cannot read the certificate, and no tool running in a web page can. Browsers deliberately expose no API that hands a page the remote peer's certificate, its issuer, its expiry date or the TLS version negotiated. That information requires a server-side connection, which is why full certificate inspection is done by scanners like Qualys SSL Labs rather than by anything in your browser tab.
What this page adds instead is the part that certificate checkers tend to leave out: what a valid certificate actually proves, how long one is allowed to last under the current rules, and which of the things people check for are worth acting on.
How to Use SSL / TLS Certificate & Security Inspector
- Enter any domain name (e.g. onlinetoolhubs.com)
- Click Check SSL
- Review encryption validation, HSTS configuration, and TLS protocol support
Formula Used by SSL / TLS Certificate & Security Inspector
Maximum certificate lifetime, on the current schedule
maximum Validity Period is set by the date the certificate was issued
- Validity Period
- notBefore to notAfter, measured in days of exactly 86,400 seconds
- issue date
- Which bracket of the CA/Browser Forum schedule the certificate falls into
Worked example
A certificate issued today, 11 September 2026.
- Today falls on or after 2026-03-15 and before 2027-03-15
- That bracket caps the Validity Period at 200 days — a CA MUST NOT exceed it and SHOULD NOT exceed 199
- Issued 11 September 2026, the latest permitted expiry is 30 March 2027
Result: A certificate you are shown with a two-year expiry was either issued before March 2026 or is not a publicly trusted TLS certificate. The cap tightens again to 100 days in March 2027 and to 47 days in March 2029.
Reading an HSTS max-age value
days = max-age ÷ 86,400
- max-age
- Seconds a browser should refuse to use plain HTTP for this host
- 86,400
- Seconds in a day
Worked example
The header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
- 31,536,000 ÷ 86,400 = 365 days
- That is the minimum max-age the preload list accepts
- includeSubDomains extends the rule to every subdomain; preload requests inclusion in the list browsers ship
Result: One year, all subdomains, and a request to be hardcoded into browsers. Worth knowing before you set it: preloading applies to internal subdomains too, and removal from the list takes months.
Maximum Certificate Lifetime by Issue Date
From the CA/Browser Forum Baseline Requirements, section 6.3.2. These are hard limits on publicly trusted TLS certificates, not recommendations.
| Issued on or after | Issued before | Maximum validity |
|---|---|---|
| — | 2026-03-15 | 398 days |
| 2026-03-15 | 2027-03-15 | 200 days |
| 2027-03-15 | 2029-03-15 | 100 days |
| 2029-03-15 | — | 47 days |
What a Browser Can and Cannot Establish
The dividing line is whether the answer requires reading the certificate or only completing a connection.
| Question | Answerable here? |
|---|---|
| Does an HTTPS connection to this host succeed? | Yes — that is what this tool tests |
| Did the browser accept the certificate chain? | Yes, implicitly — it would refuse otherwise |
| Who issued the certificate? | No — needs a server-side connection |
| When does it expire? | No — the expiry date is in the certificate |
| Which TLS version and cipher were negotiated? | No — not exposed to page JavaScript |
| Are TLS 1.0 and 1.1 still enabled on the server? | No — requires deliberately negotiating down |
| Is HSTS set, and with what max-age? | No — response headers of a no-cors request are opaque |
| Is the chain missing an intermediate? | No — and your browser may cache one that other clients lack |
What Each Check Is Actually For
Certificate checkers report many fields. These are the ones that change what you should do.
| Finding | What it means in practice |
|---|---|
| Expired certificate | Visitors see a full-page interstitial. Fix immediately |
| Hostname mismatch | Same interstitial. Usually www vs bare domain |
| Missing intermediate | Works in your browser, fails for other clients — a classic "works for me" outage |
| TLS 1.0 / 1.1 enabled | No modern browser will use them; a compliance finding rather than a live risk |
| No HSTS | A first visit over plain HTTP can be intercepted. Worth setting |
| Self-signed certificate | Fine internally, an interstitial for everyone else |
How to Read Your Result
The padlock proves the connection, not the site
A domain-validated certificate — the overwhelming majority of them — is issued to whoever demonstrates control of the domain name. That demonstration is automated, free and takes seconds. It establishes that your connection is encrypted and that you are talking to the name in the address bar rather than someone in the middle, which is genuinely valuable and is the whole point. It says nothing whatsoever about whether the operator is honest, whether the business exists, or whether the site is a phishing page. A phishing site can and routinely does hold a perfectly valid certificate, because it also controls its domain. Reading the padlock as an endorsement is the single most common misunderstanding about HTTPS.
Certificates are getting much shorter, and this is the reason
Revocation has never worked reliably on the web. CRLs are large and stale, OCSP added a privacy leak and a latency cost, and browsers ended up soft-failing both — a revocation check that cannot be completed is treated as a pass, because hard-failing would take sites offline whenever a CA had an outage. If revocation cannot be relied upon, the only dependable limit on a compromised key is the certificate running out. Hence the schedule in the table: 398 days until March 2026, 200 now, 100 from 2027 and 47 from 2029. The practical consequence is that manual renewal stops being viable. Anything not on automated issuance will eventually go down at an inconvenient hour.
HSTS is what closes the gap the certificate cannot
A certificate protects a connection that is already HTTPS. It does nothing about the first request, when someone types a bare hostname and the browser tries plain HTTP before being redirected — a redirect an attacker on the same network can intercept. Strict-Transport-Security tells a browser to refuse plain HTTP for this host for max-age seconds, so the vulnerable first request happens only once. Preloading removes even that one, by shipping the rule inside the browser. It is also the setting to approach carefully: preload covers every subdomain including internal ones, and getting off the list is slow.
You can see every certificate ever issued for your domain
Since Certificate Transparency, publicly trusted certificates are logged to append-only public logs, and browsers require evidence of that logging before trusting one. The side effect is a public audit trail: anyone can search crt.sh for a domain and see every certificate issued for it, by any CA. For a domain owner that is the useful check nobody runs — not whether your certificate is valid, but whether a certificate you did not order exists. It is also worth knowing before you request an internal certificate for a hostname you would rather not publish, because the name will be in a public log permanently.
Limitations & Accuracy Notes
- This tool makes one opaque no-cors request and reports whether it resolved. It does not read the certificate, and cannot.
- A failed probe is not evidence of a certificate problem. A non-existent host, a server that blocks the request, a firewall and an actual TLS failure are indistinguishable to a browser.
- A successful probe reflects your browser's trust store on your device. A certificate your machine accepts — because of a corporate root, an antivirus TLS proxy, or a cached intermediate — may fail for other visitors.
- No issuer, expiry date, key type, signature algorithm, chain contents, TLS version, cipher suite or HSTS status. All of those need a server-side scanner.
- Tests the default HTTPS port only. Services on other ports are not reachable this way.
- Nothing is tested from another network or geography, so it will not detect a problem specific to a single region or resolver.
- The handshake time shown includes DNS resolution and TCP setup from your location, and is not a server performance measurement.
Frequently Asked Questions
What is an SSL / TLS certificate?
What is HSTS (HTTP Strict Transport Security)?
What happens if a certificate expires?
What is the difference between a domain-validated (DV) and extended-validation (EV) certificate?
Why can this not show me the certificate?
What does a successful result actually prove?
Why did a site I know works fail the check?
Does a valid certificate mean a site is safe?
Why are certificates getting so short?
How do I see every certificate issued for my domain?
References & Further Reading
- CA/Browser Forum — Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates — Section 6.3.2 is the source of the validity-period schedule above, including the 200-day cap in force from 15 March 2026 and the 100- and 47-day caps that follow
- Qualys SSL Labs — SSL Server Test — The server-side scanner that answers everything a browser cannot: full chain, expiry, protocol and cipher support, graded
- HSTS Preload List submission requirements — Source of the preload criteria quoted above — max-age of at least 31,536,000 seconds, includeSubDomains and preload
- MDN — Strict-Transport-Security — Reference for the header, its directives and their effect on browsers
- Let's Encrypt — FAQ — Confirms the 90-day default lifetime and the six-day short-lived option, with recommended renewal at 60 days and three days respectively