Self-Signed Certificate

What is a self-signed certificate?

A self-signed certificate is a TLS/SSL certificate that an entity issues and signs for itself, rather than obtaining one signed by a trusted Certificate Authority (CA). Technically it still contains a public key and still enables encrypted connections — the math of encryption works the same. What it lacks is the one thing a CA provides: an independent, trusted third party vouching that the certificate’s holder is who they claim to be. That missing vouching is exactly why browsers throw a scary warning (“Your connection is not private”) when they encounter one.

Encryption vs. trust — the distinction that explains everything

The key insight is that TLS certificates do two separate jobs: they enable encryption (scrambling traffic so eavesdroppers can’t read it) and they provide authentication (proving the server is genuinely who it claims to be). A self-signed certificate does the first perfectly well but fails the second — there’s no trusted CA in the chain saying “yes, this really is example.com.” That gap matters because encryption without authentication is vulnerable to a man-in-the-middle attack: an attacker can intercept the connection and present their own self-signed certificate, and the client has no way to tell the impostor from the real server. The whole CA trust chain — browsers and operating systems ship with a list of trusted root CAs, who sign certificates only after verifying domain ownership — exists precisely to close this gap. A self-signed cert sits outside that chain, so clients can’t validate it, which is why the warning exists and why users should not be trained to click through it casually on the public internet.

When it’s fine — and when it absolutely isn’t

Self-signed certificates are legitimately useful in the right places: local development (testing HTTPS on localhost without buying a cert), internal services where you control both ends and can distribute the cert to clients out-of-band, and testing environments. In those cases you get encryption and you manage trust yourself. Where they’re dangerous is public-facing production: presenting a self-signed cert to real users trains them to ignore security warnings and offers no protection against MITM. And there’s rarely an excuse anymore — Let’s Encrypt provides free, automated, CA-signed certificates, eliminating the old cost/effort justification for self-signing public sites. For internal PKI at scale, organizations run their own private CA and distribute its root to their fleet, which gives the trust benefit internally without a self-signed cert on every service. The recurring mistake is either using self-signed certs on public services (bad) or, worse, configuring clients to disable certificate validation entirely to make self-signed certs “work” — which silently throws away MITM protection everywhere, a far more dangerous habit than the certificate itself.

What people get wrong

• Using them on public production sites — they train users to bypass warnings and give no MITM protection; use free CA certs (Let’s Encrypt).
• Disabling cert validation to accommodate them: turning off verification “to make it work” removes authentication globally — a much bigger hole than the cert.
• Confusing encryption with trust — a self-signed cert encrypts fine but proves no identity, which is the whole point of a certificate.

Primary source: Let’s Encrypt: How it works