A self-signed certificate is one where the signer and the subject are the same entity — you generate it, and you sign it yourself, rather than getting it signed by a CA already in browser trust stores. It provides identical encryption to a CA-issued certificate; what it lacks is third-party verification of identity.
Legitimate uses
- Local development environments (localhost) where no real visitors will ever connect
- Internal tools on a private network where every client can be manually configured to trust the specific certificate
- Testing TLS configuration before a real certificate is issued
Why it fails in production
A public-facing site using a self-signed certificate will show a full-page browser warning to every visitor — "Your connection is not private" in Chrome, similarly alarming language elsewhere. Since there's no CA vouching for it, the browser has no basis to distinguish a legitimate self-signed certificate from one an attacker generated to impersonate your site.
Generating one for local use
openssl req -x509 -newkey rsa:2048 -nodes \
-keyout localhost.key -out localhost.crt -days 365Why browsers can't tell a legitimate self-signed certificate from a malicious one
The entire reason a browser warns about self-signed certificates is that it has no independent way to distinguish one you deliberately created for local testing from one an attacker created to impersonate a site — both are technically valid TLS certificates, just signed by an untrusted party, which is exactly the ambiguity the warning exists to flag.
A faster alternative for local development: mkcert
Rather than manually generating a self-signed certificate and separately configuring your OS or browser to trust it, the mkcert tool automates the entire process — creating a local certificate authority, installing it in your system trust store, and issuing locally-trusted certificates for any development domain you specify.
What a self-signed certificate's fields actually contain
A self-signed certificate has identical fields to a CA-issued one, Subject, Issuer, validity dates, public key, except its Issuer and Subject fields are the same entity, since it's signing its own claim rather than having a separate party vouch for it — structurally identical, just missing the third-party verification a CA would normally provide.
Why internal, non-public services sometimes use a private CA instead
For internal-only infrastructure never exposed to the public internet, a private, self-operated certificate authority is often a better middle ground than either self-signed certificates or public CA certificates — it lets you issue trusted certificates for internal hostnames at scale without the browser warnings self-signed certificates trigger, while avoiding the constraints public CAs operate under.
The specific browser warning language you'll actually see
Chrome shows a Your connection is not private message with a NET::ERR_CERT_AUTHORITY_INVALID code for a self-signed certificate; Firefox shows a similarly worded Potential Security Risk Ahead warning — both are describing exactly the same underlying fact: there's no trusted third party vouching for this specific certificate.
A closing distinction worth keeping straight
A self-signed certificate and an invalid certificate aren't the same thing — a self-signed certificate can be cryptographically flawless, correctly encrypting every byte exchanged, while still triggering a trust warning purely because no third party vouches for it. The warning is about trust, not about whether the encryption itself is working correctly.
What a corporate or internal PKI setup looks like as a middle-ground alternative
Larger organizations needing certificates for many internal services often deploy their own private, internally-trusted certificate authority rather than either public certificates or scattered self-signed ones — internal devices trust this private CA specifically, giving centralized, warning-free coverage across internal infrastructure.
A closing thought
A quick closing thought: the distinction covered here, self-signed versus CA-issued isn't about security strength but about verified identity, is one of the more commonly confused concepts in this entire category, worth revisiting whenever the difference feels unclear again.