Live Certificate Expiry

Live Certificate Expiry samples your HTTPS hosts (apex + www first, then a small set of resolved hosts) and checks how many days remain on each served certificate. The score is driven by the WORST host: a single dying cert anywhere in the sample tanks the whole 25-point check. This is the heaviest single check in the Certificate Transparency category and it overlaps with the Certificate Validity sub-weight in Web Application Security; the difference is scope and aggregation.

If you got a low score here, the fix is the same as the web sub-weight: automate renewal so no cert ever dips into the warning bands. The Certificate Validity guide covers per-platform setup; this page focuses on the worst-host aggregation and the multi-host pitfalls that make this check uniquely failure-prone.

How the check works

Per scan, RedScore samples HTTPS hosts and reads each certificate's notAfter date. Per-host scores by remaining days:

• 30+ days remaining (or unknown days): 1.0 (band: healthy).
• Up to 30 days: 0.6 (band: expiring_30d). Reason: ct_cert_expiring_30d.
• Up to 14 days: 0.2 (band: expiring_14d). Reason: ct_cert_expiring_14d.
• Expired or past notAfter: 0.0 (band: expired). Reason: ct_cert_expired.

Composite = MIN of all host scores. One expired cert anywhere in the sample drops the whole check to 0; one cert expiring within 14 days drops the whole check to 0.2 (warn). Verdict via the standard CT composite mapping (pass at high scores, warn at mid, fail at low).

How the verdict maps to evidence

• Pass: every sampled host has 30+ days remaining.
• Warn: at least one host between 14 and 30 days.
• Fail: at least one host expired or under 14 days remaining.

Evidence shows tls_expiry_rows for each evaluated host: hostname, expired flag, days_to_expiry, band, and per-host score.

Special states

• Unavailable: no HTTPS samples could be obtained. Fix Web Assessability or HTTPS Consistency first.

Fix: automate renewal across every host

The per-host setup is in the Certificate Validity guide (Web Application Security). The unique angle of this check is multi-host aggregation: every HTTPS host in the sample is graded individually, and the worst one wins. Two patterns are common failure causes:

Apex auto-renewing, www manually renewed (or vice versa)

Apex (yourdomain.tld) is on Let's Encrypt with certbot auto-renewal. www.yourdomain.tld got a different cert during a launch deploy that never made it onto the renewal pipeline. Apex stays at 89-day renewal cycles; www quietly approaches 0. Fix: include every public hostname in one ACME pipeline.

sudo certbot certonly --nginx \
  -d yourdomain.tld -d www.yourdomain.tld

# This issues a single cert with both SANs and a single renewal lifecycle.

Subdomains scoped under different teams

api.yourdomain.tld lives in the platform team's infra; admin.yourdomain.tld lives in the IT team's setup. Each team thinks the other handles renewal; one quietly expires. Fix: a single source of truth for cert lifecycle. Either:

• Centralize via wildcard (*.yourdomain.tld) on one ACME pipeline. Every subdomain inherits the cert.
• Centralize via per-host ACME on the same shared pipeline (Kubernetes cert-manager, AWS ACM, Cloudflare). Every host renews from the same orchestrator.
• Document and monitor cross-team ownership: each subdomain has a named owner team and a monitored renewal alert.

Per-platform pointers (see Certificate Validity for details)

• Managed platforms (Vercel, Netlify, Cloudflare Pages, Render, Heroku): auto-renewal is built in; check the dashboard for any custom domains in PENDING_VALIDATION state.
• CDN front door (Cloudflare Universal SSL, AWS ACM + CloudFront, Fastly): auto-renew when DNS validation records remain in place.
• Self-hosted with ACME: certbot, Caddy (default-on), Traefik, acme.sh; each provides automated renewal via cron or systemd timer.
• Commercial CAs: insist on ACME or REST-API automation in the contract.

Independent monitoring (do not trust automation alone)

Renewal pipelines fail silently. Run independent expiry monitoring across every host:

• Uptime monitors with TLS-expiry alerts: Pingdom, UptimeRobot, Datadog Synthetics, Better Stack.
• Self-hosted: Prometheus + blackbox_exporter exposes probe_ssl_earliest_cert_expiry per host; alert when any drops below 30 days.
• Email reminders from your CA. Let's Encrypt sends warnings to the email registered with your account; do not rely on this alone but it is a useful backstop.
• Renew at 30 days minimum to avoid hitting the warn band of this check between scans.

Verify the fix

• For each sampled host listed in the evidence: openssl s_client -connect host:443 -servername host < /dev/null 2>/dev/null | openssl x509 -noout -dates.
• Single-line check across many hosts: for h in apex www api admin; do echo "$h: $(echo | openssl s_client -connect $h.yourdomain.tld:443 -servername $h.yourdomain.tld 2>/dev/null | openssl x509 -noout -enddate)"; done
• Run your ACME renewal dry-run periodically: sudo certbot renew --dry-run.
• Re-run the RedScore lookup. The composite reflects the worst host; pass requires every sampled host above 30 days.

Common pitfalls

• Worst-host scoring punishes outliers. One forgotten subdomain pulls the score from pass to fail. Inventory every public hostname; do not let any sit outside the renewal pipeline.
• Different cert authorities for different hosts. Each authority has its own renewal cadence and lifecycle. Centralize where possible.
• Wildcard cert covering many hosts but expiring centrally. A single failure here loses every host at once. Always have a working backup path (manual issuance to a backup ACME account) for high-stakes wildcards.
• Cert renewed but not deployed. Multi-host clusters need the renewed cert distributed to every node; reverse proxies cache certs in memory until reload. cert-manager and ACME-aware orchestrators handle this; manual setups need a sync step.
• ACME validation broken on one specific host. HTTP-01 challenges depend on the .well-known/acme-challenge path being reachable. If a CDN, load balancer, or auth wall intercepts that path on one host, renewal fails for that host alone. Run --dry-run per host periodically.
• Treating the days_to_expiry: null case as safe. The check awards full credit when it cannot read the date, but unread dates often mean a deeper TLS handshake problem worth investigating. Cross-check with the TLS Chain Trust check.