mediumSeverity: mediumRisk ratingHow usable this gap is to an attacker. Severity sets the posture penalty: critical −40, high −20, medium −10, low −4, info −1. Higher severity means fix it sooner.TLS certificateWhere it livesImplementationThis fix is applied in: TLS certificate. That's the surface you'll edit, DNS, response headers, or a static file.~5 minTime to fixEffortRoughly 5 minutes of hands-on work, propagation aside. Most of these are copy-paste.+10 posture+10 postureScore impactPoints this fix recovers in the ApeCyber posture score (0–100). Posture = 100 minus the severity penalty of every open finding; clearing this finding adds these points back.

TLS certificate expiring soon: let it renew itself before the deadline

Automated renewal plus expiry alerts refresh the certificate well before it can ever lapse

The threat

Your certificate is still valid and trusted right now, so nothing is broken for visitors today. But the scanner read its notAfter date and it falls inside the next 21 days. This is the early-warning check: it is telling you the runway is short while you still have calm, unhurried time to act, rather than after the site has already gone dark.

If nothing changes, the certificate expires on schedule and the day after that every visitor meets a full “connection not private” warning instead of your site. The only difference between this finding and the critical “expired” one is timing, and timing is a solved problem: certificates are meant to renew themselves automatically, so reaching this window at all usually means the renewal loop is missing or was never switched on. The fix is to close that loop and add a couple of alerts as a backstop.

The exact fix

Managed host. On Netlify, Vercel, Cloudflare Pages, and similar, renewal is automatic and happens weeks ahead of expiry. If you are seeing this warning on a managed host, check that both the apex and its www variant are still attached and that DNSDNSInfrastructureThe Domain Name System, the internet's address book. It's also where you publish the SPF, DKIM, DMARC and CAA records that secure your domain. has not drifted to point somewhere else. Re-attaching the domain lets the platform renew normally again.

Self-managed with certbot. Do not plan to renew by hand, that is the very habit that produces expiring certificates. Enable the renewal timer once and let it run unattended:

sudo systemctl enable --now certbot.timer
sudo systemctl list-timers certbot.timer
sudo certbot renew --dry-run

list-timers should show the next scheduled run, and the dry run should finish without errors. Together that means the certificate renews on its own at roughly 60 days, long before this 21-day window.

Add alerting as a backstop, so a silent failure still reaches a human:

  • Point an uptime or certificate monitor at the domain and have it alert at 30, 14, and 7 days remaining.
  • Even a small scheduled job that reads the expiry and emails you covers the case where the renewal timer itself breaks.

Tip: the goal is that a healthy certificate never triggers this warning again, because it renews around 60 days and the check only fires inside 21. If you keep landing here, the timer is not actually running, fix that rather than renewing by hand each cycle.

Verify it

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -checkend 2592000

-checkend 2592000 asks “will this still be valid in 30 days?” A healthy certificate answers Certificate will not expire. If it says it will expire, your renewal has not run yet, go back and confirm the timer.

Proof

Both apecyber.com and dev3lop.com sit behind managed certificates that renew automatically, weeks ahead of the window this check watches, which is exactly why neither ever trips it. The ApeCyber scanner reads the days-remaining passively on every scan, from the outside and touching nothing, so a stalled renewal surfaces as a quiet −10 to fix this week instead of a critical outage next month.