The date that matters is on the live certificate

An SSL certificate has two dates: when it becomes valid, and when it stops. Browsers and other clients care about the end date. Checking expiry means reading that date from the certificate your public URL is serving right now — not only from a file on disk or a panel that last looked healthy.

If you wait until the browser shows a full-page warning, visitors already cannot reach the page. What happens when an SSL certificate expires covers that warning. This article is about reading the date while the site still loads.

Check in the browser

Open the HTTPS address in a normal browser window.

  • In Chrome or Edge, open the site information control next to the address, open the secure-connection details, then open the certificate. Read the validity period (often labeled as valid to, expires, or similar).
  • In Firefox, open the padlock, open the connection details, then view the certificate. Under validity, look for “Not After”.
  • In Safari, open the certificate details from the connection or padlock controls and read the expiry field.

Menu names move between browser versions. You are looking for the end of the validity period on the certificate the browser accepted for that hostname.

A browser check is enough for one URL you already have open. It does not watch the date for you, and it only shows the host you visited. example.com and www.example.com can present different certificates. A CDN edge certificate can look fine while an origin certificate is near expiry, if you only ever check the public edge.

Check with OpenSSL

From a Mac or Linux machine that has OpenSSL, ask the server for the certificate it presents for your hostname:

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

Replace example.com with the hostname visitors use. The output includes lines like notBefore=... and notAfter=.... The notAfter value is the expiry date, printed in GMT.

Pass -servername so the server picks the certificate for that name (SNI). That matters on shared hosts and when you connect by IP. Check every public hostname that people or systems actually use, not only the apex domain.

This reads what is served over the network. A renewed file on disk does not help until the web server or CDN presents the new certificate.

Common mistakes

  • Checking the site once after setup, then never again
  • Reading a certificate in a panel that is not what the public URL serves
  • Checking only the marketing site and skipping the shop, staging hostname, or campaign page
  • Treating “the lock icon is green today” as proof the certificate will still be valid next month

Let’s Encrypt and many hosts renew automatically. Automatic renewal still fails when DNS moves, a challenge record disappears, or a new panel never takes over the old renewal. The public end date is the check that visitors will face.

A schedule beats a habit

Opening the certificate details when you remember works for a site you use every day. It is a weak habit for a site you edit only sometimes, or for a list of URLs. The useful habit is a repeated check of the served expiry date, with enough lead time to renew before browsers warn.

SiteOK reads the expiry date for each HTTPS URL you add. The phone dashboard shows that date, and an SSL warning when a URL needs renewal, next to whether the page is up or down. Nothing is installed on the server. Checks run every 30 minutes. The weekly email includes SSL expiry for each URL. When a renewal is detected, SiteOK sends the new expiration date and keeps watching that certificate.

To see the date for a public URL on a schedule, start a free trial. No signup is required.