A self-signed certificate is a TLS certificate you sign yourself instead of obtaining from a trusted Certificate Authority. It still encrypts traffic, but because no recognised CA vouches for it, browsers show a prominent security warning. It is fine for local testing but never for public sites.
Self-signed certificates provide encryption but not verified identity, so browsers cannot trust them automatically. They are useful for internal tools and development, but on a public website they trigger scary warnings that destroy visitor trust.
Check your website
See how your site handles self-signed certificates: when they help and when they hurt — free, no account needed.
For business owners
Serving a public site with a self-signed certificate is one of the fastest ways to lose a customer: the browser interrupts them with a full-page "Your connection is not private" warning. For anything the public touches, use a free trusted certificate instead — the cost saving of self-signing is never worth the lost trust.
How it works (technical)
A self-signed certificate is signed by its own private key rather than by a CA, so it does not chain to any root in the browser's trust store. TLS still negotiates and encrypts, but validation fails, producing errors like ERR_CERT_AUTHORITY_INVALID. They are appropriate for localhost development, internal services with a private CA distributed to clients, or automated testing. For production, a free automated CA (ACME/Let's Encrypt) issues a trusted certificate in seconds, removing any reason to self-sign publicly.
Real-world example
A developer shipped a staging configuration with a self-signed certificate to production. Visitors were met with a browser interstitial warning them the site might be dangerous; traffic and conversions cratered until a trusted certificate was installed. The fix took minutes with an automated CA.
Why it matters
A self-signed certificate on a public site erodes trust and is treated as effectively insecure by browsers. Scanners flag untrusted or self-signed certificates on public hostnames.
How to fix it
For any public site, replace self-signed certificates with a trusted CA certificate.
Use an automated CA (ACME/Let's Encrypt) for free, instant, auto-renewing certificates.
Reserve self-signed certificates for localhost and internal testing only.
For internal services, distribute your own private root CA to trusted clients instead of ignoring warnings.
Verify in a browser that the padlock appears with no warning.
Best practices
Never use self-signed certificates on public-facing production sites.
Automate trusted certificate issuance and renewal.
Use a managed internal CA for internal systems rather than per-host self-signed certs.
Common mistakes
Deploying a self-signed certificate to production and training users to click through warnings.
Confusing "encrypted" with "trusted" — self-signed is encrypted but not trusted.
Ignoring certificate warnings, which conditions users to accept real attacks.
Frequently asked questions
Is a self-signed certificate encrypted?
Yes, the connection is encrypted. The problem is trust: no recognised authority vouches for it, so browsers cannot verify who is on the other end and warn the user.
When is self-signing acceptable?
For local development, automated testing, or internal systems where you control the clients and can distribute your own trusted root. Never for the public web.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free