How to Check a Website's SSL Certificate: Step-by-Step Guide

Short answer. You can check a website's SSL certificate in three ways: click the padlock icon in your browser's address bar, run an online scan with the enterno.io SSL checker, or use openssl s_client in a terminal. Focus on three things: the expiration date, whether the domain matches the SAN field, and whether the certificate chain is complete.

Why checking an SSL certificate matters

An SSL certificate proves a website's identity and enables encryption between the browser and the server. An expired or misconfigured certificate means:

• Lost visitors — a full-page "Your connection is not private" warning scares most users away
• SEO impact — Google uses HTTPS as a ranking signal
• Exposed data — passwords and form data travel in plain text
• Payment failures — PCI DSS requires modern TLS for card data
• Broken integrations — API clients and mobile apps start failing the minute a certificate expires

How to check an SSL certificate in the browser

The fastest method, and it needs no tools. The steps differ slightly between browsers.

Checking in Chrome

1. Click the padlock (in recent versions, the tune icon) to the left of the address.
2. Choose "Connection is secure" → "Certificate is valid".
3. The General tab shows the Subject (issued to), the Issuer (issued by), and the validity period.
4. On the Details tab, find the Subject Alternative Name field — it lists every domain the certificate covers.

Checking in Firefox

1. Click the padlock → "Connection secure" → "More information".
2. In the Page Info window, click "View Certificate".
3. Firefox opens an about:certificate page with one tab per link in the chain: the site certificate (leaf), the intermediate, and the root.
4. Review the validity dates, the SAN list, and the issuer of each link.

Checking in Safari

1. Click the padlock in the address bar → "Show Certificate".
2. The top of the window shows the whole trust chain as a tree, from the root CA down to the site certificate.
3. Expand the Details section for the serial number, signature algorithm, validity dates, and SAN entries.

Browsers cache intermediate certificates, so a green padlock on your machine does not prove the server sends the full chain. Re-check the site with an external tool or openssl from a clean machine — that is exactly how first-time visitors see it.

Checking an SSL certificate online

An online tool is the quickest way to see the whole picture from the outside. The enterno.io SSL checker connects to your site from the public internet — the same way a visitor's browser does — and reports:

• the expiration date and the number of days remaining;
• the full trust chain and any missing intermediates;
• the issuer (CA) and validation type;
• supported TLS protocol versions;
• an overall configuration grade, so problems are visible at a glance.

For most day-to-day checks this is enough — no terminal required.

How to check an SSL certificate with openssl

When you need details, connect to the server directly:

# Full TLS handshake and certificate details
openssl s_client -connect example.com:443 -servername example.com

The -servername flag sends SNI; without it, a server hosting several sites on one IP may return a different certificate.

Extract the validity dates:

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

# notBefore=Jun  1 00:00:00 2026 GMT
# notAfter=Aug 30 23:59:59 2026 GMT

Inspect the chain exactly as the server sends it, and check the issuer:

# Full chain as served
openssl s_client -connect example.com:443 -servername example.com -showcerts < /dev/null

# Issuer and subject only
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -subject

A quick check with curl

curl -vI https://example.com 2>&1 | grep -E "expire|issuer|subject|SSL"

curl prints the issuer, the expiry date, and the verification result (SSL certificate verify ok). An error at this stage means some of your visitors see a warning too.

What the certificate fields mean

• Subject (CN) — the name the certificate was issued for. Modern browsers ignore CN and rely on SAN only.
• Subject Alternative Name (SAN) — the actual list of domains the certificate covers. A domain missing from SAN triggers a name-mismatch error.
• Issuer — the CA that signed the certificate: Let's Encrypt, GlobalSign, Sectigo, and so on.
• Validity (notBefore / notAfter) — the validity window. After notAfter the certificate becomes invalid instantly; there is no grace period.

The trust chain: leaf → intermediate → root

A browser does not trust your certificate directly — it trusts the root CAs in its local store. Validation walks the chain: the site certificate (leaf) is signed by an intermediate, which is signed by a root. The server must send the leaf and all intermediates, but sending the root is pointless: the client only trusts the copy of the root already present in its own trust store and ignores any root the server presents. If an intermediate is missing, some clients — older Android in particular — fail with a trust error; see the breakdown in the guide to "cannot verify server certificate".

Which TLS versions are considered safe

Protocol	Status	Action
SSL 2.0 / 3.0	Vulnerable (POODLE, DROWN)	Disable
TLS 1.0 / 1.1	Deprecated, banned by PCI DSS	Disable
TLS 1.2	Secure	Support
TLS 1.3	Recommended: faster and safer	Enable

You can test versions one by one with the openssl flags -tls1_2 / -tls1_3, or run a single online SSL check that probes them all at once.

Wildcard vs SAN vs DV/OV/EV certificates

• Wildcard (*.example.com) — covers all first-level subdomains, but not the bare example.com (added as a separate SAN entry) and not second-level subdomains like a.b.example.com.
• SAN / multi-domain — one certificate for an explicit list of different domains; each must be listed.
• DV (Domain Validation) — a domain-ownership check only; issued in minutes and fine for most sites.
• OV / EV — the CA also verifies the organization (EV more strictly). Since 2019 browsers no longer highlight EV, and the validation level does not affect encryption strength.

Common SSL certificate errors

Problem	Symptom	Cause	Fix
Expired certificate	ERR_CERT_DATE_INVALID	Auto-renewal broke or never existed	Reissue (certbot renew) and set up expiry monitoring
Self-signed	ERR_CERT_AUTHORITY_INVALID	Not issued by a trusted CA	Get a certificate from a public CA (Let's Encrypt is free)
Name mismatch	ERR_CERT_COMMON_NAME_INVALID	Domain missing from SAN (often www)	Reissue with the full domain list
Incomplete chain	Errors on mobile while desktop looks fine	Server does not send the intermediate	Install fullchain, not just the leaf
Revoked certificate	ERR_CERT_REVOKED	CA revoked it (key compromise)	Reissue immediately with a new key

The two most common cases are covered in detail separately: fixing ERR_CERT_AUTHORITY_INVALID and fixing "cannot verify server certificate".

One regional special case: some Russian websites (major banks and government portals) use certificates from the Russian Trusted CA run by the Ministry of Digital Development. Its root is not included in Chrome, Firefox, or Safari trust stores, so these browsers report ERR_CERT_AUTHORITY_INVALID even though the certificate itself is valid — the Issuer field will show "Russian Trusted Sub CA".

Monitoring SSL certificate expiration

Certificates rarely expire because nobody cared — they expire because auto-renewal fails silently:

• the certbot cron job was lost during a server migration or OS upgrade;
• DNS records changed and ACME validation stopped passing;
• the disk filled up and the new certificate was never written;
• the certificate renewed, but the web server never reloaded its configuration;
• the main domain renewed while a forgotten subdomain did not.

A minimal DIY safeguard is a daily cron script (GNU date syntax):

#!/bin/sh
# /etc/cron.daily/ssl-check
DOMAIN="example.com"
EXPIRY=$(echo | openssl s_client -connect "$DOMAIN:443" -servername "$DOMAIN" 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
DAYS=$(( ($(date -d "$EXPIRY" +%s) - $(date +%s)) / 86400 ))
if [ "$DAYS" -lt 14 ]; then
  echo "SSL for $DOMAIN expires in $DAYS days" | mail -s "SSL ALERT: $DOMAIN" admin@example.com
fi

The script has blind spots: it checks only the date (not the chain or the protocols), runs on the same server as the site, and has to be duplicated per domain. For production certificates, external automated monitoring is safer: the enterno.io SSL checker watches the expiry date, the chain, and the TLS configuration, and enterno.io monitoring alerts you well in advance — see pricing. For a comparison of approaches, see the review of the best SSL monitoring services.

Set alerts on at least three thresholds — 30, 14, and 7 days before expiry. The first gives you time for a planned renewal, the second catches a forgotten task, and the third is the last call to renew the same day.

FAQ: checking a website's SSL certificate

How can I check an SSL certificate without installing anything?

Click the padlock in your browser, or run an online SSL check and enter the domain. The online check is more informative: it shows the chain, the protocols, and a grade, not just the expiry date.

Why does my browser say the certificate is valid while visitors get errors?

The classic sign of an incomplete chain: your browser fetched and cached the intermediate certificate earlier, while fresh clients cannot. Verify with openssl s_client -showcerts from another machine or with an external checker.

Can I check the SSL certificate of any website?

Yes. A certificate is public by design — the server presents it on every connection, before any data is exchanged. Every method in this guide works for any site.

How often should I check an SSL certificate?

Manually — after every change to the server, DNS, or CDN configuration. Automatically — daily: it costs nothing and closes the "renewal silently broke and customers told us first" scenario.

Are SSL and TLS the same thing?

In practice, yes. SSL is the historical name of the protocol that has evolved as TLS since 1999. "SSL certificate" is the established term, but technically it is an X.509 certificate used over TLS 1.2 or 1.3.

SSL certificate check checklist

• The certificate is not expired and has more than 14 days left
• The domain and all subdomains are present in SAN (including www)
• The chain is complete: the server sends the leaf and all intermediates
• The issuer is a trusted CA
• TLS 1.2 and 1.3 are supported; SSL 3.0 and TLS 1.0/1.1 are disabled
• curl -vI and openssl report no verification errors
• Auto-renewal is configured and dry-run tested (certbot renew --dry-run)
• External expiry monitoring is on, with 30/14/7-day alerts