How to Check an SSL Certificate (Validity, Issuer, Expiry & Chain)
A practical, step-by-step guide to checking any SSL certificate: confirm validity, issuer, expiry and the trust chain, plus how to diagnose the four most common SSL errors.
How to Check an SSL Certificate in Under a Minute
If you want to know how to check an SSL certificate, the fastest path is to paste the domain into an SSL checker and read four things off the report: whether the certificate is valid right now, who issued it, when it expires, and whether the certificate chain is complete back to a trusted root. Those four data points tell you almost everything about whether browsers will trust the site and whether visitors will see a padlock instead of a scary warning page.
You do not need OpenSSL, a terminal, or admin access to do this. A browser-based tool like the free SSL Checker connects to the server, completes the TLS handshake, and lays out the validity dates, issuer, subject names, and the full chain in one screen. Below I will walk through exactly how to read each field, then go deep on the four errors that account for nearly every "your connection is not private" message you will ever hit: expired certificates, name mismatches, self-signed certificates, and incomplete chains.
What an SSL Certificate Actually Proves
An SSL/TLS certificate does two jobs. First, it encrypts traffic between the browser and the server so nobody on the network can read it. Second, and more importantly for trust, it proves the server is who it claims to be. A Certificate Authority (CA) like Let's Encrypt, DigiCert, or Google Trust Services signs the certificate, and your browser ships with a list of CAs it trusts. When you check SSL certificate details, you are really verifying that this signed chain leads back to one of those trusted roots and that none of the data has expired or been tampered with.
When any link in that logic breaks, the browser refuses to load the page and shows a full-screen warning. That is why an SSL certificate test should be part of every launch checklist, every domain migration, and every "the site looks down" investigation.
The four fields that matter most
| Field | What it tells you | Red flag |
|---|---|---|
| Validity (Not Before / Not After) | The window during which the cert is trusted | Current date is past "Not After" |
| Issuer | Which CA signed the certificate | Issuer equals the subject (self-signed) |
| Subject / SAN | Which hostnames the cert covers | Your domain is missing from the list |
| Chain | The path from your cert to a trusted root | Missing intermediate certificate |
How to Check an SSL Certificate Step by Step
Here is the workflow I use when I am asked to verify SSL on a site I have never touched before. It takes about thirty seconds with a web tool and gives you a clean pass/fail on each of the four checks above.
- Enter the full domain. Open the SSL Checker and type the hostname exactly as visitors reach it, including the subdomain (use
www.example.comif that is the canonical version). Subdomains often have different certificates than the root domain. - Confirm the certificate is valid today. Look at the "Not Before" and "Not After" dates. The current date must fall inside that window. If the expiry is within 14 days, treat it as urgent.
- Read the issuer. A real CA name (Let's Encrypt, DigiCert, Sectigo, Google Trust Services, GoDaddy) means the cert is publicly trusted. If the issuer is the same as the subject, it is self-signed and browsers will reject it.
- Match the hostname. Check the Subject Alternative Name (SAN) list. Your domain, or a wildcard that covers it like
*.example.com, must appear there. A wildcard covers one level of subdomain only, not the bare apex. - Verify the chain. The report should show your leaf certificate, one or more intermediate certificates, and a trusted root. A gap between leaf and root is the classic "works in Chrome, fails on Android" bug.
- Cross-check the response. If the cert looks fine but the site still misbehaves, pull the live server response with the Get HTTP Header tool to confirm HTTPS is redirecting correctly and HSTS is set.
Quick tip: always test the exact hostname your users type. A certificate valid forexample.comis not automatically valid forwww.example.comunless both names are listed in the SAN field.
Common SSL Certificate Errors and How to Fix Them
Most SSL failures fall into one of four buckets. Once you can recognize the symptom in an SSL checker report, the fix is usually straightforward. Here is how to diagnose each one.
1. Expired certificate
This is the most common outage by a wide margin. The certificate was valid, the "Not After" date passed, and nobody renewed it. Browsers show NET::ERR_CERT_DATE_INVALID. The fix is to renew and reinstall the certificate, then restart or reload the web server so it serves the new one. To prevent a repeat, automate renewal (Let's Encrypt certs last 90 days, so manual renewal is a trap) and set a calendar reminder 30 days out. When you run your SSL certificate test after renewing, confirm the new "Not After" date actually moved forward; a surprising number of "renewals" install the same expired file.
2. Name mismatch
The certificate is valid and trusted, but it does not cover the hostname being requested. You will see NET::ERR_CERT_COMMON_NAME_INVALID. This usually happens when a cert was issued for example.com only, but visitors arrive at www.example.com, or when a wildcard *.example.com is used for the bare apex (which it does not cover). The fix is to reissue the certificate with every required hostname in the SAN list, or to redirect traffic to the hostname that is actually covered. When you verify SSL after the fix, scan the full SAN list rather than just the primary common name.
3. Self-signed certificate
A self-signed certificate is one your own server generated and signed, with no public CA in the chain. The issuer equals the subject. These are fine for local development and internal tools, but a public browser will throw NET::ERR_CERT_AUTHORITY_INVALID because the signer is not in its trust store. The fix for any public-facing site is to replace it with a certificate from a trusted CA. Free options like Let's Encrypt make this a non-issue, so there is rarely a reason to ship a self-signed cert to real visitors.
4. Incomplete certificate chain
This is the sneakiest error because the site often loads fine in desktop Chrome (which caches intermediates) while failing on Android, iOS, and command-line tools. The server is sending the leaf certificate but not the intermediate certificate that links it to the trusted root. An SSL checker will flag the chain as broken or incomplete. The fix is to install the full chain (your CA provides a "full chain" or "bundle" file) so the server presents leaf plus all intermediates. After fixing it, re-test from a tool that does not cache intermediates so you are sure the chain resolves on a clean client.
| Error | Browser code | Root cause | Fix |
|---|---|---|---|
| Expired | ERR_CERT_DATE_INVALID | Past "Not After" date | Renew + reload server; automate renewal |
| Name mismatch | ERR_CERT_COMMON_NAME_INVALID | Hostname not in SAN | Reissue with correct SANs or redirect |
| Self-signed | ERR_CERT_AUTHORITY_INVALID | No public CA in chain | Get a trusted CA cert (e.g. Let's Encrypt) |
| Incomplete chain | Varies by client | Missing intermediate | Serve the full chain bundle |
Reading the Issuer and Trust Chain Like a Pro
The chain is where most people get lost, so it is worth slowing down. A valid HTTPS connection has three layers: the leaf (your domain's certificate), one or more intermediate certificates, and a root that lives in the browser's trust store. The server is responsible for sending the leaf and the intermediates; the browser supplies the root. If the server skips an intermediate, the browser cannot connect the dots, and the chain breaks.
When you check SSL certificate chains in a good tool, each link is displayed in order with its own validity dates and issuer. Read it bottom to top: leaf signed by intermediate, intermediate signed by root. If any intermediate is itself expired, the whole chain fails even though your leaf certificate is fine, so do not stop reading at the first valid date you see.
Why a browser padlock is not enough
Relying on the padlock you see in your own browser is a trap. Your desktop browser may have cached an intermediate from another site, hiding a chain problem that mobile users hit every time. A dedicated checker performs a fresh handshake with no cache, so it surfaces issues your own browser hides. That is the whole point of testing from outside your own machine rather than eyeballing the address bar.
SSL Checker vs SSL Labs and the Command Line
If you have searched for an SSL Labs alternative, you already know the famous Qualys tool is thorough but slow and heavy on protocol grading. For a quick "is this cert valid, who issued it, when does it expire, is the chain complete" check, a lightweight browser tool is faster and gives you the answer without a full protocol audit. The table below shows when to reach for which approach.
| Method | Best for | Trade-off |
|---|---|---|
| Browser SSL checker | Fast validity, issuer, expiry, chain check | Not a full protocol/cipher grade |
| SSL Labs | Deep protocol and cipher grading | Slow, more than most launches need |
| OpenSSL command line | Scripting and server-side debugging | Steep syntax, needs terminal access |
For day-to-day work, run the quick check with the SSL Checker first. If the cert passes but pages still feel slow, the bottleneck is usually delivery, not encryption, so test your payload size with the Check GZIP Compression tool to confirm text assets are actually being compressed over that HTTPS connection.
Performance, Migrations, and Ongoing Monitoring
Checking SSL once is not enough. Certificates expire on a schedule, domains get migrated, and CAs occasionally revoke certs. Build a habit of testing after every deploy and on a recurring cadence. During a domain migration in particular, verify the certificate on the new host before you flip DNS, so visitors never land on a name-mismatch warning.
SSL also touches your broader site-health work. Search engines treat HTTPS as a ranking signal, and a broken certificate tanks crawlability overnight. If you are auditing a domain end to end, pair your certificate check with registration and ownership data from our WHOIS lookup guide, and tie the technical wins back to demand using the workflow in our free keyword research tool guide. All of these tools live under the Website Tracking Tools hub, which is the fastest way to run a full technical sweep in one sitting.
A simple recurring checklist
- Test the canonical hostname and the
wwwvariant separately. - Confirm expiry is more than 30 days out; if not, renew now.
- Verify the issuer is a recognized public CA.
- Walk the full chain from leaf to root with no gaps.
- Re-check after every deploy, renewal, and DNS change.
Frequently Asked Questions
How do I check if a website's SSL certificate is valid?
Enter the domain into an SSL checker and confirm the current date falls between the "Not Before" and "Not After" dates, the issuer is a trusted public CA, your hostname appears in the SAN list, and the chain resolves to a trusted root. If all four pass, the certificate is valid and browsers will show the padlock.
How can I tell when an SSL certificate expires?
The expiry date is the "Not After" field in the certificate. A checker displays it directly, often with the number of days remaining. Treat anything under 30 days as a renewal task, and automate renewal for short-lived certificates like Let's Encrypt, which expire every 90 days.
What does "incomplete certificate chain" mean?
It means the server is sending your leaf certificate but not the intermediate certificate that connects it to a trusted root. Desktop browsers sometimes hide this because they cache intermediates, but mobile devices and command-line tools will fail. The fix is to install the full chain bundle on the server.
Why does my site show a name mismatch error?
The certificate is trusted but does not cover the exact hostname being requested. This usually happens when a cert covers example.com but visitors reach www.example.com, or when a wildcard is used for the bare apex domain. Reissue the certificate with every needed hostname in the SAN list, or redirect to the covered hostname.
Are self-signed certificates safe to use?
They encrypt traffic, but no public CA vouches for them, so browsers reject them with an authority-invalid warning. They are fine for local development and internal tools, but never for a public site. Use a free trusted CA like Let's Encrypt for anything visitors will reach.
Is a browser SSL checker a good SSL Labs alternative?
For a fast validity, issuer, expiry, and chain check, yes. A lightweight browser tool gives you the answer in seconds without the heavy protocol grading SSL Labs runs. If you specifically need a deep cipher and protocol audit, use SSL Labs; for everyday verification, a quick checker is faster and sufficient.
Do I need to install anything to check an SSL certificate?
No. A browser-based SSL checker runs entirely online with no signup, download, or terminal required. You paste the domain and read the report. Command-line tools like OpenSSL are only worth it when you are scripting checks or debugging directly on a server.
How often should I verify SSL on my site?
Check after every deploy, every certificate renewal, and every DNS or hosting change, plus a recurring monthly sweep. Certificates expire on a fixed schedule and migrations can silently break the chain, so periodic testing catches problems before your visitors do.