SSL Checker
Read The Real Certificate
A padlock in your address bar answers one question out of four, and never shows you the real certificate. This SSL checker opens a connection to your domain, reads the certificate it actually sends, and reports the dates, the names it covers, the issuer and the chain separately.
- FreePrice
- 4Checks made
- NonePages downloaded
- NoneSign-up
SSL Certificate Checker
Expiry, name cover, issuer and trust — read from the live certificate
The domain on its own is enough. We connect on port 443, read the certificate it presents, and close the connection.
Ready. Type a domain and press the button.
Why Use A Free SSL Checker
A certificate has four separate jobs. It must be in date, cover the exact name being visited, carry a trusted signature, and arrive with its intermediates.
Any one of them can fail by itself. So a site can hold three out of four and still show every visitor a full-page warning.
An SSL checker answers all four questions on their own. Therefore you learn which part broke, rather than reading one word that says invalid.
That matters because the fixes differ completely. A renewal takes a minute, while a missing name needs the certificate reissued from scratch.
The handshake behind that padlock is public reading. RFC 8446, which defines TLS 1.3 is the current version of it.
Dates, Names And Signatures
Expiry is the famous one. Certificates last months now, not years, and an outage from a missed renewal is always avoidable.
The name catches people out more often. A certificate for example.com does not cover www.example.com, because each hostname has to be listed.
Wildcards help, though only one level deep. So *.example.com covers www.example.com, yet it misses the bare domain and anything nested further down.
The Chain Nobody Checks
Your server must send the intermediate certificates as well as its own. Most installation guides mention this once and quietly.
Leave them out and desktop browsers usually cope. Since they keep intermediates in a cache, the site looks perfectly fine on your laptop.
Phones do not cache them. As a result the same page fails on mobile, and the fault reads as random rather than as a missing file.
Why Trust Needs Its Own Answer
Reading a certificate and judging it are two different jobs. This tool opens one connection with verification off, purely to capture whatever your server sends, so that a broken certificate can still be read and explained. Then it opens a second, verifying connection to answer one question: does anyone trust this? That is why a report can call a certificate readable, correctly named, in date and still untrusted.
Checking a Certificate in Four Moves
Type the domain and read the verdict. Because only the certificate travels, the answer arrives in about a second.
- 1
Enter the domain
The hostname alone does the job. Check www and the bare domain separately, since they can hold different results.
- 2
Press check
Our server opens a connection on port 443, reads the certificate, then hangs up. No page content ever gets requested.
- 3
Read the one-line verdict
Valid, expiring soon, or broken. The line names the reason instead of leaving you to work it out.
- 4
Work through the findings
Problems appear at the top, followed by warnings and notes. Each one says what to change on the server.
Everything This SSL Checker Tells You
A padlock is a yes or no answer. Instead, this report separates the four things a certificate has to get right.
The days until expiry, worked out for you
The report says in sixty-eight days rather than printing a raw date. That means the figure on screen is the one to act on.
Name cover checked
We confirm the certificate lists the exact host you typed. Therefore a wildcard that misses the bare domain shows up immediately.
Trust tested separately
A second verifying connection answers the trust question on its own. As a result self-signed and untrusted get told apart.
Chain length reported
One certificate and no intermediates earns a warning. Since that fault only breaks phones, it otherwise stays hidden for weeks.
Protocol and signature shown
Retired TLS versions and SHA-1 signatures get flagged plainly. Then you know what to switch off on the server.
Nothing kept afterwards
The domain serves one check and then goes. We store no history, and we ask for no account either.
Habits That Prevent Outages
Certificate failures are predictable, which makes them preventable. These six habits cover almost all of them.
- Automate renewal properly. Set it up once, then confirm it actually ran. A renewal script that broke silently is the usual cause of an expiry.
- Check both hostnames. Test example.com and www.example.com separately. Because they can carry different certificates, one can fail while the other passes.
- Install the full chain. Your provider supplies a bundle, not a single file. So upload the whole thing, rather than only the certificate itself.
- Test on a phone. A missing intermediate hides from desktop browsers entirely. Therefore one mobile visit catches what a laptop never will.
- Watch the thirty-day mark. Automatic renewal usually fires around then. If nothing has happened by day thirty, look into it before the deadline.
- Include each subdomain you run in the certificate. Shops, blogs and app subdomains each need cover. A wildcard reaches one level down and no further.
Certificate Faults Worth Knowing
These three cause most https outages. Each one looks like something else until somebody reads the certificate.
Trusting the padlock alone
A browser caches intermediates and hides the gap. However, a first-time visitor on mobile sees the warning you never do.
Leaving a self-signed certificate
Staging certificates follow the site to production surprisingly often. So every browser rejects it, however strong the encryption is.
Assuming renewal still works
A path change or a failed cron job stops it quietly. Rather than assume, check the days remaining once a month.
Certificate Questions Answered
Why does this tool use your server?
A browser tab cannot read another site's certificate, since nothing in the web platform exposes it. Our server opens the connection instead. We send only the domain you typed, we download no pages, and we keep nothing afterwards.
My site works, so why the warning?
Nearly every time, the intermediate certificate is absent. Your desktop browser cached it from another site and fills the gap for you. A phone has no such cache, therefore it refuses the connection outright.
How long should a certificate last?
Public certificates are capped at well under a year now, and the limit keeps dropping. Short lifetimes are a good thing, because they force the renewal to be automatic rather than remembered.
Does a wildcard cover everything?
No, only one level. A wildcard for *.example.com covers www.example.com and shop.example.com, yet it misses example.com itself and anything like a.b.example.com. List the bare domain explicitly.
Does a free Let’s Encrypt certificate protect less?
Visitors would never see a difference. The encryption is identical, and browsers treat it identically. Paid certificates add warranties and support, rather than stronger protection. So pick whichever one your host renews automatically.
Can I check an internal server?
No. Private networks and internal names get refused before any connection opens, because this runs on our server rather than in your tab. Public domains only.
Denwix Tools for the Rest of Your Setup
A certificate is one part of a working https site. So these three cover the others.
HTTP Status Code Checker
Read the reply headers, including HSTS, for any address.
Open tool →Redirect Chain Checker
Catch a chain that drops from https back to http.
Open tool →.htaccess Redirect Generator
Write the rule that forces https site wide.
Open tool →
Check Your Certificate Now
Type a domain and read all four answers at once. This SSL checker is free, it takes a second, and it downloads no pages.