What Self-Signed Means
A normal public HTTPS certificate is signed by a Certificate Authority or an intermediate that chains to a trusted root. A self-signed certificate signs itself — the issuer field and subject field reference the same key. There is no external trust chain for the browser to follow, so the browser cannot automatically determine whether the server is who it claims to be.
How CA Chain Trust Works vs Self-Signed
When a browser connects to an HTTPS site, it receives the server's certificate and any intermediate certificates the server sends. It then walks the chain: each certificate must be signed by the one above it, terminating at a root certificate already present in the browser or operating system trust store. Root stores are curated lists maintained by Apple, Microsoft, Mozilla, and Google. A certificate is trusted when this chain is intact, the signatures are valid, the certificate is not revoked, and none of the certificates have expired. A self-signed certificate cannot satisfy the chain requirement because there is no signer above it that the trust store already knows about. The browser treats the certificate as its own root and immediately fails verification since that root was never installed.
Encryption vs Identity
| Question | Self-Signed Certificate | Public CA Certificate |
|---|---|---|
| Can it enable TLS encryption? | Yes | Yes |
| Will browsers trust it automatically? | No | Usually yes |
| Does it prove public domain control? | Not by itself | Yes, through CA validation |
| Good for public websites? | No | Yes |
| Good for private labs or internal use? | Sometimes, with explicit trust | Sometimes, with private CA |
Browser Warnings and Why They Appear
When a browser encounters a self-signed certificate, it displays a full-page interstitial warning. In Chrome the error code is ERR_CERT_AUTHORITY_INVALID; Firefox shows SEC_ERROR_UNKNOWN_ISSUER. The warning is not cosmetic. It means the browser has no way to verify that the server is the intended destination rather than an attacker presenting their own self-signed certificate. The "Advanced" bypass option that lets users proceed teaches a dangerous habit: it trains users to ignore certificate errors, which undermines protection against real attacks.
When Self-Signed Certificates Make Sense
- Local development on
localhostwhere the browser's own localhost exception applies. - Private lab services where you pin or manually install the certificate fingerprint.
- Internal device management consoles where the certificate fingerprint is verified out of band.
- Temporary testing before a real certificate is issued from Let's Encrypt or another CA.
- Private PKI environments where your own root CA is intentionally installed on managed devices.
- mTLS between microservices in isolated networks where both sides are configured by the same operator.
Generating a Self-Signed Certificate with OpenSSL
The standard tool for generating self-signed certificates on Linux, macOS, and Windows Subsystem for Linux is OpenSSL. A minimal command that creates a 2048-bit RSA key and a certificate valid for 365 days looks like this:
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=myservice.internal"
For development use, adding a Subject Alternative Name (SAN) extension is important because modern browsers reject certificates that include only a Common Name. A SAN can be added via an OpenSSL config file or with the -addext "subjectAltName=DNS:myservice.internal" flag available in OpenSSL 1.1.1 and later. For local HTTPS development, tools like mkcert automate both certificate generation and local trust store installation, removing the browser warning on the developer's own machine.
Pinning Self-Signed Certificates
Certificate pinning is a technique where the client is configured to trust only a specific certificate or public key, ignoring the normal trust store. For self-signed certificates in controlled environments, this can be appropriate: an IoT device, a mobile app, or an internal CLI tool can be shipped with the exact certificate fingerprint it expects to see. The risk is that pinned certificates must be rotated before they expire, and any update that changes the certificate without updating the client breaks the connection. Pinning is best suited for closed environments where you control both sides of the connection.
The Warning Click-Through Problem
Deploying self-signed certificates on services that real users visit creates a long-term security debt. Users who see the warning repeatedly learn to dismiss it without reading it. When an actual attack presents a malicious certificate — or when a legitimate certificate expires and is replaced by an attacker's certificate — those same users click through without hesitation. Security teams at organizations that run internal services with self-signed certificates often find that users have been trained to treat certificate warnings as noise. Issuing certificates from a private CA and distributing the root via MDM or group policy eliminates the warning entirely and avoids this conditioning problem.
mTLS with Self-Signed Certificates
Mutual TLS (mTLS) requires both the server and the client to present a certificate during the handshake. In private microservice architectures, both sides may use certificates from a private CA rather than public ones. Self-signed certificates can participate in mTLS if each side explicitly trusts the other's certificate or the CA that signed it. Service mesh tools such as Istio and Linkerd issue short-lived certificates from an internal CA automatically, making mTLS practical without requiring operators to manage individual self-signed certs. The key difference from a single self-signed server certificate is that mTLS setups usually involve a shared private CA, not truly self-signed leaf certificates on each service.
Private CA vs Self-Signed Leaf
A private CA is almost always better for internal systems than a collection of unrelated self-signed leaf certificates. You install one private root certificate on managed devices through MDM, group policy, or a configuration management tool. All internal services get certificates signed by that root, and clients trust them automatically. Revocation becomes possible through CRL or OCSP. Rotation is cleaner because you can issue new leaf certificates from the same root without redistributing trust. The root key must be protected carefully — ideally stored offline or in an HSM — because compromise of the root undermines all certificates issued under it.
Frequently Asked Questions
Are self-signed certificates encrypted?
A self-signed certificate can enable encrypted TLS traffic, but encryption alone does not prove the server's identity to a browser.
Why do browsers warn about self-signed certificates?
Browsers warn because the certificate does not chain back to a trusted Certificate Authority in the browser or operating system trust store.
When are self-signed certificates okay?
They can be acceptable in controlled labs, local development, private internal systems, or device management when you verify and install trust intentionally.