Self-signed certificates provide encryption without a trusted Certificate Authority's validation — browsers show warnings for them, but they remain genuinely useful in specific internal/development contexts.
What Makes a Certificate "Self-Signed"
Instead of being signed by a trusted CA, a self-signed certificate is signed by its own private key — providing the same encryption strength as a CA-issued certificate, but with no third-party verification of the certificate holder's identity.
When Self-Signed Certificates Are Appropriate
- Local development environments
- Internal tools/services never exposed to the public internet, where all users already implicitly trust the infrastructure
- Testing TLS configuration before deploying a real certificate
- Internal service-to-service communication where you control both ends and can manage trust directly
When to Use a Real Certificate Instead
For anything public-facing, or anywhere untrusted users will connect, use Let's Encrypt (free) or a commercial certificate instead — self-signed certificates train users to click through security warnings, a genuinely harmful habit for real production use.
Step 1 — Generate a Self-Signed Certificate
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout selfsigned.key -out selfsigned.crt \
-subj "/CN=internal.yourdomain.local"Step 2 — Configure Nginx to Use It
server {
listen 443 ssl;
server_name internal.yourdomain.local;
ssl_certificate /etc/ssl/certs/selfsigned.crt;
ssl_certificate_key /etc/ssl/private/selfsigned.key;
}Making Browsers Trust It (For Internal/Development Use)
Rather than repeatedly clicking through browser warnings, you can add the self-signed certificate to your local trust store — the exact process varies by operating system; search for "add certificate to trust store" for your specific OS.
Creating a Local Certificate Authority for Multiple Internal Services
If you have several internal services, creating your own local CA (see How to Set Up Mutual TLS (mTLS) Authentication for the CA-creation steps) and issuing certificates from it is often better than individual self-signed certificates — you only need to trust your CA once, and it then validates all certificates it issues, similar to how public CAs work.
Setting a Reasonable Expiration
openssl req -x509 -nodes -days 90 ...Shorter validity periods for self-signed certificates encourage a habit of periodic renewal/review, though this is a matter of personal/team preference for internal use rather than a strict security requirement.
Common Mistakes with Self-Signed Certificates
- Using them for a genuinely public-facing service (undermines user trust and security awareness)
- Sharing the private key insecurely, treating it as less sensitive than a "real" certificate's key just because the certificate itself isn't CA-validated
- Never rotating them, leaving the same key/certificate in use indefinitely
Common Errors
"NET::ERR_CERT_AUTHORITY_INVALID" in the browser — expected behavior for a self-signed certificate not added to your trust store; this is the browser correctly identifying it as unverified by a recognized CA.
Continue Reading
- How to Set Up Mutual TLS (mTLS) Authentication
- How to Secure a VPS Without a Domain Name (IP-Only SSL Options)
- Understanding SSL Certificate Types: DV vs OV vs EV
Browse more articles in SSL/TLS & Certificates.
