Reading a certificate: what this check covers
An SSL checker opens a TLS connection to a domain on port 443 and reads the certificate the server presents, reporting who it was issued to, who issued it, when it expires and how many days remain.
Expired certificates are one of the few website failures with a hard, visible consequence: browsers replace the page with a full-screen interstitial that most visitors will not click through. They are also entirely preventable, because the expiry date is public and readable at any time.
This page explains precisely which checks this tool performs, which ones it deliberately does not, and how to interpret each field — including the case where the certificate looks valid here but browsers still refuse the site.
Exactly what this check does
A short, honest spec is more useful than a badge. Here is the connection this tool makes and the fields it reads.
- Connection
- A TLS handshake to port 443 on the hostname you enter, with SNI set so multi-tenant hosts return the right certificate. The check times out after 8 seconds.
- Issued to
- The certificate’s subject Common Name. On modern certificates this is one of possibly many hostnames the certificate covers.
- Issued by
- The issuing certificate authority’s organisation name — Let’s Encrypt, DigiCert, Google Trust Services and so on.
- Validity window
- The notBefore and notAfter dates, plus days remaining calculated against the current date.
- Valid flag
- This flag means the current date falls inside the validity window. It is a date check — not a verdict on trust.
- Input tolerance
- Paste a full URL if you like; the protocol and trailing slash are stripped before connecting.
What this tool does not verify
Direct answer: a green result here means the certificate is currently within its dates. Four other things can still make a browser reject the site, and they are worth knowing by name.
Chain of trust
The connection is made without enforcing trust-chain validation, so the certificate is read even when it is self-signed or the intermediate certificate is missing. Missing intermediates are the single most common cause of "works in my browser, fails on Android or in curl" — desktop browsers often cache intermediates that other clients do not have.
Hostname coverage
A certificate is valid for the names in its Subject Alternative Name list. This tool reports the Common Name only, so a certificate issued for www.example.com while you are testing example.com can look fine here and still fail in a browser.
Revocation
A certificate can be revoked long before it expires. Revocation status is published via OCSP and CRLs and is not checked here.
Protocol and cipher configuration
A current certificate served over TLS 1.0 with weak ciphers will still show as valid. Configuration grading needs a dedicated TLS scanner.
Mixed content
A perfect certificate does not stop a browser removing the padlock because one image or script is still loaded over http://. Check the page source after a migration.
Three results and what to do about them
Example 1: Healthy, on automated renewal
Valid: yes
Days left: 67
Issued by: Let’s Encrypt
Valid until: in ~2 monthsNone. Re-check monthly.Let’s Encrypt issues 90-day certificates and renewal normally happens at day 60. Seeing a number above 60 means renewal has not run yet — which is expected, not a problem.
Example 2: Renewal has quietly stopped
Valid: yes
Days left: 9
Issued by: Let’s EncryptInvestigate today.A 90-day certificate with 9 days left means automated renewal has failed roughly three times already. The usual causes are a blocked /.well-known/acme-challenge path, a DNS change that broke validation, or a stopped renewal timer.
Example 3: Valid dates, but the browser still complains
Valid: yes
Issued to: www.example.com
You tested: example.comFix hostname coverage or redirect.Either reissue the certificate covering both names, or redirect the uncovered hostname to the covered one — the .htaccess redirect generator produces the canonical www rule for Apache.
Certificate checklist for a launch or migration
- Check both the apex domain and the www hostname — they are separate names and can behave differently.
- Confirm the DNS records point at the new server before expecting a new certificate to issue; validation fails otherwise. Verify with the DNS checker.
- Set a calendar reminder at 30 days remaining, even with automation, so a silent renewal failure surfaces with time to spare.
- Force HTTPS at the server rather than in application code so redirects happen before any page renders.
- After going live, re-run this check plus a page load test to catch mixed content and slow TLS handshakes.
- Keep a note of the issuing CA and the renewal method — the person debugging this at 2am may not be you.
How this page is maintained
The port, SNI behaviour, 8-second timeout and the exact fields returned were read from this tool’s server code. The limitations section lists what the check deliberately does not do, so a passing result is not mistaken for a full TLS audit.
Written and reviewed by the ToolsRacks editorial team. Last reviewed: .