Next-Gen App & Browser Testing Cloud

Trusted by 2 Mn+ QAs & Devs to accelerate their release cycles

What is a Self-signed Certificate?

A self-signed certificate is a public key certificate that is signed with its own private key instead of being issued by a trusted Certificate Authority (CA). It still encrypts traffic between a client and a server, but because no third party vouches for the identity behind it, browsers cannot verify that identity and display a security warning. Self-signed certificates are free, instant to create, and ideal for development and test environments, but they are unsuitable for public-facing production sites.

Understanding Self-signed Certificates

An SSL/TLS certificate lets you encrypt data communications across open networks and binds a public key to an identity such as a domain name. Normally that binding is asserted by a recognized CA, whose signature ensures the integrity of the information in the certificate and eliminates rogue certificates impersonating legitimate enterprises. A self-signed certificate uses a different strategy: the certificate is signed by the same private key it certifies, so it does not require a signature from any CA, public or private.

Technically, a self-signed certificate is a valid X.509 certificate. The difference is trust, not cryptography. The encryption strength is identical to a CA-signed certificate of the same key size, but the chain of trust that browsers rely on is missing. Because the issuer and the subject are the same entity, there is nothing external for a client to check against, which is why self-signed certificates are best confined to environments where you control both ends of the connection.

How Does a Self-signed Certificate Work?

The lifecycle of a self-signed certificate skips the CA entirely. In a nutshell, the process works like this:

Key generation: You create a private/public key pair on your own machine or server.
Certificate details: You define the subject (common name, organization, validity period) that the certificate will assert.
Self-signing: Instead of sending a Certificate Signing Request (CSR) to a CA, you sign the certificate with your own private key.
Installation and trust: To avoid warnings, the certificate must be manually added to the trust store of every client that needs to accept it.

When a browser connects, it walks the certificate chain looking for a root it already trusts. With a CA-signed certificate that root is one of the authorities pre-installed in the operating system or browser. With a self-signed certificate the chain ends at the certificate itself, so the browser stops and raises an error such as NET::ERR_CERT_AUTHORITY_INVALID.

How to Create a Self-signed Certificate with OpenSSL

The most common way to generate a self-signed certificate is with OpenSSL. You can do it in three explicit steps that show each part of the process:

# 1. Generate a 2048-bit private RSA key
openssl genrsa -out key.pem 2048

# 2. Create a Certificate Signing Request (CSR)
openssl req -new -sha256 -key key.pem -out csr.pem

# 3. Self-sign the certificate, valid for 365 days
openssl x509 -req -in csr.pem -signkey key.pem -out cert.pem -days 365

If you prefer a single command that produces both the key and the certificate at once, use the -x509 flag. The -nodes option skips passphrase protection, which is convenient for local testing:

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 -nodes \
  -keyout key.pem -out cert.pem \
  -subj "/CN=localhost"

For modern browsers you should also add a Subject Alternative Name (SAN), because a Common Name alone is no longer sufficient. Once generated, you can inspect the certificate to confirm its fields:

openssl x509 -in cert.pem -text -noout

Self-signed vs CA-signed Certificates

Both certificate types encrypt traffic, but they differ sharply in trust and lifecycle management:

Trust: CA-signed certificates are automatically trusted by browsers; self-signed certificates trigger warnings until manually trusted.
Cost: Self-signed certificates are completely free; CA-signed certificates range from free (Let's Encrypt) to paid tiers with validation and warranty.
Issuance speed: Self-signed certificates are instant; CA validation can take minutes to days depending on validation level.
Revocation: CA-signed certificates can be revoked via CRL/OCSP; self-signed certificates cannot be centrally revoked.
Best fit: Self-signed suits internal, dev, and test use; CA-signed is mandatory for public production websites.

Advantages and Risks of Self-signed Certificates

Self-signed certificates offer clear benefits in controlled environments:

They give developers independence from external certificate issuance.
They are fast and easy to issue, making them useful for test environments.
The owner has complete control over generation, signing, and renewal.
They are free to create and do not require paying a Certificate Authority.

Those same properties create real risks at scale:

Security teams often lack visibility into how many self-signed certificates exist, where they are deployed, who owns them, and how the private keys are stored.
Tracking certificates issued without a formal request or approval process is nearly impossible.
Self-signed certificates cannot be revoked by a CA if a key is compromised.
The inability to swiftly locate and cancel the private key tied to a self-signed certificate poses a significant danger.

Common Mistakes and Troubleshooting

Missing SAN: A certificate with only a Common Name is rejected by modern browsers. Always add a Subject Alternative Name entry for each hostname.
Using it in production: Deploying a self-signed certificate on a public site produces persistent warnings and erodes user trust. Use a CA-issued certificate instead.
Git "self signed certificate in certificate chain" error: This usually means a corporate proxy is injecting a certificate. Add the corporate root to your trust store rather than disabling verification entirely.
Expired certificates: Short validity windows are easy to forget. Track expiry dates and rotate certificates before they lapse.
Unprotected private keys: Leaving the -nodes key unencrypted on a shared server is risky. Restrict file permissions and never commit keys to version control.

Conclusion

A self-signed certificate is a fast, free way to enable encryption when you control both the client and the server, which makes it a natural fit for development, testing, and internal tools. Its weakness is trust: no Certificate Authority backs it, it cannot be centrally revoked, and browsers will warn users. Use OpenSSL to generate one for non-production work, keep private keys protected, add proper SANs, and switch to a CA-issued certificate the moment a service becomes public-facing.

Frequently Asked Questions

Is a self-signed certificate secure?

A self-signed certificate provides the same strength of encryption as a CA-signed certificate, so data in transit is protected. What it lacks is trust: no third party vouches for the identity behind the certificate, so browsers cannot confirm you are talking to the intended server, which is why they show warnings.

What is the difference between a self-signed and a CA-signed certificate?

A self-signed certificate is signed by its own private key, while a CA-signed certificate is signed and validated by a trusted Certificate Authority. CA-signed certificates are trusted by browsers automatically and can be revoked, whereas self-signed certificates are free, instant, but untrusted and non-revocable.

How do I create a self-signed certificate?

Use OpenSSL. Generate a private key with openssl genrsa, then run openssl req with the -x509 flag to produce a certificate signed by that key. A single command such as openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes creates both the key and the certificate at once.

Why do browsers show a warning for self-signed certificates?

Browsers ship with a list of trusted root Certificate Authorities. A self-signed certificate is not in that chain of trust, so the browser cannot verify the site's identity and displays an error such as NET::ERR_CERT_AUTHORITY_INVALID to warn the user of a possible man-in-the-middle risk.

Can a self-signed certificate be revoked?

No. Because there is no Certificate Authority involved, there is no CRL or OCSP responder to revoke a self-signed certificate. If its private key is compromised, the only remedy is to remove it from every trust store manually, which is why self-signed certificates are discouraged for production use.

Where should self-signed certificates be used?

Self-signed certificates are best for development, testing, internal tools, and short-lived environments where you control both client and server. They should never be used on public-facing production websites, where a certificate from a trusted CA is required to avoid browser warnings and to earn user trust.