What Is a Self-Signed Certificate and When Is It Safe to Use?

A self-signed certificate is one signed with its own private key, so the issuer and the subject are the same. Nobody else vouches for it. It encrypts traffic like any certificate but proves nothing about identity unless you trust it by a separate, deliberate step.

What does the standard say?

RFC 5280, the Internet X.509 profile, defines the terms precisely. Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-signed certificates are a subset: self-issued certificates where the signature can be verified using the public key inside the certificate itself. The RFC says self-signed certificates are used to convey a public key for use to begin certification paths.

That last point explains something that confuses many people. Every root certificate authority certificate is self-signed. The difference is trust. Your operating system or browser ships with a list of roots it already trusts, so a chain that ends at one of them is accepted. A random self-signed certificate ends at nothing you trust, so clients warn or refuse.

RFC 5280 also describes certification paths as starting from a CA public key the relying party already trusts, which may be in the user's own domain. That is the legitimate use of private roots inside an organization.

Why do clients complain about them?

A certificate's value is the answer to "is this really the server I meant to reach?" A trusted authority answers by checking the requester before issuing. A self-signed certificate skips that check. If an attacker sits between you and the server, they can present their own self-signed certificate and, if you click through the warning, read everything.

The encryption is real but the identity is unproven. That combination is the problem, and it is why training users to accept warnings is harmful.

When is it acceptable?

• Local development, on your own machine, where you control both ends.
• Short-lived test environments that never hold real data.
• Devices where you install the certificate yourself and pin or import it deliberately, such as a lab appliance.

For anything with more than one user, a better path is a private certificate authority. You create one root, install that root's certificate on your managed devices, and issue server certificates from it. Clients then trust your servers without warnings, and you can revoke or rotate certificates. For public sites, use a certificate from a publicly trusted authority.

A constructed example

A team spins up an internal dashboard with a self-signed certificate. Engineers add an exception in their browsers. Months later the dashboard reads production metrics, and a contractor on the guest network gets the same warning and clicks through, as everyone else does.

An attacker on that network could have done the same trick with a different certificate, and nobody would notice. The team replaces the setup with a small private CA. The root is pushed to managed laptops, the dashboard gets a certificate from it, and the warning disappears, which means a future warning actually means something.

How to check or apply this

1. Search your environment for services presenting self-signed certificates, including appliances and internal tools.
2. For each, decide: replace with a certificate from a public authority, replace with one from your private CA, or accept as local test only.
3. Never use self-signed certificates for services that hold real data or serve people outside your control.
4. If you run a private CA, protect its root key offline, use short-lived server certificates, and keep an inventory.
5. Install the private root only on devices you manage.
6. Turn off any practice of telling users to "just click continue" past certificate warnings.
7. Set reminders for expiry, since expired self-signed certificates are a frequent cause of outages.

Quick check

Sources

• RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Last reviewed: 18 October 2026.