SSL & HTTPS Guides

Self-Signed Certificates: When They Are and Are Not Appropriate

Learn what self-signed certificates are, why browsers do not trust them by default, and when to use a publicly trusted SSL certificate instead.

By CheckDomainHealth Editorial Team Reviewed by Dionis Ceban Updated Jun 28, 2026 7 min read Beginner

Introduction

A self-signed certificate is an SSL/TLS certificate that is signed by its own creator instead of a publicly trusted certificate authority. It can still enable encryption, but browsers and operating systems usually do not trust it by default.

Self-signed certificates can be useful for local development, testing, internal systems and private infrastructure where trust is controlled. They are not appropriate for public websites, customer portals, payment pages or any service where visitors expect normal browser trust.

Quick answer

Quick answer

A self-signed certificate can encrypt traffic, but it is not trusted by public browsers unless the user or organization manually trusts it. Use self-signed certificates only for controlled internal or testing environments. Public websites should use certificates from trusted certificate authorities.

Self-signed certificates

A self-signed certificate is a certificate signed by the same entity that created it. It is not issued by a public certificate authority such as Let’s Encrypt, DigiCert, Sectigo, GlobalSign or Google Trust Services.

Because public browsers do not automatically trust the signer, visitors usually see a warning such as:

  • Your connection is not private
  • This certificate is not trusted
  • NET::ERR_CERT_AUTHORITY_INVALID
  • Security risk ahead

The problem is not always encryption. The problem is trust.

Self-signed vs trusted

Self-signed certificate

  • Issued by: Your own system or organization.
  • Trusted by browsers: No, not by default.
  • Best for: Local testing, private labs, internal tools and controlled environments.
  • Main risk: Users see warnings unless trust is manually configured.

Publicly trusted certificate

  • Issued by: A trusted certificate authority.
  • Trusted by browsers: Yes, if valid and correctly installed.
  • Best for: Public websites, customer portals, APIs and production services.
  • Main risk: Must be renewed and installed correctly.

Acceptable use cases

Local development

Useful for testing HTTPS on a developer machine.

Private lab

Useful for isolated test environments.

Internal systems

Acceptable when all devices are controlled and trust is managed centrally.

Temporary testing

Useful for short-term testing before a real certificate is issued.

Private services

May be acceptable for VPN-only or internal-only tools.

Even internally, self-signed certificates should be documented and managed properly.

When not to use them

Public websites

Visitors will see browser warnings and may leave.

E-commerce

Payment and checkout pages need trusted HTTPS.

Customer portals

Users should not be trained to bypass certificate warnings.

Production APIs

Clients may reject untrusted certificates.

Login pages

Untrusted certificates reduce confidence and create security risk.

Email or hosting control panels

Public-facing admin tools should use trusted certificates.

Never ask normal users or customers to ignore certificate warnings on a public service.

Browser warnings

Browsers warn users because they cannot verify who created the certificate. With a publicly trusted certificate, the browser can follow a trust chain back to a trusted root certificate authority. With a self-signed certificate, that trust chain is missing.

A self-signed certificate may still encrypt traffic, but encryption without trusted identity is not enough for public websites.

Why this matters

Why this matters

This matters because certificate warnings damage trust immediately. A visitor may assume the website is fake, unsafe, abandoned or compromised. For public websites, a self-signed certificate is usually worse than no professional SSL setup because it teaches users to ignore security warnings.

For internal systems, self-signed certificates can be acceptable only when the organization controls the devices and trust settings.

How to check trust

Use SSL Checker to inspect the issuer, trust status and certificate chain.

When checking a self-signed certificate, review

These six checks help decide whether the certificate is appropriate.

Issuer

Check whether the certificate is issued by itself or an unknown authority.

Trust status

Confirm whether browsers trust the certificate.

Certificate chain

Check whether the certificate links to a trusted root.

Hostname match

Confirm the certificate still covers the correct hostname.

Expiry date

Check whether the certificate is expired.

Environment

Decide whether the service is public, internal, testing or local.

Check certificate trust

Use SSL Checker to verify whether your certificate is trusted by public browsers.

Run SSL Check →

Common problems

Public website uses self-signed certificate

High

Visitors will see browser warnings because the certificate is not publicly trusted.

Next step: Install a certificate from a trusted certificate authority.

Users are told to ignore warnings

High

Training users to bypass certificate warnings creates bad security habits.

Next step: Fix certificate trust instead of asking users to continue.

Internal certificate not deployed to devices

Medium

The organization uses an internal CA, but devices do not trust it.

Next step: Deploy the internal root CA through managed device policies.

Self-signed certificate expired

Medium

Even self-signed certificates have expiry dates.

Next step: Renew or replace the certificate and update the service.

Hostname mismatch

High

The certificate does not cover the hostname being used.

Next step: Create a certificate for the correct hostname or use a trusted public certificate.

Production API rejects certificate

High

Clients may refuse connections to untrusted certificates.

Next step: Use a publicly trusted certificate or configure private trust correctly.

Self-signed certificate used as a permanent shortcut

Medium

Temporary test certificates often remain in production by mistake.

Next step: Replace with a managed certificate process and renewal plan.

How to replace them

  1. Step 1: Identify where the certificate is used

    Check whether it is on a website, control panel, API, mail service, internal app, CDN or proxy.

  2. Step 2: Decide if the service is public or private

    Public services should use publicly trusted certificates. Private services may use internal trust if managed properly.

  3. Step 3: Choose a trusted certificate option

    Use Let’s Encrypt, hosting AutoSSL, CDN SSL, commercial CA or internal CA depending on the use case.

  4. Step 4: Issue the certificate for correct hostnames

    Include root domain, www, subdomains or internal hostnames as needed.

  5. Step 5: Install the certificate and full chain

    Update the web server, proxy, load balancer, CDN or service configuration.

  6. Step 6: Reload and test

    Reload the service and verify trust externally with SSL Checker.

  7. Step 7: Set renewal process

    Use automatic renewal where possible.

Internal CA

For organizations, an internal certificate authority is often better than random self-signed certificates.

Internal CA

Centrally managed. Root CA can be deployed to company devices. Certificates can be issued consistently. Better for internal services.

Random self-signed certificate

Trusted nowhere by default. Harder to manage. Easy to forget. Creates repeated warnings.

Internal CA setups still require careful management and should not be used for public websites unless the CA is publicly trusted.

Better alternatives

Let’s Encrypt

Good free option for public websites.

Hosting AutoSSL

Good for shared hosting and cPanel/Plesk environments.

CDN SSL

Useful when HTTPS terminates at Cloudflare, CDN or proxy.

Commercial CA

Useful for business requirements, organization validation or special certificate needs.

Internal CA

Useful for managed private infrastructure.

The best alternative depends on whether the service is public or private.

Common browser error 
NET::ERR_CERT_AUTHORITY_INVALID
Check certificate issuer 
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer -subject
Check certificate chain 
openssl s_client -connect example.com:443 -servername example.com -showcerts

Public website recommendation

Use a trusted CA certificate.

Internal-only recommendation

Use internal CA trust management instead of unmanaged self-signed certificates.

These examples are illustrative. Replace example.com with your real domain or internal hostname.

Frequently asked questions

Is a self-signed certificate encrypted?

Yes, it can encrypt traffic, but browsers do not trust it by default.

Why do browsers warn about self-signed certificates?

Because the certificate is not signed by a trusted certificate authority.

Can I use a self-signed certificate on a public website?

You should not. Public websites should use publicly trusted certificates.

When is self-signed acceptable?

It may be acceptable for local development, testing labs or controlled internal systems.

Is an internal CA better than self-signed certificates?

Usually yes for organizations, because trust can be managed centrally.

Can users manually trust a self-signed certificate?

Yes, but that is not appropriate for normal public visitors or customers.

What should I use instead?

Use Let’s Encrypt, hosting AutoSSL, CDN SSL, a commercial CA or a managed internal CA depending on the use case.

Use these free tools to verify your configuration after applying changes.

SSL Checker CAA Record Checker DNS Lookup Website Status Checker Domain Health Checker
Understanding Certificate Authorities and Trust Chains 8 min read How to Check Your SSL Certificate 8 min read Installing a Let's Encrypt Certificate on Your Hosting 9 min read What Is SSL/TLS and How Does It Protect Your Site 8 min read Troubleshooting SSL Handshake Failures 9 min read
Browse all SSL & HTTPS guides →

Need help applying this fix?

Send us your domain, report link or issue details. CheckDomainHealth will review the request and route it to the right technical team if hands-on support is needed.

Get Help Run Domain Health Check

Was this guide helpful?

Your feedback helps us improve our guides for everyone.