SSL Certificate Checker: Check SSL Certificate Expiry Date, Validity and Chain
Enter any domain and we open a real TLS connection to it on port 443, read the certificate the server actually presents, and report the expiry date, days remaining, issuer, covered hostnames and chain.
SSL certificate checker
LivePaste a bare domain or a full URL. We always test port 443.
| Issued to | - |
|---|---|
| Issued by | - |
| Valid from | - |
| Valid to | - |
| Signature | - |
| Covers | - |
In short
An SSL certificate checker connects to a domain on port 443, reads the certificate the server presents and reports its expiry date, issuer, subject, alternative names and chain. The three things worth checking are the days remaining before expiry, whether the certificate actually covers the hostname you typed, and whether the intermediate certificate is being served. A certificate that is valid in your browser can still fail elsewhere if the chain is incomplete, because browsers cache intermediates and other clients do not.
Every field
What an SSL certificate check tells you, field by field
Most people check a certificate to answer one question: when does it expire. That is the field that causes the outage, but it is not the only one that breaks a site, and three of the fields below fail in ways that never show up in your own browser.
| Field | What it is | Why it matters |
|---|---|---|
| Days remaining | The gap between now and the notAfter date | The single number worth alerting on. Most teams want a warning at 30 days and an escalation at 7. |
| Expiry date (notAfter) | The moment the certificate stops being accepted | Expiry is absolute and hits every visitor at once. There is no grace period and no partial failure. |
| Issued date (notBefore) | The moment it becomes valid | A freshly issued certificate installed early fails with a not-yet-valid error, which looks identical to a clock skew problem on the server. |
| Issuer | The certificate authority that signed it | Tells you where to renew, and whether the certificate came from the authority you expect rather than an interception proxy. |
| Subject and SANs | The hostnames the certificate covers | A certificate for example.com does not cover www.example.com unless www is listed. This is the most common cause of a name mismatch error. |
| Chain | The intermediate certificates the server sends | A missing intermediate is the classic works-in-Chrome-but-fails-in-curl bug. Browsers often fill the gap from cache; API clients, mobile apps and payment callbacks do not. |
| Signature algorithm | The hash and key type used to sign | SHA-1 signatures are no longer trusted. Modern certificates use SHA-256 with RSA or ECDSA. |
The 47 day roadmap
How long are SSL certificates valid for, and why that is changing
In April 2025 the CA/Browser Forum passed ballot SC-081v3, which cuts the maximum lifetime of a publicly trusted TLS certificate from 398 days to 47 days in three steps. The first step already happened: since March 15, 2026 no publicly trusted certificate can be issued for longer than 200 days. This is the single biggest change to certificate operations in a decade, and most teams have not adjusted for it yet. The full schedule, what it does to renewal workload and what to fix first are covered in certificate lifetime changes.
| Maximum lifetime | In force | Renewals per certificate per year | Renewals a year across 50 certificates | What it means in practice |
|---|---|---|---|---|
| 398 days | Until Mar 15, 2026 | 0.92 | 46 | The old normal. One renewal a year, and a calendar reminder was enough. |
| 200 days | From Mar 15, 2026 (in effect now) | 1.83 | 91 | Renewal stops lining up with an annual cycle. Two a year, on no fixed date. |
| 100 days | From Mar 15, 2027 | 3.65 | 183 | Roughly quarterly. Manual renewal becomes a standing chore for every certificate. |
| 47 days | From Mar 15, 2029 | 7.77 | 388 | Around eight a year per certificate. Automation is the only workable answer. |
The window shrinks faster than the lifetime
If you renew 30 days before expiry, a 398 day certificate gives you a 368 day quiet period. A 200 day certificate gives you 170. At 47 days you are left with a 17 day window, which is shorter than a lot of change freezes and most vacations.
Volume is the real problem
A company with 50 certificates renewed roughly 46 times a year under the old rules, about once a week. At 47 day certificates that becomes 388 renewals a year, which is more than one every single day. No calendar reminder survives that.
Automation still fails quietly
Automated renewal is the right answer, but ACME clients fail: a DNS challenge breaks, a firewall rule blocks the HTTP challenge, a cron job stops running after a server rebuild. Renewal automation and expiry monitoring are two different controls, and the second is what tells you the first stopped working.
Four methods
How to check an SSL certificate, and what each method misses
There are four ways to read a certificate and they do not return the same answer. The difference matters most for the certificate chain, because your browser can quietly repair a broken chain and then show you a green padlock for a configuration that fails for everyone else.
| Method | How | What it is good for, and what it misses |
|---|---|---|
| In the browser | Click the padlock, then the certificate details | Fastest for one site you are already looking at. Shows only what your browser sees, and your browser may be completing the chain from its own cache, which hides a missing intermediate. |
| On the command line | openssl s_client -connect example.com:443 -servername example.com | The most accurate view, and the only one that shows exactly what the server sends. Add | openssl x509 -noout -dates to print just the validity window. Scriptable, but only tells you about the moment you ran it. |
| An online checker | Enter the hostname in the tool at the top of this page | Connects from outside your network, so it sees what the public sees rather than what your laptop sees. Good for a one-off check or for confirming a fix landed. |
| Continuous monitoring | A scheduled check that alerts before expiry | The only method that catches a certificate you forgot about. Everything above requires you to remember to look, which is exactly the failure mode that takes sites down. |
| A whole-site check | DNS, connection, certificate and status code in one pass | When you are not sure whether the certificate is the problem at all. Checks the layers in the order they fail and names the one that broke, which rules the certificate in or out in a single request. |
Print just the dates on Linux or macOS
echo | openssl s_client -connect example.com:443 \ -servername example.com 2>/dev/null \ | openssl x509 -noout -dates -subject -issuer
The -servername flag sends SNI. Leave it out on a server that hosts more than one site and you will read the wrong certificate, which is a genuinely common way to spend an hour debugging the wrong thing.
Check whether it expires within 30 days
openssl x509 -in cert.pem -noout -checkend 2592000 \ && echo "OK for 30 more days" \ || echo "EXPIRES SOON"
The -checkend flag takes a number of seconds and sets the exit code, so it drops straight into a shell script. 2592000 is 30 days. This is the honest DIY version of certificate expiry alerting.
The failure
What happens when an SSL certificate expires
Certificate expiry is unusual among outages because it is completely predictable and still takes sites down constantly. It is also worse than it looks from a browser, because the browser is the only client that offers a way through.
Visitors see a full page warning
Not a small padlock change: an interstitial covering the whole page, with the continue option hidden behind an advanced link. Most people leave. If the site takes payments, the drop is immediate and total, and it happens at the exact second of expiry rather than degrading gradually.
Everything that is not a browser just fails
API clients, mobile apps, payment webhooks, cron jobs and partner integrations reject the connection with no interstitial and nobody to click through it. These often fail silently for hours because there is no human watching, which is how an expired certificate turns into missing data rather than a visible outage.
Search and reputation take the hit too
Crawlers that cannot complete a handshake cannot fetch pages. A short expiry is usually recoverable, but a certificate left expired over a long weekend can cost crawl coverage on top of the traffic, and any uptime commitment you have published is being spent the whole time.
It is the outage with the longest warning
Unlike a bad deploy or a hardware failure, expiry announces itself months ahead in a field anyone can read. Every certificate expiry outage is a monitoring failure rather than an infrastructure failure, which is the whole reason automated checks pay for themselves here.
Error to cause
Common SSL certificate errors and what each one actually means
Run the checker at the top of this page against the affected hostname and the field that is wrong is usually obvious once you know which error maps to which field.
| Error | Real cause | Fix |
|---|---|---|
| NET::ERR_CERT_DATE_INVALID | Expired, or not yet valid | Check the notBefore and notAfter dates above. If the certificate looks current, check the clock on the server or the client. |
| NET::ERR_CERT_COMMON_NAME_INVALID | The hostname is not covered | The name you requested is not in the subject or the SAN list. Adding www or a subdomain to the certificate fixes it. |
| NET::ERR_CERT_AUTHORITY_INVALID | Self-signed, or an untrusted issuer | Either a self-signed certificate is in place, or the intermediate is missing so the client cannot build a path to a trusted root. |
| unable to get local issuer certificate | Incomplete chain | The server is sending the leaf certificate without its intermediate. Install the full chain file rather than just the certificate. |
| SSL_ERROR_BAD_CERT_DOMAIN | The hostname is not covered | The Firefox wording for the same name mismatch as ERR_CERT_COMMON_NAME_INVALID. |
| Cloudflare error 526 | The origin certificate was rejected | Cloudflare completed the handshake with your origin but refused the certificate, usually because it is expired or self-signed while the SSL mode is Full (Strict). |
| Cloudflare error 525 | The handshake never completed | No valid certificate on the origin, port 443 closed, or no cipher suite in common. Different from 526, which means the handshake succeeded first. |
The two Cloudflare codes are worth separating because they are constantly confused. A 525 means the TLS handshake with your origin never completed, while a 526 means it completed and Cloudflare then rejected the certificate. Switching from Full (Strict) to Full clears a 526 and never clears a 525.
The limit of a one-off check
What a certificate checker cannot tell you
The tool at the top of this page tells you the truth about one hostname at one moment. That is genuinely useful for confirming a fix or diagnosing an error, and it is exactly the wrong shape for the problem that actually takes sites down.
Certificates almost never expire on hosts anyone is watching. They expire on the staging domain that quietly started serving production traffic, the API subdomain nobody has touched since it was set up, or the vanity domain a marketing campaign still points at. Nobody types those into a checker, because nobody remembers they exist.
The second gap is time. A certificate with 60 days left is fine today and an outage in nine weeks. A one-off check cannot tell you that, and the shrinking lifetime schedule above means the gap between two manual checks now regularly exceeds the entire life of the certificate.
What continuous checking adds
- A daily check on every hostname you own, including the ones nobody thinks about
- Alerts at 30 and 7 days before expiry, while renewal is still routine rather than an incident
- Chain and hostname validation on every run, not just the expiry date
- Confirmation that your renewal automation is still working, which is the failure nobody plans for
- The same check running alongside uptime, keyword and API checks, so one alert path covers all of it
Questions
SSL certificate checker questions, answered
How do I check an SSL certificate?
Enter the domain in the checker at the top of this page and it will connect to the host on port 443 and read the certificate directly. You can also click the padlock in your browser, or run openssl s_client -connect example.com:443 -servername example.com on the command line. The command line view is the most accurate because it shows exactly what the server sends.
How to check SSL certificate expiry?
The expiry date is the notAfter field in the certificate. The checker on this page shows it along with the number of days remaining. On the command line, openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates prints the notBefore and notAfter dates and nothing else.
How to check if an SSL certificate is valid or not?
A certificate is valid when four things are all true: the current date sits between notBefore and notAfter, the hostname is covered by the subject or a SAN entry, the chain leads to a trusted root, and it is not self-signed. Checking only the expiry date is the common mistake, because a name mismatch or a missing intermediate breaks the connection just as completely.
What happens when an SSL certificate expires?
Browsers show a full-page interstitial warning and most visitors leave immediately. It is worse outside the browser: API clients, mobile apps, payment webhooks and scheduled integrations reject the connection outright with no warning screen and no way for a user to click through. Expiry is instant and total rather than gradual.
Why do SSL certificates expire?
Expiry limits the damage from a stolen private key, since a compromised certificate stops being trusted on a known date whether or not anyone noticed the theft. It also forces domain ownership to be re-verified regularly and lets the industry retire weak algorithms on a predictable schedule. Revocation checking is unreliable in practice, so a short lifetime does the job instead.
How long are SSL certificates valid for?
The maximum is 200 days as of March 15, 2026. Under CA/Browser Forum ballot SC-081v3 that drops to 100 days on March 15, 2027 and to 47 days on March 15, 2029. The previous limit was 398 days. Certificates issued before a cutoff keep their original lifetime, so shorter maximums arrive gradually rather than all at once.
Do SSL certificates expire at midnight?
Not necessarily. A certificate expires at the exact timestamp in its notAfter field, expressed in UTC, and that time is usually the moment of issue plus the lifetime rather than a midnight boundary. Some authorities do round to 23:59:59 UTC. Check the full timestamp rather than assuming you have until the end of the day.
What does SSL certificate expired mean?
It means the current date is past the notAfter timestamp, so clients no longer accept the certificate as proof of the server identity. The encryption itself still works, but no client will trust it, which is why the connection fails rather than falling back to an unencrypted one.
How do I check an SSL certificate on a Linux server?
For a live host, run openssl s_client -connect example.com:443 -servername example.com. For a certificate file already on disk, run openssl x509 -in /path/to/cert.pem -noout -text to print everything, or add -noout -enddate to print just the expiry. The -servername flag matters on any server hosting more than one site.
Why does my certificate work in Chrome but fail in curl?
Almost always a missing intermediate certificate. Browsers cache intermediates they have seen before and can quietly fill the gap, while curl, API clients and mobile apps cannot. The server needs to send the full chain, not just the leaf certificate. The checker above reports the chain length so you can confirm the intermediate is present.
Does an SSL certificate checker tell me if my site is down?
No. A certificate check reads the certificate and tells you nothing about whether the site itself returns a working page. A host can present a perfect certificate and still serve a 500 error, and a site can be perfectly healthy at the moment you check and expire three weeks later. Those are separate checks, which is why monitoring runs both continuously.
How often should I check SSL certificates?
Daily is enough for expiry, because the useful alert thresholds are 30 days and 7 days out. Checking manually at any interval is the weak part: the certificates that take sites down are the ones nobody remembered they owned. An automated daily check across every hostname is the practical answer, and it becomes mandatory once lifetimes reach 47 days.
Keep reading
Related tools and guides
A one-off check catches today's problem, not next month's
Uptimehub checks every certificate on your domains daily and alerts you 30 and 7 days before expiry, alongside uptime and response time from six global regions. From $9 a month, priced per monitor and never per seat.