In one paragraph
A TLS certificate expiring soon finding means the certificate observed at the scanned HTTPS endpoint is approaching its validity deadline or has already expired. Renew it and confirm the public service actually presents the replacement. Then repair the renewal, validation, deployment, and alerting process. A new file on disk does not protect visitors if the active TLS endpoint still serves the old certificate.
Why it matters
An expired certificate normally causes validating clients to reject the connection. Visitors may see a certificate warning, while API callers and integrations fail before an ordinary HTTP request reaches the application. Treat imminent expiry as an availability risk as well as a maintenance issue.
The certificate visible to the scanner may belong to a CDN or load balancer. An independently expiring origin certificate can break the edge-to-origin connection without being the certificate this public probe reads. Monitor both connections where applicable.
Automation is necessary but not self-verifying. Renewal can fail because of DNS changes, unavailable validation routes, credentials, CAA restrictions, or an activation hook that never reloads the service. Some renewals follow ACME Renewal Information rather than a universal fixed date; do not assume every certificate has the same lifetime or renews exactly thirty days before expiry.
How WebAuditOS evaluates this finding
The supplied site-wide rule reads the scanned host's leaf certificate and rounds remaining lifetime down to whole days. More than 30 days passes; 15-30 days warns; 14 days or fewer fails at high severity; an already expired certificate fails at critical severity. Non-HTTPS or incomplete handshakes are not graded by this rule.
These are scanner thresholds, not a certificate authority's renewal schedule. Only the probed hostname and port are covered. No result from an incomplete handshake is not evidence of a healthy certificate, and a fresh certificate for www does not establish apex or API coverage.
How to fix it
- Inspect the exact public hostname and TLS termination point in the finding. Check validity dates, subject alternative names, issuing chain, and whether multiple edges or instances serve different certificates.
- Review renewal status at the owner of the certificate. For a managed platform, inspect its validation and renewal diagnostics. For a self-managed ACME client, review job history and current client documentation rather than immediately requesting repeated replacement certificates.
- Test renewal safely. A Certbot-style deployment can use:
certbot renew --dry-runConfirm the relevant timer or scheduler runs and the challenge succeeds. A successful dry run checks the tested renewal path; it does not automatically prove every custom production deployment hook has activated a new certificate.
- Repair the cause of failure. Check HTTP-01 or DNS-01 validation, permission to update required records, credentials, and the destination of any redirect. Avoid disabling unrelated security controls without identifying the actual blocked step.
- Install the appropriate leaf-and-intermediate bundle and activate it at the TLS endpoint. Use a validated reload or the provider's supported deployment mechanism. Preserve private-key confidentiality and ensure the certificate matches its key.
- Reconnect from outside and confirm the newly served dates, names, trust, and chain. A process may keep the previous certificate in memory until reloaded. Test all intended hostnames and any separately configured origin connection.
- Add expiry monitoring independent of the renewal job, with thresholds suited to the certificate's actual lifetime and operational response needs. Assign an owner for alerts and failed validation, not merely an email address nobody checks.
- Rescan and repeat important API or login journeys. Watch across subsequent renewal cycles so a manual repair becomes a durable process.
What the fix can break
Reissuing with missing hostnames can create a new name-mismatch outage. A different intermediate chain can affect some clients, and incorrect key or file permissions can prevent activation. Validate before swapping configuration.
Certificate or public-key pinning in owned clients requires a planned rollover strategy. Do not assume every integration will accept an otherwise valid replacement without testing.
A brief warning near a normal renewal window can occur, but persistent warnings demand investigation. Use actual client status and deployment evidence rather than either panicking over one threshold or ignoring every expiry alert as routine.
Questions
Why does the site still show the old certificate after renewal?
The active TLS process, edge, or another instance may not have loaded the replacement. Inspect the served connection, not only the filesystem.
Does the scan check our origin certificate behind a CDN?
Normally it sees the public TLS endpoint for the scanned hostname. Monitor the separate origin connection independently if used.
Should every renewal happen thirty days before expiry?
No. Lifetimes and renewal guidance vary, including ARI-driven timing. Follow the issuer and client's current supported process.
Which related checks help?
Review certificate-chain validation and HTTPS availability.