criticalSeverity: criticalRisk 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.~10 minTime to fixEffortRoughly 10 minutes of hands-on work, propagation aside. Most of these are copy-paste.+40 posture+40 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.

Expired TLS certificate: renew now, then automate so it never lapses again

Renewing the certificate clears the browser's 'not secure' interstitial immediately, and auto-renewal keeps it gone

The threat

The scanner completed an ordinary TLS handshake with your site, read the certificate it presented, and found the notAfter date is already in the past. That certificate is expired. Every modern browser treats an expired certificate as a hard trust failure, so visitors do not get a subtle nudge, they get a full-page interstitial: “Your connection is not private,” NET::ERR_CERT_DATE_INVALID, with your actual site hidden behind a button most people never click.

This is not a future risk, it is live right now for everyone who visits, which is why the spec calls it losing customers today rather than hypothetically. The usual cause is an auto-renewal that quietly stopped working (a moved 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. record, a firewall change, a paused job) so the lapse went unnoticed until traffic dropped. The fix therefore has two halves: get a valid certificate back in place immediately, then repair the automation that was supposed to prevent this.

The exact fix

Fastest path, a managed certificate. If your site sits on a managed host (Netlify, Vercel, Cloudflare Pages, and similar), the platform issues and renews the certificate for you. Open the domain’s TLS settings and re-provision, or confirm the domain’s DNS still points at the host. The managed certificate replaces the expired one within minutes and renews itself from then on.

Self-managed with certbot / Let’s Encrypt. On your own nginx or Apache box, force a renewal now and reload the server so it serves the fresh certificate:

sudo certbot renew --force-renewal
sudo systemctl reload nginx   # or: sudo systemctl reload apache2

Then repair the automation that failed, so you never land here again. certbot installs a renewal timer; make sure it is enabled and actually firing:

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

The dry run rehearses the whole renewal without spending rate limits. If it passes, the real renewals (which run at roughly 60 days on a 90-day certificate) will too.

Tip: an expired certificate almost always means the renewal job broke weeks ago, not that renewal is impossible. Do not just renew and walk away, confirm the timer is enabled and the dry run passes before you close the ticket.

Verify it

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

You want the notAfter= date to be comfortably in the future. Reload your site in a fresh browser tab and the “not secure” interstitial should be gone.

Proof

apecyber.com runs on a Netlify-managed certificate that renews itself automatically, so it never reaches the expired state this check catches. The ApeCyber scanner reads the certificate’s expiry passively on every scan, from the outside, using the same handshake any browser makes and touching nothing on your server, so a lapse surfaces here before it surfaces as a lost sale.