Your Website's Security Certificate Isn't Trusted by Browsers

Vulnerability Explanation

The server is presenting a TLS certificate that was signed by its own private key rather than by a trusted Certificate Authority (CA). Browsers and API clients maintain a built-in list of trusted root CAs; because a self-signed certificate does not chain to any of these roots, clients cannot cryptographically verify the server's identity. This negates a core purpose of TLS: endpoint authentication. Without it, a network-positioned attacker can present their own self-signed certificate during a connection, and the client has no reliable mechanism to distinguish the legitimate server from the impostor — enabling man-in-the-middle (MITM) interception. Additionally, self-signed certificates cannot be revoked through standard mechanisms (OCSP/CRL), meaning a compromised certificate has no kill switch.

Root Cause

A self-signed certificate was generated locally (e.g., via openssl req -x509 or a server's auto-generated cert) and deployed to production without obtaining a CA-issued certificate. This is common when a service is stood up quickly for testing and the certificate is never replaced before going live.

Technical Impact

A network-positioned attacker can perform a MITM attack by presenting their own certificate in place of the server's. Because there is no trusted CA to validate against, clients that bypass the browser warning (or API clients with certificate validation disabled) will encrypt traffic to the attacker's key, allowing decryption of credentials, session tokens, and sensitive data in transit. The certificate also cannot be revoked if the private key is compromised.

Severity Justification

Exploitation requires a network-positioned attacker (e.g., same network segment, ARP/DNS poisoning, or rogue Wi-Fi). Modern browsers display prominent warnings that most users will not bypass, reducing real-world exploitability. However, API clients and internal tooling often disable certificate validation when self-signed certs are present, which significantly increases risk in those contexts.

Affected Components

• Self-signed TLS certificate — all versions

Remediation Steps

1. Obtain a free, trusted certificate from Let's Encrypt using Certbot. For Nginx: `sudo apt install certbot python3-certbot-nginx && sudo certbot --nginx -d yourdomain.com`. For Apache: `sudo apt install certbot python3-certbot-apache && sudo certbot --apache -d yourdomain.com`. Certbot will automatically configure the web server and set up HTTP→HTTPS redirects.
2. If the server is not publicly accessible (internal service), set up a private internal CA and distribute its root certificate to all client trust stores, rather than using a self-signed cert. This preserves chain-of-trust validation.
3. Enable automatic renewal. Certbot installs a systemd timer or cron job by default. Verify it with: `sudo certbot renew --dry-run`.
4. After replacing the certificate, audit any API clients, CI/CD pipelines, or internal services that connect to this endpoint and remove any `verify=False`, `--insecure`, or `ssl_verify=false` flags that were added to work around the self-signed cert.
5. Test the new certificate with Qualys SSL Labs: https://www.ssllabs.com/ssltest/

Verification Steps

1. Run `curl -vI https://yourdomain.com 2>&1 | grep -E 'issuer|subject|SSL'` and confirm the issuer is Let's Encrypt or your chosen CA, not the server itself.
2. Visit https://www.ssllabs.com/ssltest/ and enter your domain — a valid CA-issued cert should score A or higher with no trust errors.
3. In a browser, navigate to the site and confirm the padlock icon appears without any warning interstitial.
4. Check renewal is scheduled: `sudo systemctl status certbot.timer` (systemd) or `sudo crontab -l | grep certbot`.

Code Examples (nginx)

# Nginx config pointing to a self-signed certificate
ssl_certificate     /etc/ssl/certs/self-signed.crt;
ssl_certificate_key /etc/ssl/private/self-signed.key;

# Nginx config after Certbot replaces with Let's Encrypt certificate
ssl_certificate     /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
include             /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;

Best Practices

• Never deploy self-signed certificates to production or any externally accessible service — use Let's Encrypt (free) or a commercial CA.
• Automate certificate renewal and set up expiry monitoring alerts (e.g., via UptimeRobot, Datadog, or `certbot renew --dry-run` in CI) to prevent silent expiry.
• Audit all services that connect to this endpoint and ensure certificate validation is never disabled in client code — `verify=False` in Python requests or `--insecure` in curl are red flags.
• For internal services that cannot use a public CA, deploy a private internal CA and distribute its root certificate to client trust stores rather than using self-signed certificates.

References

• letsencrypt.org/
• certbot.eff.org/
• www.ssllabs.com/ssltest/
• owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_SSL_TLS_Ciphers_Insufficient_Transport_Layer_Protection
• cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html