SSL Checker
Deep TLS certificate check on any port: chain, expiry, OCSP, HSTS.
Enter a value above to run SSL Checker
e.g. example.com
Quick answer
SSL Checker performs a live TLS handshake to any host and port and reports the certificate's names, issuer, expiry, chain completeness, signature algorithm, HSTS, and OCSP stapling. Use it to catch expired certificates, missing intermediates, and name mismatches before they take a service offline.
SSL Checker connects to a hostname over TLS, on any port you choose, and reports everything about the certificate it is served: the subject and Subject Alternative Names, the issuing CA, the validity dates, the signature algorithm, the full certificate chain, HSTS status, and OCSP stapling. Instead of trusting your desktop browser, which quietly caches missing intermediates and papers over problems, this tool shows you what a fresh client actually sees during the handshake. That is the view that matters for mobile apps, API clients, and mail servers.
It is the fastest way to answer the questions that cause real outages: is the certificate expired, does it cover the name I typed, is the chain complete, and is the server still using a weak algorithm. Because you can set the port, it works for HTTPS on 443 as well as SMTP on 25 or 587, IMAP on 993, and any other TLS service.
How it works
The tool opens a TCP connection to the host and port you enter, then performs a full TLS handshake using Server Name Indication (SNI) so a server hosting many sites on one IP returns the right certificate. It parses the leaf certificate for its Common Name, SAN list, issuer, serial, notBefore and notAfter dates, and signature algorithm, then walks the intermediate certificates the server sent to reconstruct the chain up to a trusted root. It also records whether the server sent an HSTS header and whether it stapled an OCSP response during the handshake.
Checking non-443 ports and SNI
TLS is not only on port 443. Submissions on 465 (SMTPS), 587 (STARTTLS submission), 993 (IMAPS), 995 (POP3S), 636 (LDAPS) and custom application ports all present certificates you can inspect here by setting the port field. SNI matters because most hosts pack many certificates behind one IP; the tool sends the hostname you typed in the handshake so the server knows which certificate to return. If you check by IP instead of hostname, the server falls back to a default certificate that is often the wrong one.
Chain repair and AIA
The single most common real-world SSL fault is a missing intermediate certificate. Your server should send the leaf plus every intermediate up to (but not including) the root. When it sends only the leaf, desktop Chrome and Safari often still succeed because they cache intermediates or follow the Authority Information Access (AIA) URL inside the certificate to fetch the missing link. Many clients, including OpenSSL, older Android, and most non-browser libraries, do not. If this tool reports a short or broken chain, install the full CA bundle your issuer provided and reload the server.
Expiry, HSTS and weak signatures
Read notAfter first: renew with comfortable margin, ideally weeks, because a lapse takes the whole service down at once for every visitor. HTTP Strict Transport Security (HSTS) tells browsers to refuse plain HTTP for your domain, which blocks downgrade attacks; the checker shows whether the header and its max-age are present. Finally, confirm the signature algorithm is SHA-256 or stronger. Certificates signed with SHA-1 have been rejected by every major browser since 2017, and any CA still issuing them would be distrusted, so a SHA-1 leaf means a very old or self-made certificate that clients will not accept.
Why it matters
A certificate problem is a hard failure, not a warning: browsers show a full-page block and non-browser clients simply refuse to connect, so a bad certificate can take an API, a payment flow, or inbound mail offline instantly. Running this check before and after every deploy, and on a schedule for anything you cannot afford to lose, catches expiry, name mismatches, and chain breaks while they are still cheap to fix rather than after customers hit the error.
Frequently asked questions
- Why does my certificate work in Chrome but fail here or on my phone?
- Desktop browsers cache intermediate certificates from earlier browsing and can also fetch a missing one via the AIA URL, so they build a valid chain even when your server omits the intermediate. Fresh clients, mobile apps, and command-line tools usually cannot. If this tool shows a short chain, your server is only sending the leaf; add the full intermediate bundle from your CA and reload.
- Can I check TLS on a port other than 443?
- Yes. Set the port field to whatever the service uses: 465 or 587 for SMTP, 993 for IMAP, 995 for POP3, 636 for LDAPS, or any custom port. The tool performs a normal TLS handshake there and shows the certificate that endpoint presents, which is how you verify mail and directory servers, not just websites.
- What is the maximum lifetime of a public SSL certificate?
- Publicly trusted TLS certificates are currently capped at 398 days, and the industry is moving toward much shorter lifetimes. The CA/Browser Forum has adopted a phased reduction that drops the maximum to 47 days by 2029, which makes automated renewal effectively mandatory. Short-lived certificates limit the damage of a stolen key and are why tools like Certbot renew unattended.
- What does OCSP stapling in the result mean?
- OCSP stapling means the server itself fetched a fresh, signed revocation status from the CA and attached it to the TLS handshake, so the client does not have to contact the CA separately. It is faster and more private than a client-side OCSP query. If stapling is absent it is not an error, but enabling it improves handshake speed and reliability.
- The certificate covers www but I typed the bare domain, why the mismatch?
- Modern clients validate the hostname strictly against the Subject Alternative Names list, ignoring the legacy Common Name. If you serve both example.com and www.example.com, the certificate must list both names in its SAN. A certificate that only lists www.example.com will throw a name-mismatch error for the bare domain, so reissue it with every hostname you actually serve.
- Is checking a certificate here any different from opening the site in a browser?
- Yes, in an important way. A browser leans on its cache, AIA fetching, and prior visits, so it can hide a broken chain that will still fail for other clients. This tool performs a clean handshake with no cached state, so it reflects what a first-time visitor or a non-browser client sees, which is the honest measure of whether your configuration is complete.