Self-Signed SSL Certificates: When to Use Them and When Not To

A self-signed certificate is one that you sign yourself instead of having a Certificate Authority sign it. It provides the same encryption — the TLS handshake, the encrypted tunnel, all of it — but it carries no third-party identity verification. Because browsers and operating systems only trust certificates from CAs in their pre-installed root store, your self-signed certificate will trigger a "Your connection is not private" warning on every visitor's browser.

How to Create a Self-Signed Certificate with OpenSSL

Generating a self-signed certificate takes one command. The example below creates a certificate valid for 365 days covering localhost and a local IP:

Breaking this down:

• -x509 — Output a self-signed certificate instead of a CSR
• -newkey rsa:2048 -nodes — Generate a 2048-bit RSA key with no passphrase
• -days 365 — Certificate validity period
• -addext "subjectAltName=..." — SANs are required by modern browsers; CN alone is ignored

Use It for Local Development

The most common legitimate use of a self-signed cert is running HTTPS on a local development server. Many modern web features (service workers, camera/microphone access, certain APIs) only work over HTTPS, so http://localhost isn't always sufficient.

For local dev, consider mkcert instead of a raw self-signed cert. It creates a local CA that it installs into your system's trust store, so you get a certificate that your browser actually trusts without warnings — while still being completely isolated from the internet.

How to Install a Self-Signed Certificate on Apache/Nginx

The configuration is identical to a CA-signed certificate — just point to your self-signed files:

Trusting a Self-Signed Certificate in Your Browser

For team use on an internal tool, you can distribute your self-signed cert and have team members add it to their OS/browser trust store. On macOS, drag the .crt file into Keychain Access and set it to "Always Trust." On Windows, double-click the cert and install it into "Trusted Root Certification Authorities." On Firefox, go to Settings → Certificates → View Certificates → Import.

Self-Signed vs Let's Encrypt: The Decision

For anything accessible from the internet, Let's Encrypt removes every excuse for using a self-signed certificate. It's free, automated, and browsers trust it without any warnings. The only scenario where self-signed is genuinely better is when your server has no domain name (only an IP address), is fully offline, or is on an air-gapped network where CA validation isn't possible.

FAQs

• Does a self-signed certificate provide real encryption?
  Yes. The encryption algorithm is identical to a CA-signed certificate — AES-256 for the session, RSA or ECC for key exchange. What's missing is identity verification. You know the connection is encrypted, but you can't prove to visitors that the server belongs to who it claims to be.
• Will Google penalize my site for using a self-signed certificate?
  Visitors will see a security warning and most will leave before your page even loads. That's a practical penalty worse than any algorithmic one. Use a CA-signed certificate for any public site.
• How long should I make my self-signed certificate valid?
  For local development, 1–2 years is convenient. For internal tools, follow the same 398-day practice as public certificates — shorter validity periods reduce the damage if a private key is ever compromised.