A self-signed certificate is a digital credential that a person or organization creates and signs themselves, rather than having a trusted third party (called a certificate authority) sign it for them.
When you visit a website, your browser checks whether the site's certificate was signed by a recognized authority. A self-signed certificate fails that check — your browser doesn't recognize who signed it, so it can't verify the certificate is legitimate. This is why you see a warning like "Your connection is not private" or "Certificate not trusted" when you land on a site using a self-signed certificate.
Self-signed certificates still encrypt the connection between you and the server. The encryption itself works fine. The problem is authentication — you have no way to confirm you're actually talking to the server you think you are. Someone could intercept your connection and present their own self-signed certificate, and your browser would show the same warning either way.
Key Takeaways
- A self-signed certificate encrypts your connection but doesn't prove who owns the server, because no trusted authority verified the owner's identity.
- Your browser will warn you that the connection is not private or trusted when you encounter a self-signed certificate.
- Self-signed certificates are common on internal company networks, development servers, and personal projects where the owner controls both ends of the connection.
- Proceeding past the warning on a public website you don't recognize is risky, because you cannot verify the server's identity.
- A certificate authority charges money to verify your identity and sign your certificate, which is why legitimate public websites use them.
Why organizations create self-signed certificates
A self-signed certificate costs nothing and takes minutes to create. A certificate from a recognized authority (called a certificate authority or CA) requires you to prove who you are, and the CA charges a fee — anywhere from $50 to several hundred dollars per year depending on the type of certificate and the CA you choose.
For internal use, self-signed certificates make sense. If you're running a server on your company's private network that only your employees access, you control both the server and the computers connecting to it. You can tell your employees "this certificate is legitimate" and they can verify it directly with you. The encryption protects the data in transit; the lack of third-party verification doesn't matter because you're not trying to prove your identity to strangers.
Developers also use self-signed certificates when testing websites locally before they go live. A developer building a site on their own computer can create a self-signed certificate in seconds, test the encrypted connection, and then replace it with a proper certificate before the site goes public.
The warning you see and what it means
When your browser encounters a self-signed certificate on a public website, it shows a warning because it cannot verify the certificate came from a legitimate source. The exact wording varies by browser — Chrome says "Your connection is not private," Firefox says "Warning: Potential Security Risk Ahead," Safari says "This Connection is Not Private."
The warning is telling you that the encryption is in place, but you have no proof you're talking to the real server. An attacker could set up their own server with their own self-signed certificate, and you would see an identical warning. You have no way to tell the difference without additional information (like calling the organization directly to ask if they use self-signed certificates).
Some browsers let you click through the warning and proceed anyway. This is safe only if you have a specific reason to trust this particular server — for example, you're connecting to a development server your company runs, or you've manually verified the certificate's fingerprint with the server's owner.
Self-signed certificates versus trusted certificates
A trusted certificate (one signed by a recognized certificate authority) includes a chain of verification. The CA has checked that the person requesting the certificate actually owns the domain or organization name on the certificate. When your browser sees a trusted certificate, it can verify that chain and confirm the server is who it claims to be.
With a self-signed certificate, there is no chain to verify. The certificate says "I am example.com" but there's no independent verification that the person who created the certificate actually owns example.com. Anyone can create a self-signed certificate that claims to be any domain.
This is why legitimate public websites use trusted certificates. They want visitors to know they're the real organization, not an imposter. The certificate authority's verification and signature is what makes that possible.
When you should and shouldn't proceed past the warning
If you're accessing an internal company tool, development server, or personal project you know about, proceeding past the warning is usually fine. You already have a reason to trust the server — your employer told you to use it, or you set it up yourself.
If you're on a public website you don't recognize, or a site that claims to be a bank, email provider, or payment processor, do not proceed. There's no way to verify the server is legitimate. Close the tab and contact the organization through a phone number or website address you find independently to ask whether they use self-signed certificates. (They won't — legitimate financial and email services always use trusted certificates.)
If you're unsure, the safest choice is to leave. A self-signed certificate warning means you cannot verify the server's identity. That's a real limitation, not a false alarm.
How self-signed certificates are created
Creating a self-signed certificate requires command-line tools like OpenSSL (available on Mac, Linux, and Windows). The process takes a few minutes and involves generating a private key and a certificate, then signing the certificate with that key.
You don't need to understand the technical details to recognize one. What matters is knowing that anyone can create one in minutes, which is why a self-signed certificate proves nothing about who owns the server. A trusted certificate, by contrast, proves the certificate authority checked the owner's identity before signing it.
Free alternatives to self-signed certificates
If you're running a public website and want encryption without paying for a certificate, Let's Encrypt offers free trusted certificates. Let's Encrypt is a nonprofit certificate authority that automates the verification process. You prove you own a domain by placing a file on your server, and Let's Encrypt signs your certificate automatically. The certificate is trusted by all major browsers.
Let's Encrypt certificates are valid for 90 days and renew automatically. Most web hosting providers and site builders (like WordPress.com, Squarespace, and Wix) include Let's Encrypt certificates for free or as part of their service. If you're building a website, using a provider that includes a trusted certificate is simpler than managing a self-signed one.
Frequently Asked Questions
Is a self-signed certificate less secure than no certificate at all?
No. A self-signed certificate still encrypts your connection, so someone eavesdropping on your network cannot read the data you send. The difference is that you cannot verify the server's identity. With no certificate, the connection isn't encrypted at all. Self-signed is more secure for privacy, but it doesn't prove who you're talking to.
Can I make my browser stop warning me about a self-signed certificate?
Yes, but only for internal servers you control. On Windows, Mac, and Linux, you can add the certificate to your system's trusted store, and your browser will stop showing the warning for that specific certificate. This is common in corporate environments where IT departments distribute the company's self-signed certificates to all employee computers. Do not do this for public websites.
If a website uses a self-signed certificate, does that mean it's a scam?
Not necessarily. It could be a legitimate internal tool, development server, or personal project. But if it's a public website claiming to be a bank, store, or email service, the self-signed certificate is a red flag. Real financial and commercial services always use trusted certificates because they need to prove their identity to customers.
Why doesn't my company just use Let's Encrypt instead of self-signed certificates?
Let's Encrypt requires a public domain name and internet access to verify ownership. Internal company servers often don't have either — they're only accessible from inside the company network and don't have a public domain. For those servers, self-signed certificates are the practical choice.