A self-signed certificate is one you create yourself — you act as your own Certificate Authority. A CA-signed certificate is issued and signed by a trusted Certificate Authority (like Let’s Encrypt or DigiCert) that browsers already trust.
The practical difference: self-signed certificates trigger browser security warnings. CA-signed certificates don’t.
Comparison
| Self-signed | CA-signed | |
|---|---|---|
| Created by | You (openssl command) | A trusted CA |
| Browser trust | ❌ Warning: “Not trusted” | ✅ Padlock icon |
| Encryption strength | Same | Same |
| Cost | Free | Free (Let’s Encrypt) or paid |
| Validation | None — you vouch for yourself | CA verifies domain/org |
| Use case | Development, internal, testing | Production websites |
| Renewal | Manual (you set the validity) | 90 days (LE) or 1 year (paid) |
| Man-in-the-middle protection | ⚠️ Weak — users trained to click through warnings | ✅ Strong — warnings only on real problems |
Why self-signed certificates show warnings
Browsers trust certificates based on who signed them. Your OS and browser ship with a list of ~100-150 trusted root CAs. When a server presents a certificate signed by one of these CAs, the browser shows a padlock.
A self-signed certificate isn’t signed by any trusted CA — it’s signed by its own private key. The browser has no way to verify that the certificate is legitimate, so it shows a warning. This is the correct behavior — without CA verification, anyone could create a certificate claiming to be google.com.
When to use self-signed certificates
Internal services
Services that aren’t exposed to the internet — internal dashboards, monitoring tools, database admin panels. Your team can add the self-signed CA to their trust stores.
Development and testing
Quick HTTPS for local development when you don’t want to set up mkcert. The browser warning is annoying but functional for testing.
IoT and embedded devices
Devices that communicate with a known server and can pin the certificate — no browser trust store involved.
Air-gapped networks
Networks with no internet access where Let’s Encrypt’s ACME protocol can’t reach. Self-signed is the only option.
When NOT to use self-signed certificates
Any public-facing website
Users see a scary warning and leave. Search engines may not crawl HTTPS pages with untrusted certificates. There’s no reason to self-sign when Let’s Encrypt certificates are free.
Any site handling user data
Self-signed certificates train users to click through security warnings — the opposite of good security. When a real attack triggers a warning, users who are habituated to clicking “Proceed anyway” won’t notice.
How to create a self-signed certificate
# ECDSA (recommended)
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 \
-keyout key.pem -out cert.pem -days 365 -nodes \
-subj "/CN=internal.example.com" \
-addext "subjectAltName=DNS:internal.example.com,IP:10.0.0.5"
# RSA
openssl req -x509 -newkey rsa:2048 \
-keyout key.pem -out cert.pem -days 365 -nodes \
-subj "/CN=internal.example.com"Use the resulting cert.pem and key.pem in your server config. Note: fullchain.pem and chain.pem aren’t needed — there’s no chain with self-signed certs.
Better alternatives for every scenario
| Scenario | Instead of self-signed, use |
|---|---|
| Production website | Let’s Encrypt via GetHTTPS — free, trusted, 5 minutes |
| Local development | mkcert — locally-trusted, no warnings |
| Internal services | Let’s Encrypt (if internet-accessible) or a private CA |
| Testing/staging | Let’s Encrypt staging environment — unlimited test certs |
Self-signed certificates made sense when SSL certificates cost $100+/year. Now that Let’s Encrypt is free, there’s rarely a reason to self-sign for anything beyond truly isolated environments.
Frequently asked questions
Is a self-signed certificate less secure than a CA-signed one?
The encryption is identical — same algorithms, same key strengths. The difference is trust: a CA-signed certificate proves the server’s identity via a trusted third party. A self-signed certificate proves nothing — anyone can create one for any domain. The security issue isn’t the crypto; it’s the lack of authentication.
Can I make browsers trust my self-signed certificate?
Yes, on machines you control. Import the certificate (or a self-signed CA that signed it) into the OS/browser trust store. This is what mkcert automates. But you can’t make other people’s browsers trust it — that requires a real CA.
My hosting provider gave me a self-signed certificate. Is that OK?
No, for a public website. Ask your provider to enable free Let’s Encrypt (most hosts support it). If they don’t, use GetHTTPS to get a trusted certificate yourself.
Why not just create my own CA?
You can, but browsers won’t trust it unless you go through the years-long, expensive process of joining browser trust stores. A private CA works for internal infrastructure (your team installs the root cert), but not for public websites. For public sites, use a trusted CA like Let’s Encrypt.