A self-signed SSL certificate is one you create and sign yourself, rather than buying one from a certificate authority
When your browser visits a website, it checks whether the site's SSL certificate was signed by a trusted third party — a certificate authority like DigiCert, Let's Encrypt, or Sectigo. A self-signed certificate skips that middle step: you generate the certificate on your own server and sign it with your own private key, claiming to vouch for your own identity.
Your browser will still encrypt the connection to a site using a self-signed certificate. The encryption itself works perfectly. What does not work is trust: your browser has no way to verify that the certificate actually belongs to the site you think you are visiting, because nobody independent confirmed it. Most browsers will show a warning — "Your connection is not private" or "Certificate not trusted" — and require you to click through before loading the page.
Self-signed certificates are free to create and useful for testing, internal tools, and development environments where you control both the server and the client machines. They are not suitable for public websites where strangers need to trust that they are really talking to you.
Key Takeaways
- A self-signed certificate encrypts traffic but provides no proof of identity, because no trusted third party verified who you are.
- Browsers warn users that the connection is not private and may block access unless the user manually overrides the warning.
- Self-signed certificates are free and work well for internal tools, testing, and development servers where you control the machines accessing them.
- Public websites need certificates signed by a certificate authority so visitors can trust they are really connecting to the real site.
- Creating a self-signed certificate requires command-line tools like OpenSSL and takes only a few minutes.
How a self-signed certificate differs from a trusted one
When you buy an SSL certificate from a certificate authority, that authority verifies your identity — they check that you own the domain, that your business is real, or both, depending on the certificate type. They then sign your certificate with their own private key. Because browsers have the certificate authority's public key built in, they can verify that signature and confirm the certificate is legitimate.
A self-signed certificate has no such verification step. You create it, you sign it with your own key, and you install it on your server. When a browser visits, it sees the certificate is signed by someone called "your server" — which means nothing to the browser. The browser checks its list of trusted certificate authorities and finds no match, so it warns the user that the site may not be what it claims.
The warning is not a bug — it is a security feature. It prevents an attacker from setting up a fake version of your bank's website, signing it with their own certificate, and tricking you into entering your password. Without that warning, you would have no way to know the site was fake.
When self-signed certificates make sense
Self-signed certificates are practical for any situation where you control the machines on both ends of the connection. If you are running a development server on your laptop, or an internal tool on your company network, or a test environment that only your team accesses, a self-signed certificate lets you use HTTPS without paying for a certificate or waiting for a certificate authority to verify you.
You can also configure your own machines to trust your self-signed certificate, so you will not see the browser warning. On a development team, you might distribute the certificate to all developers' machines so everyone can work without warnings. On an internal network, your IT department might add the certificate to the company's trusted store so employees see no warning when they access internal tools.
Self-signed certificates are also useful for testing how your process behaves with HTTPS before you deploy it to production. You can verify that your code handles encrypted connections correctly without needing a real certificate.
Why self-signed certificates fail for public websites
The moment your website is public — when strangers visit it — a self-signed certificate becomes a liability. Visitors will see a browser warning and many will leave rather than click through. Search engines may penalize the site in rankings. Payment processors and other third-party services often refuse to work with sites using self-signed certificates.
More importantly, visitors have no reason to trust you. They cannot tell whether they are really connected to your site or to an attacker's fake version. The browser warning is meant to make them suspicious, and they should be. A legitimate business uses a certificate from a trusted authority precisely so customers know they are in the right place.
For public websites, you have better options. Let's Encrypt offers free certificates signed by a trusted authority, with automated renewal. Paid certificate authorities offer additional features like higher validation levels or coverage for multiple domains. Both are far better choices than self-signed for any site the public will visit.
How to create a self-signed certificate
Creating a self-signed certificate requires a command-line tool called OpenSSL, which is built into Linux and macOS and available free for Windows. The basic command generates a certificate valid for 365 days:
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365
OpenSSL will ask you for information like your country, state, organization name, and the domain name the certificate is for. You can leave most fields blank if this is just for testing. The command creates two files: key.pem (your private key, which you must keep secret) and cert.pem (the certificate itself, which you install on your server).
The exact steps to install the certificate depend on your server software — Apache, Nginx, Node.js, and others all have different configuration files. Your server's documentation will explain where to point it to the certificate and key files. Once installed, your server will use HTTPS with the self-signed certificate, and browsers will warn visitors that the connection is not trusted.
Self-signed certificates and internal networks
Many companies use self-signed certificates for internal tools — employee directories, time-tracking systems, internal wikis — because the tools are only accessed from inside the company network. The certificate encrypts the connection, which protects passwords and data from being read in transit, even on a trusted network.
To eliminate browser warnings on an internal network, the IT department can add the self-signed certificate to the company's trusted certificate store. On Windows, this means importing the certificate into the system's certificate manager. On macOS, it means adding it to the Keychain. On Linux, it means copying the certificate file to the system's certificate directory. Once added, employees will see no warning when they visit the internal site, because their machines now trust the certificate.
This approach works only if you control the machines. If employees use personal devices or remote access from outside the network, they will still see warnings unless you add the certificate to their personal machines too.
The security trade-offs of self-signed certificates
A self-signed certificate provides encryption but not authentication. An attacker cannot read the data flowing between your browser and the server — the encryption prevents that. But an attacker could set up their own server with their own self-signed certificate and trick you into connecting to it instead of the real server. You would see a warning, but if you are not paying attention, you might click through.
This is why self-signed certificates are safe for internal networks where you control the machines and can trust the URLs you visit. It is why they are unsafe for public websites where visitors have no way to verify they are at the right place. The encryption is real; the trust is not.
For any public-facing service, a certificate from a trusted authority is not optional — it is the only way to prove your identity to visitors. For internal tools and development, a self-signed certificate is a practical, free solution that provides encryption without the overhead of certificate authorities.
Frequently Asked Questions
Will a self-signed certificate encrypt my connection?
Yes. The encryption works the same way whether the certificate is self-signed or from a trusted authority. The difference is that visitors have no way to verify the certificate is really yours, so browsers warn them. The data is still encrypted in transit.
Can I use a self-signed certificate on a public website?
Technically yes, but you should not. Visitors will see a browser warning, many will leave, search engines may penalize your rankings, and third-party services often refuse to work with self-signed certificates. A free certificate from Let's Encrypt is a better choice for any public site.
How long does a self-signed certificate last?
You set the duration when you create it, typically 365 days or longer. Once it expires, browsers will show a warning that the certificate has expired, and you will need to create a new one. Unlike certificates from authorities, there is no automatic renewal — you have to manually recreate and reinstall it.
Can I add a self-signed certificate to my browser's trusted list?
Yes, but only on your own machine. You can import the certificate into your browser's certificate store so it no longer shows a warning. This works for testing and development. For a team or organization, you would need to import it on every machine that needs to access the site.
What is the difference between a self-signed certificate and a wildcard certificate?
A wildcard certificate covers multiple subdomains of a single domain (like *.example.com). A self-signed certificate is straightforward one you signed yourself rather than buying from an authority. You can create a self-signed wildcard certificate, but it still provides no proof of identity and will trigger browser warnings on public sites.