SSL Labs test and certificate expiry

A ssl labs certificate expiry review pairs Qualys letter grades with the leaf notAfter date—grades judge cipher posture, while expiry is a separate clock you must read on every scan.

Security auditors paste SSL Labs links into compliance packets, yet renewal engineers still get paged when notAfter slips past midnight UTC. The scan is famous for rating TLS configuration, but teams often conflate an “A” with “safe until next quarter.” Expiry and grading answer different questions, and both belong in your checklist before you sign off on production HTTPS.

The usual mistake is running SSL Labs once after a hardening sprint, then never correlating the reported certificate validity window with what cron-based renewals actually deploy. Another is assuming the cached report on ssllabs.com reflects this second’s listener after an emergency cert swap.

This guide walks through what SSL Labs shows about certificates, how to capture expiry from the report, when to re-scan, and how to double-check the same hostname with a live TLS probe so inventory and dashboards agree with strangers on the internet.

What to check

SSL Labs evaluates trust path, protocol support, cipher suites, and known misconfigurations. Certificate expiry appears in the certificate details section as validity dates for the leaf and sometimes noted weaknesses (for example, short key sizes). It does not continuously monitor your site; cached results can lag behind a renewal you completed ten minutes ago.

Separate three layers when you read a report: registration (who owns the domain at the registrar), trust (issuer, chain completeness, revocation posture), and TLS lifetime (notBefore / notAfter on the certificate the server presents on port 443). SSL Labs is strongest on trust and configuration signals; for operational expiry alerts you still need live checks or automation.

Also note hostname coverage: the scan follows the name you submit. A grade on www.example.com does not prove api.example.com or legacy aliases share the same notAfter. Wildcard certificates may satisfy many hosts in SAN, but only names listed on the cert or covered by the wildcard pattern are in scope.

If you are incident-driven, compare the serial number and notAfter in SSL Labs against openssl from the command line on the same hostname. Mismatches mean you are looking at cache, a different anycast node, or a CDN edge that rotated before the origin did.

Grade caps and warnings (weak DH params, ROBOT, TLS 1.0 enabled) belong in hardening backlogs. They rarely block handshakes today the way an expired leaf does tonight. Still export them: auditors ask for letter grades even when operations only care about days-to-expiry.

Multi-name estates should maintain a spreadsheet column for last SSL Labs scan, last live notAfter probe, and next ACME or OV renewal. When two columns diverge by more than a few hours after deploy, stop trusting the older column until a human reconciles listener reloads.

Front-end and back-end certificates on the same brand may differ. Marketing might earn an A+ on the CDN while webhooks hit an aging origin cert. SSL Labs on the public marketing hostname does not close that gap—probe each integration URL your partners document.

Step-by-step

Submit the public hostname from a browser URL bar—never an internal-only DNS name SSL Labs cannot resolve.

1. Open the Qualys SSL Labs server test and enter https://HOSTNAME/ (replace HOSTNAME with your site).
2. Wait for the full report (not the handshakes-only summary if you need certificate tables).
3. Open Certificate #1 (server certificate) and record Valid until (UTC).
4. Scroll to Chain issues and note any extra download links or missing intermediates.
5. Record the overall grade, then schedule a live confirmation (below) before closing a renewal ticket.

Capture a live handshake in parallel so you are not relying on a stale cached scan alone.

echo | openssl s_client -connect HOSTNAME:443 -servername HOSTNAME 2>/dev/null \
  | openssl x509 -noout -dates -serial -subject -issuer

On Windows, the same OpenSSL invocation works in PowerShell when OpenSSL is installed; otherwise use curl.exe:

curl.exe -vI --connect-timeout 15 "https://HOSTNAME/" 2>&1 | Select-String -Pattern "expire|SSL certificate|subject:|issuer:"

Re-run SSL Labs after you change ciphers, disable old TLS versions, or renew the certificate, because configuration changes can shift the grade independently of notAfter.

For a deeper comparison between scanner cache and real-time TLS, see SSL Labs vs live endpoint certificate check.

During pre-production hardening, capture two SSL Labs URLs: one before disabling legacy TLS, one after renewal lands. Executives often confuse the reports; date-stamp filenames so nobody cites the wrong quarter.

If your organization blocks outbound access to third-party scanners, run equivalent live checks from a bastion and attach openssl transcripts to the internal wiki. Request an exception for quarterly SSL Labs exports when customers contractually require Qualys references.

How to read the output

In the certificate panel, Valid from and Valid until map directly to X.509 notBefore and notAfter. Treat Valid until as an inclusive deadline in the certificate’s timezone encoding; automation should alert several weeks earlier, not on the last day.

The Grade (A+, A, B, and so on) aggregates protocol support, forward secrecy, and similar rules. A site can hold an A while sitting seven days from expiry—clients will still fail when notAfter passes, regardless of grade. Conversely, a renewal fixes expiry but might drop a grade if you re-enable legacy TLS to appease an old client.

Chain # entries list intermediates. If SSL Labs flags Chain incomplete, browsers might still work on some platforms while others fail trust; that is unrelated to expiry but often shows up in the same audit. Read Additional Certificates count: more certs in the handshake usually means a fuller chain, which helps trust but does not extend lifetime.

When HSTS or OCSP stapling sections mention misconfiguration, fix those on their own merit; they do not substitute for tracking notAfter. Document the hostname, grade snapshot, and certificate end date in your ticket so the next engineer does not re-open a closed renewal based on an old PDF export.

Simulation and Forward Secrecy sections describe cipher negotiation, not calendar risk. A site with perfect forward secrecy still falls over when the leaf ages out.

Rating Trust issues (for example, incomplete chain) can appear alongside valid future dates. Fix chain presentation before renewal week anyway—some Android builds fail early when intermediates are wrong, mimicking expiry confusion in support queues.

Pay attention to Alternative names in the certificate table. SSL Labs lists SAN entries so you can confirm marketing subdomains share the scanned hostname’s lifetime. If a SAN you expect is missing, renewals need CSR changes, not only timer fixes.

Common mistakes

Treating an archived SSL Labs PDF as proof of current expiry is the most common error. Reports cache for days; after certbot or a load-balancer upload, only a fresh scan or live s_client counts.

Teams sometimes scan the CDN hostname while customers hit a different CNAME that terminates on an expired origin certificate. Always match the name users type, including regional or marketing subdomains listed in analytics.

Another pitfall is ignoring certificate transparency or serial changes: after renewal, SSL Labs should show a new serial and later notAfter. If dates move forward in your PEM files but not in SSL Labs, you updated the wrong listener or have not invalidated cache yet.

Do not disable TLS 1.0 solely to chase a grade during an expiry firefight unless change management allows it; fix notAfter first, then harden. Chasing grade without live monitoring leaves you surprised when ACME fails silently next month.

Compliance teams sometimes freeze production during audit week and forbid renewals that might change the SSL Labs screenshot. Plan renewals before audit freeze windows or accept temporary grade drift after mandatory ACME cycles.

Shared hosting customers paste vanity domains into SSL Labs while the provider still serves a default cert on the shared IP. The scan grades the wrong name. Always verify SNI-specific certificates with live tools before opening registrar tickets.

When to use automation

SSL Labs is an excellent quarterly posture benchmark, but it is a poor sole source for expiry monitoring. Queue external checks that read notAfter from the live handshake on each production hostname, including redirects and API subdomains. Pair TLS dates with RDAP registrar expiry so domain revalidation does not block the next issuance.

Re-scan SSL Labs after major TLS policy changes and after every incident where grade and expiry were conflated. For day-to-day operations, use scheduled live probes with thresholds at 30, 14, 7, and 1 day before notAfter. Services like ssldays run outsider checks so you notice expiry even when internal files on disk look fresh.

Combine scanner grades with test an SSL certificate online workflows in CI after deploys: one job asserts handshake dates, another optionally links to SSL Labs for human-readable audit trails.

Tag PagerDuty routes so expiry alerts never share a silence with grade regression alerts. Different teams own those workstreams; merged silences let real expiry burn while someone chases cipher polish.

Use SSL Labs Dev APIs only if your security team approves third-party polling. For most shops, wrapping Qualys in CI is slower than openssl probes triggered on every successful deploy hook.

Train support staff to request SSL Labs links and screenshots of padlock expiry from Chrome. Paired evidence shortens debates between “internet thinks we are expired” and “our dashboard says ninety days left.”

Vendor questionnaires often ask for “last penetration test and SSL grade.” Answer expiry questions with live monitoring metrics, and grade questions with dated SSL Labs permalinks so legal teams stop conflating the two columns on the same spreadsheet row.