Check a website's SSL certificate
An expired SSL certificate turns a site "not secure" for every visitor — and it's usually noticed too late. Pingvera checks the certificate's expiry in one click, along with availability and domain expiry. No sign-up.
We check availability, SSL and domain expiry. Results are cached for 10 minutes.
What the check shows
The check opens a TLS connection to the site and reads the certificate: the expiry date and how many days are left, who issued it (the certificate authority — Let's Encrypt or another), and which name it was issued for — whether that matches the domain you're checking, including www and other subdomains.
How to read the result
More than a month left is fine — nothing to do. Below that the thresholds tighten: 30 days is a warning, schedule the renewal; 14 days means get it onto this week's priorities; 7 days or fewer is urgent — the site can start showing visitors a browser warning at any moment.
There's one special case worth knowing: Let's Encrypt certificates live only 90 days and are supposed to renew automatically about 30 days before expiry. If the check shows fewer than 30 days left on a Let's Encrypt certificate, auto-renewal has almost certainly already failed — that's not "it'll sort itself out soon", it's a broken process that needs a human to fix it.
Why Let's Encrypt auto-renewal breaks
Auto-renewal looks reliable right up until the day it isn't. In practice the same handful of causes show up over and over:
- the renewal timer or cron job is disabled, or it simply never ran;
- the webroot or the nginx config changed and the ACME challenge path (
/.well-known/acme-challenge/) became unreachable — often because a catch-all server block intercepts that path before certbot can serve it; - the certificate renewed on disk, but the web server was never reloaded and keeps serving the old one from memory;
- a DNS-01 challenge is used, and the DNS provider's API token expired or its permissions changed.
What to do if it's already expired
Work through it in order: renew or reissue the certificate; reload the web server — a renewal on disk isn't enough, the running process has to pick up the new file; confirm the new certificate is actually being served with echo | openssl s_client -servername DOMAIN -connect DOMAIN:443 2>/dev/null | openssl x509 -noout -dates; and separately check the certificate chain — an incomplete chain with missing intermediates often "works" in a browser (browsers can build the rest of the chain themselves) but breaks in mobile apps and server-to-server clients that can't.
Certificate is valid, but the browser still complains
If the check says the certificate is fine but visitors still see a warning, the cause is usually something else:
- mixed content — an https page loading images, scripts or fonts over plain http;
- a name mismatch — the certificate covers example.com but the site is opened at www.example.com, or the other way around;
- an incomplete certificate chain on the server;
- a wildcard certificate (*.example.com) that doesn't cover a nested third-level subdomain like sub.app.example.com.
See also
Check domain registration expiry · Check availability from multiple regions · Check a WordPress site · SSL certificate expired: how to check and never miss the date
What is a certificate chain and why does it matter?
Your certificate is signed by an intermediate certificate from the certificate authority, which is in turn signed by a root that browsers and operating systems trust. The server has to serve the intermediate certificates along with its own — otherwise some clients, especially mobile apps and server-side HTTP clients, can't build the trust chain and fail the connection, even though everything looks fine in a browser.
Does a wildcard certificate cover every subdomain?
Only one level deep: *.example.com covers shop.example.com but not sub.shop.example.com. A nested subdomain needs either its own certificate or a separate wildcard entry for that level.
Why is the certificate valid in a browser but broken in a mobile app?
Browsers can build the trust chain themselves from a cache of intermediate certificates. Mobile apps and many server-side clients can't — they need the full chain from the server. If it's incomplete, the browser shows no error while the app's connection fails.
How do I avoid missing an expiry next time?
A one-off check shows the current status but won't warn you ahead of time. Put the site under continuous monitoring in Pingvera to get an alert 30, 14 and 7 days before expiry, by email or Telegram.
Do I need to sign up?
No. A one-off check is free and requires no sign-up. Sign-up is only needed if you want continuous monitoring with an alert before your customer notices a problem.
How often can I check?
The result for each site is cached for 10 minutes so we don't add extra load to the site being checked. For continuous monitoring with checks every minute, put the site under ongoing monitoring in Pingvera.