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

Self-signed certificate: swap in a publicly trusted one and drop the warning

Replacing a self-signed certificate with a CA-issued one clears the browser's trust warning for every visitor

The threat

Your site is serving HTTPS, but the certificate it presents was signed by itself, or by an authority no browser recognizes, rather than by a public Certificate Authority. Encryption still happens, yet the browser has no way to confirm the certificate is genuinely yours, so it will not trust it. The scanner saw this as a broken chain: the issuer is in no trusted root store, the classic NET::ERR_CERT_AUTHORITY_INVALID.

To a visitor this looks exactly as alarming as an expired certificate, a full-page “your connection is not private” warning that most people back away from. Self-signed certificates are common on internal tools and staging boxes, where clicking through the warning is normal, and the trouble starts when that same setup gets pointed at real public traffic. The fix is not to convince visitors to trust your certificate, it is to serve one that every browser already trusts out of the box, which today is free.

The exact fix

Fastest path, a managed certificate. On Netlify, Vercel, or Cloudflare Pages, point your domain’s 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. at the host and enable the managed certificate. The platform provisions a publicly trusted certificate (Let’s Encrypt or similar) automatically and renews it, and your self-signed certificate drops out of the path entirely.

Self-managed with certbot / Let’s Encrypt. On your own nginx or Apache server, certbot obtains a real, publicly trusted certificate and installs it in place of the self-signed one in a single command:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Apache: sudo certbot --apache -d yourdomain.com -d www.yourdomain.com

certbot rewrites your server config to use the new certificate, then sets up automatic renewal. Confirm the renewal path is healthy:

sudo certbot renew --dry-run

Tip: the certbot HTTP-01 challenge needs port 80 reachable from the internet and DNS already pointing at this server. If the box is genuinely internal (a staging or admin host that should not be public at all), the right fix may be to keep it off the public internet rather than to get it a public certificate. A self-signed certificate is fine for something only you reach.

Verify it

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>&1 | grep -iE "verify return code|issuer"

You want Verify return code: 0 (ok) and an issuer that names a real CA (for example Let’s Encrypt), not your own domain. A self-signed certificate shows a nonzero verify code and an issuer identical to the subject.

Proof

You do not reach an A / 100 grade with a self-signed certificate, a publicly trusted one is the baseline, and dev3lop.com was taken from a failing grade to exactly that A / 100. The ApeCyber scanner reads the certificate’s issuer chain passively on every scan, from the outside and touching nothing, so an untrusted certificate is caught the same way a browser catches it.