tls.certificate_expiry Reviewed July 2026

Quick fix

Confirm which public component terminates TLS and owns certificate renewal.

What this finding means

SecuTest reads the served certificate's `notAfter` value and warns within 30 days. Expiration is primarily an availability and operational-control failure; it becomes a security problem when users or applications disable validation to keep working.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type Service disruption and warning-bypass impersonation

How the attack or failure scenario works

After expiration, validating clients reject the certificate. Users may be redirected to insecure channels or taught to click through warnings. An attacker with network position can exploit that behavior by presenting another invalid certificate that victims accept.

Conditions and limitations

  • The certificate expires or renewal deploys incorrectly.
  • Clients enforce certificate validity, causing an outage, or users bypass warnings.
  • Impersonation additionally requires an attacker able to intercept or redirect traffic.

Why it matters

Security and business impact An expired or soon-to-expire certificate can cause a production outage, train users to bypass warnings, and weaken confidence in server identity.

Step-by-step fix

Where to make the change

  • The public TLS termination point: CDN, load balancer, reverse proxy, ingress controller, or web server.
  • The origin server only when it directly terminates the externally observed TLS connection.

Remediation procedure

  1. Confirm which public component terminates TLS and owns certificate renewal.
  2. Renew or reissue the certificate before the warning window closes.
  3. Automate renewal and deployment, including service reload and multi-node propagation.
  4. Add independent monitoring for expiration, renewal job failure, and the certificate actually served at the edge.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

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

Certbot dry run
sudo certbot renew --dry-run

Verify the fix

  1. Inspect `notAfter` with OpenSSL and compare it with the deployed certificate inventory.
  2. Run the renewal process in dry-run or staging mode.
  3. Confirm every CDN, load balancer, and node serves the new certificate.
  4. Verify the certificate chain and hostname after deployment.
Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

  • Renewing the certificate file but not reloading the service.
  • Monitoring the CA account expiration date instead of the certificate served publicly.
  • Forgetting a secondary region, IPv6 endpoint, or CDN custom hostname.

Authoritative references