What Is a Self-Signed Certificate?

A self-signed certificate is one signed by its own private key instead of by a trusted certificate authority. It claims an identity and then, in effect, vouches for itself. That circular signature is exactly why browsers refuse to trust it for public websites: nothing independent confirms that the certificate belongs to who it says it does. The encryption still works, but the identity guarantee that makes public TLS meaningful is absent. If the underlying concepts here feel fuzzy, our pillar guide, SSL/TLS certificates explained, lays out the fundamentals first.

Think of the difference as trust versus encryption. A self-signed certificate can scramble a connection so eavesdroppers cannot read it, yet it offers no way for a visitor to know the server is genuine rather than an impostor. A normal certificate solves that by having a CA verify the requester and sign on its behalf, producing a path back to a root the browser already trusts. The rules CAs follow when performing that verification live in the CA/Browser Forum Baseline Requirements. For the broader picture of how all of this fits together, the pillar, SSL/TLS certificates explained, is the place to go.

No CA, no chain

In a properly issued certificate, the file points to the intermediate that signed it, which points to a root. A self-signed certificate has no such ancestry. Its issuer and its subject are the same entity, so the chain begins and ends in one place. The X.509 certificate profile describes how clients try to build a path from a presented certificate up to a trusted anchor; with a self-signed certificate there is no external anchor to reach, so the path cannot be completed against the browser's trust store.

Why the browser warning appears

When you load a site secured by a self-signed certificate, the browser walks the chain, finds no trusted root at the top, and stops. It cannot tell a legitimate self-signed certificate from one an attacker generated five minutes ago, because neither has been verified by anyone. So it shows a full-page interstitial: the connection is encrypted, but the identity is unverified, and the user is asked to accept the risk. That warning is doing its job. Training users to click through it is precisely the habit attackers rely on.

Self-signed versus CA-issued

The two are easy to confuse because both enable HTTPS. They differ in what they prove and where they belong.

Aspect	Self-signed	CA-issued
Signed by	Its own private key	A trusted certificate authority
Chain of trust	None; issuer equals subject	Links to a trusted root
Browser behavior	Security warning by default	Loads without warning
Identity verification	None	CA validates the requester
Encryption strength	Same algorithms available	Same algorithms available
Cost	Free to generate	Free options exist (Let's Encrypt)
Right place to use	Internal, dev, testing	Any public-facing site

The takeaway from the table: a self-signed certificate is not weaker cryptography, it is unverified identity.

Where self-signed certificates genuinely belong

There are real, sensible uses. They shine anywhere you control both the server and the clients that connect to it.

• Local development, where you just need HTTPS on a laptop and warnings are noise.
• Automated testing and CI pipelines that talk to throwaway services.
• Internal tools and dashboards behind a VPN, especially when you distribute the certificate to a known set of machines.
• Internal PKI, where an organization runs its own certificate authority and pins or pre-installs its root on managed devices so the chain resolves internally.

In each case the trust gap closes because you decide which certificates the clients accept. That is the whole trick: you become the trusted party, deliberately and within a controlled boundary.

Why never on a public site

The moment strangers visit, the model breaks. You have no way to push your certificate to every visitor's device, so each one sees the warning. Worse, you teach people that the alarm is safe to dismiss, which erodes the protection for everyone. There is simply no upside, because the free alternative removes every reason to take the risk.

The free alternative

You do not have to choose between cost and trust. Let's Encrypt and other ACME-based authorities issue genuine, browser-trusted certificates at no charge, and the ACME protocol automates issuance and renewal so the whole process runs unattended. For a public site, an automated CA certificate is strictly better than a self-signed one: same encryption, real identity, no warnings.

If you suspect a domain is serving a self-signed or otherwise untrusted certificate, run a free SSL check at domainintel.app and find out in seconds. For the warnings it can surface, see SSL certificate chains explained and common SSL errors.