Roftr Labs

Website

SSL Certificate Checker

Issuer, validity dates, hostname coverage, the chain as served, and expiry with the days counted.

10 checks a day, 5 an hour · results are kept for 24 hours, then deleted

How to use it

  1. Enter the address you want to checkType or paste it into the field marked "Address to check", including the https:// at the front. Use https:// and the exact hostname you serve on — a certificate is issued to a name, and www and the bare domain are different names.
  2. Press Check and wait a few secondsThe request runs from our server rather than from your browser, so your cache, your extensions and your login session cannot affect the answer. That is the point of it: you are seeing what an anonymous visitor sees.
  3. Check the expiry date firstDays remaining is the number that matters. An expired certificate shows every visitor a full-page browser warning, and it is the single most preventable outage there is.
  4. Confirm the name actually matchesEvery name the certificate covers is listed. A certificate for example.com that does not also cover www.example.com will fail on half your traffic, and browsers are unforgiving about it.
  5. Look at the chain, not only the certificateA missing intermediate is the classic "works in my browser, fails everywhere else" fault — some clients cache the intermediate and some do not, so it looks intermittent when it is not.
  6. Share or keep the result within 24 hoursThe result has its own link you can send to whoever needs to act on it. It is deleted 24 hours after the check ran, so save anything you need to keep — and re-run the check after a change rather than trusting an old link.

About this tool

This opens a TLS connection to a host and reports the certificate it presents: who issued it, when it expires, which hostnames it actually covers, and the chain the server sends alongside it.

The reason to check rather than trust your browser is that browsers are forgiving in ways other clients are not. Chrome caches intermediate certificates from previous sites and quietly repairs an incomplete chain, so a site can look perfect to you while failing for curl, payment gateways, mobile apps and search engine crawlers.

Understanding the result

The expiry is shown as a count of days, not just a date, because the practical question is how long you have. Renewal automation that stopped working is the single most common cause of an outage on an otherwise healthy site.

The names the certificate covers come from its Subject Alternative Names. Browsers ignore the old Common Name field entirely, so a certificate whose CN looks right but whose SAN list does not include your host will still be refused.

The chain is shown as the server actually sent it. If verification failed but the certificate looks correct, a missing intermediate is the usual explanation.

Example

Input

roftr.com

Output

Valid — expires in 70 days
Issued by Let's Encrypt · covers roftr.com, www.roftr.com
EC 256 bits · TLSv1.3 · chain trusted

Limitations

  • The certificate is checked from our server, so a host that answers differently by geography or refuses unfamiliar clients may present something else to you.
  • Revocation is not checked. A certificate revoked by its issuer still reports as valid here — revocation checking is unreliable across clients and would give a confident answer we cannot stand behind.
  • Only the certificate is assessed, not the full TLS configuration. Cipher suite ordering, session resumption and protocol downgrade behaviour need a dedicated TLS scanner.
  • The connection goes to the address the hostname resolved to at check time. A host behind round-robin DNS may have other servers with different certificates.
  • Nothing here proves who operates the server — only what they presented during the handshake.

Questions

My browser says the certificate is fine, so why does this report a problem?

Almost always a missing intermediate certificate. Browsers cache intermediates from other sites they have visited and use them to complete your chain silently; a fresh client with no cache — curl, a payment provider, a crawler — has nothing to fall back on and fails. Fix it by serving the full chain your CA provided.

My wildcard certificate covers *.example.com. Why does it not work on example.com?

A wildcard replaces exactly one label. *.example.com covers www.example.com and api.example.com, but not example.com itself and not a.b.example.com. Certificates normally list the bare domain as a second name for this reason — check the covered names shown in the result.

How long before expiry should I renew?

If renewal is automated, nothing should be needed — but check the automation actually ran when you see under three weeks left, because a silently broken cron job looks exactly like a healthy certificate until the day it does not. Manual renewals want a fortnight of headroom.

Do you check whether the certificate was revoked?

No. Revocation checking behaves inconsistently across clients — many browsers soft-fail it entirely — so a confident answer here would be misleading. Treat this as a check of what the server presents, not of what a CA has since decided about it.

Last updated 2026-08-16.

Related tools