Self-signed certificate
A cert signed by its own private key, not by a trusted CA. Useful for testing; browsers reject it for production sites.
A self-signed certificate is a TLS cert where the "issuer" and the "subject" are the same: the cert vouches for itself instead of being signed by a trusted Certificate Authority. You can generate one in 30 seconds with openssl.
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes
Why browsers reject them
Browsers trust certs only if they chain to a CA in the OS trust store. A self-signed cert chains to itself, which isn't trusted. Result: scary red warning page in production.
That's by design. The CA system exists to make sure the cert you're presenting actually belongs to who you claim to be. A self-signed cert has no such verification.
When self-signed certs ARE the right answer
- Local development.
localhosttesting, internal hostnames, integration tests. Trust manually on your dev machine. - Private internal services. A cert signed by your own corporate CA is technically self-signed at the root, but trusted because the corporate CA is in employee laptops' trust stores.
- Bootstrap. Some IoT or embedded systems use a self-signed cert at first boot, then enroll a real cert via mTLS.
When self-signed certs are wrong
- Anywhere a public browser will visit. The user sees the warning, leaves. Trust burned.
- Anywhere a third-party API will call you over HTTPS. Most API clients reject self-signed certs by default; some allow opt-out, all of them log it as suspicious.
- Anywhere compliance is in scope. SOC 2 / PCI auditors note self-signed certs in scope as findings.
"I see a self-signed cert in production, what do I do?"
Check whether the host you're connecting to is the intended one. If yes, ask the operator to install a real cert (Let's Encrypt is free). If no, you're being intercepted; bail and investigate.