You've installed an SSL certificate, your site shows the padlock, and everything seems fine. But is it actually working the way it should? There's more to a valid SSL than just seeing "https" in the address bar.

I've seen plenty of sites where the owner thought their SSL was fine, only to discover their certificate chain was broken, or worse—their cert expired without them noticing. Let's make sure that doesn't happen to you.

What makes an SSL certificate "valid"

A valid SSL certificate isn't just about encryption. It needs to meet several criteria:

Not expired — Certificates have a validity period, typically 90 days (Let's Encrypt) to 1-2 years (commercial CAs).
Issued by a trusted Certificate Authority — Your browser has a list of CAs it trusts. Self-signed certs don't cut it for public sites.
Matches your domain — A cert for example.com won't work for shop.example.com unless it's a wildcard (*.example.com).
Complete certificate chain — Your server needs to send the full chain, not just the leaf certificate.
Not revoked — CAs can revoke certificates if they're compromised.

If any of these fail, browsers will show warnings—or block access entirely.

The quick browser check

The easiest way to check is right in your browser. Click the padlock icon in the address bar, then look for certificate details. Here's what you're looking for:

In Chrome:

Click the padlock (or "Not Secure" if something's wrong)
Click "Connection is secure"
Click "Certificate is valid"

You'll see the certificate details including issuer, validity dates, and which domain it covers.

In Firefox:

Click the padlock
Click the arrow next to "Connection secure"
Click "More information"

This shows you the certificate viewer with all the technical details.

In Safari:

Click the padlock
Click "Show Certificate"

The thing is, this only tells you what your browser sees from your current location. It doesn't catch everything—like chain issues that only affect some visitors, or certificates that are about to expire.

Using an SSL checker tool

For a more thorough check, you want an external tool that verifies your certificate from outside your network. This catches issues like:

Incomplete certificate chains
Mixed content warnings
Server configuration problems
Protocol support issues (TLS 1.2, 1.3)

Our SSL Checker tool does this in seconds. Just enter your domain and you'll see:

Certificate validity dates
Issuer information
Certificate chain status
Days until expiration
Protocol support

It's the same type of check that services like SSL Labs run, but faster and focused on the essentials.

Common SSL issues and what they mean

Here's what to look for when checking your certificate:

Certificate has expired

This is the obvious one. Your cert has passed its expiration date and browsers will block access with a scary warning. The fix is straightforward—renew the certificate. If you're using Let's Encrypt with auto-renewal (you should be), something broke in your automation.

Certificate chain is incomplete

Your SSL cert isn't standalone. It's part of a chain that goes: Your Cert → Intermediate CA → Root CA. Browsers have root CAs built in, but they need the intermediate certificates from your server.

If your chain is incomplete, some browsers will still work (they can fetch missing intermediates), but others won't. Mobile browsers are particularly picky about this.

Fix: Make sure your server sends the full chain. Most hosting providers handle this automatically, but if you're managing your own server, check your configuration.

Certificate doesn't match domain

You've got an SSL cert, but it's for the wrong domain. This happens when:

You moved domains and forgot to get a new cert
You're accessing via a subdomain that isn't covered
You installed the wrong certificate

For subdomains, you either need a wildcard certificate or a certificate with Subject Alternative Names (SANs) covering all your subdomains.

Mixed content warnings

Your SSL is fine, but your page loads some resources over HTTP instead of HTTPS. Images, scripts, stylesheets—if any are loaded over HTTP, browsers will complain.

This isn't technically an SSL certificate issue, but it will break that nice padlock. Fix by updating all your resource URLs to HTTPS, or better yet, use protocol-relative URLs (//example.com/image.jpg) or just relative paths.

Self-signed certificate

You or someone created a certificate without going through a CA. Fine for development, not for production. Get a real cert—Let's Encrypt is free.

Checking from the command line

If you're comfortable with the terminal, openssl gives you detailed info:

openssl s_client -connect yoursite.com:443 -servername yoursite.com

This shows the certificate chain and negotiated protocol. For just the certificate dates:

echo | openssl s_client -connect yoursite.com:443 -servername yoursite.com 2>/dev/null | openssl x509 -noout -dates

Output looks like:

notBefore=Dec  1 00:00:00 2024 GMT
notAfter=Feb 28 23:59:59 2025 GMT

The -servername flag is important if your server uses SNI (most do now). Without it, you might get the wrong certificate.

Setting up expiry monitoring

Checking your SSL once isn't enough. Certificates expire, and if you miss the renewal, your site goes down. Here's what I recommend:

For Let's Encrypt: Make sure certbot auto-renewal is actually working. Run certbot renew --dry-run to test it. Also set up a cron job or systemd timer to run renewal checks at least daily.

For paid certificates: Add calendar reminders 30 and 7 days before expiry. Most CAs send email reminders too, but don't rely solely on those.

For critical sites: Use an external monitoring service. Uptime Robot, StatusCake, and similar services can monitor SSL expiry and alert you before it's a problem.

What about internal certificates?

If you're running internal services, you might be using a private CA or self-signed certs. The same principles apply, but your browsers and clients need to trust your CA.

For internal tools, consider:

Installing your CA's root certificate on all client machines
Using a tool like mkcert for development
Still tracking expiry dates—internal certs expire too

Quick checklist

Before you consider your SSL verified:

Certificate shows valid dates (not expired, not "not yet valid")
Certificate matches your domain (including www vs non-www)
Full certificate chain is present
No mixed content warnings on your pages
Certificate is from a trusted CA (not self-signed for production)
TLS 1.2 or 1.3 is enabled (older protocols are deprecated)
You have a plan for renewal before expiry

Run your domain through our SSL Checker for an instant verification. It catches most issues in a single check and tells you exactly how many days you have until renewal time.

SSL might seem like a "set it and forget it" thing, but expired or misconfigured certificates are one of the most common causes of website downtime. A quick check every few months—or better yet, automated monitoring—saves headaches later.

How to Check If Your SSL Certificate Is Valid