What is a self-signed certificate, when is it used, and what are its pros and cons?
A certificate signed with its own private key, so issuer equals subject; free and quick for tests and internal use, but nothing outside vouches for it.
A normal certificate is signed by a CA, and you trust it because you trust that CA. A self-signed certificate is signed by the key it certifies: the subject vouches for itself. The signature only proves the creator holds the private key; it says nothing about whether the name in it is true.
Every root CA certificate is self-signed. There is nothing above the root, so its trust comes from being placed into the trust store deliberately (shipped with the OS or browser, pushed by Group Policy).
| Pros | Cons |
|---|---|
Free, made in seconds (openssl req -x509 …) |
No chain of trust: browsers warn, users learn to click warnings away |
| No dependency on an external CA | Revocation is not possible in any useful way |
| Fine for test environments, lab devices, internal tools | Each client must import or pin it by hand |
| Still gives encryption | Without an out-of-band fingerprint check, a man-in-the-middle can swap in his own self-signed certificate unnoticed |
Typical uses: development and test servers, a device's first-boot web UI (routers, printers), and private services where the certificate is pinned. For anything users reach in a browser, a private CA (as in an AD CS setup) or Let's Encrypt is the better choice.
Go deeper:
Wikipedia: Self-signed certificate — security issues and the root-certificate special case.- Let's Encrypt: How it works — the free, automated alternative for public sites.