Self-Signed Certificate Explained

A self-signed certificate is a certificate signed by its own private key rather than by a Certificate Authority. The issuer and subject are the same entity. Self-signed certificates provide encryption but no identity assurance — any web server can generate one for any domain name without restriction.

Why Browsers Don't Trust Self-Signed Certificates

The purpose of a CA is to vouch for the identity of the certificate holder. With a self-signed cert, the entity asserting its identity is also the one signing that assertion — there's no independent verification. A phishing site for bank.com could generate a self-signed certificate for bank.com just as easily as the real bank could.

Identifying a Self-Signed Certificate

Paste the certificate into the decoder. In the Subject and Issuer sections, the fields will be identical (same CN, same O). The Basic Constraints extension will typically show CA:TRUE on self-signed certs used as roots, or may be absent on self-signed leaf certificates.

Appropriate Uses for Self-Signed Certificates

• Local development: localhost development servers (though tools like mkcert are better — they create locally-trusted certs)
• Internal services: When you control both the server and all clients, you can distribute your own root CA to clients instead of using a self-signed leaf cert
• IoT devices: Embedded devices that use device-specific self-signed certificates for encryption without browser-style CA trust

Better Alternatives for Development

Instead of self-signed certificates for local development, consider:

• mkcert: A tool that creates a local CA and installs it in your system/browser trust stores, so certificates it issues are trusted by your local browser without warnings
• Let's Encrypt with a real domain: Even for staging environments, a short-lived Let's Encrypt certificate is free and eliminates browser warnings