A self-signed certificate is a digital credential you create yourself instead of buying from a certificate authority

A self-signed certificate is an SSL/TLS certificate that you generate and sign with your own private key, rather than having a trusted third party (called a certificate authority or CA) sign it for you. When you create one, you are essentially vouching for your own identity — you are both the issuer and the subject of the certificate.

The certificate itself contains the same technical information as one from a paid CA: your server's public key, your domain name, an expiration date, and a digital signature. The difference is trust. When a browser or process encounters your self-signed certificate, it has no way to verify that you are who you claim to be, because no recognized authority has checked your identity and signed off on it.

Self-signed certificates are free to create and work when ready on your own systems. They are commonly used for internal testing, development environments, and private servers where you control both the server and the client software. They are not suitable for public-facing websites because visitors will see security warnings.

Key Takeaways

  • You create and sign a self-signed certificate yourself using command-line tools like OpenSSL, so no external authority is involved.
  • Browsers and devices will display a security warning when they encounter a self-signed certificate because they cannot verify the issuer's identity.
  • Self-signed certificates are appropriate for internal networks, development servers, and testing environments where you control the client devices.
  • The certificate provides the same encryption as one from a paid CA, but offers no proof of identity to outside users.
  • You can set the expiration date yourself when you create the certificate, and you can renew it whenever you choose.

How self-signed certificates differ from CA-signed certificates

A certificate authority is an organization that has been trusted by operating systems and browsers to verify identities and issue certificates. When you buy a certificate from a CA like DigiCert, Sectigo, or Let's Encrypt, the CA checks that you own the domain, signs the certificate with their own private key, and adds it to a chain of trust. When a browser sees that signature, it can verify that a trusted authority has confirmed your identity.

A self-signed certificate has no such chain. You sign it with your own key, so there is no independent verification of who you are. A browser cannot confirm that the certificate actually belongs to the domain it claims to represent. This is why browsers show warnings like "Your connection is not private" or "Certificate not trusted" when encountering a self-signed certificate on a public website.

The encryption itself works identically — data sent over HTTPS with a self-signed certificate is just as encrypted as data sent with a CA-signed one. The difference is authentication, not encryption. You know your data is scrambled, but visitors have no way to know they are actually talking to your server and not an imposter.

When self-signed certificates make sense

Self-signed certificates are the right choice for development and testing. If you are building a web process on your own computer or a private test server, you need HTTPS to test features that require it — like service workers, certain APIs, or cookie security settings. A self-signed certificate lets you do that without cost or delay. You straightforward add an exception in your browser or configure your test client to trust the certificate.

Internal corporate networks often use self-signed certificates for servers that only employees can access. If your company runs a file server, intranet, or internal tool on HTTPS, and all the client computers are managed by your IT department, you can install the certificate on every device once and avoid security warnings. The certificate proves encryption, and your network controls may support you are talking to the right server.

Self-signed certificates are also used for Internet of Things (IoT) devices, embedded systems, and other hardware that needs HTTPS but will never be accessed by the general public. A smart home hub, industrial control system, or network printer can use a self-signed certificate to encrypt traffic between itself and the devices that manage it.

How to create a self-signed certificate

The most common tool for creating self-signed certificates is OpenSSL, a free command-line utility available on Windows, macOS, and Linux. A basic self-signed certificate is created with a single command that generates both a private key and the certificate in one step.

The command typically looks like this: you specify the algorithm (usually RSA with a 2048-bit or 4096-bit key), the number of days the certificate should be valid (commonly 365 or 3650), the output file names, and information about your organization and domain. You will be prompted to enter details like your country, state, city, organization name, and the domain name (called the Common Name).

Once the command completes, you have two files: a private key file (which you keep secret and never share) and a certificate file (which you install on your server). Different server software — Apache, Nginx, Node.js, IIS — has different procedures for installing the certificate, but the creation step is the same across all of them.

If you are not comfortable with command-line tools, some server control panels and web hosting platforms include graphical interfaces for generating self-signed certificates. The process is the same, just presented through a form instead of a terminal.

Security warnings and browser behavior

When a visitor arrives at a website using a self-signed certificate, their browser checks the certificate's signature against its list of trusted CAs. Since the certificate is signed by you and not by a recognized authority, the browser cannot verify it and displays a warning. The exact message varies by browser — Chrome says "Your connection is not private," Firefox says "Warning: Potential Security Risk Ahead," and Safari shows "This certificate is not trusted."

In most browsers, users can click through the warning and proceed to the site anyway, though they have to take an extra step to do so. This is by design: the warning is meant to stop accidental visits to imposter sites, but it does not completely block access. However, many users will turn back when they see the warning, which is why self-signed certificates are unsuitable for public websites.

Some applications and tools allow you to manually add a self-signed certificate to a trusted store, which tells that specific process to accept the certificate without warnings. This is common in development environments and internal networks. For example, you can import a self-signed certificate into your operating system's certificate store, and then browsers and other applications on that computer will trust it.

Limitations and when not to use self-signed certificates

Never use a self-signed certificate on a public-facing website. The security warnings will drive away visitors, damage your credibility, and may harm your search engine ranking. If your site is open to the internet, you need a certificate from a recognized CA.

Self-signed certificates also cannot be revoked. If your private key is compromised, you cannot contact a CA to revoke the certificate — you can only stop using it. This is another reason they are unsuitable for production systems that handle sensitive data from the public.

Additionally, self-signed certificates do not provide any proof of your identity to third parties. If you need to prove to a business partner, customer, or regulatory body that your server is legitimate, a CA-signed certificate is required. The CA's signature is that proof.

Self-signed certificates versus free CA-signed alternatives

Let's Encrypt is a free, automated CA that issues certificates valid for 90 days at a time. If you have a public website or any server accessible from the internet, Let's Encrypt is a better choice than a self-signed certificate. It takes only a few minutes to set up, requires no payment, and your visitors will see no warnings.

The main advantage of a self-signed certificate over Let's Encrypt is that you do not need to own a domain name or have your server accessible from the internet. If you are testing on a local network or using an IP address instead of a domain, Let's Encrypt cannot issue a certificate for you. In that case, a self-signed certificate is the only option.

For any production use — any server that real users will visit — Let's Encrypt or another CA is the right choice. The cost is zero, and the setup is straightforward. Self-signed certificates should be reserved for development, testing, and internal networks only.

Frequently Asked Questions

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

Technically yes, but you should not. Browsers will show security warnings that will scare away visitors and damage your credibility. If your site is public, use a certificate from a recognized CA like Let's Encrypt (free), Sectigo, or DigiCert.

Is the encryption weaker with a self-signed certificate?

No. The encryption strength depends on the key size and algorithm, not on who signed the certificate. A self-signed certificate with a 2048-bit RSA key encrypts data just as securely as a CA-signed certificate with the same key size. The difference is authentication, not encryption.

How long does a self-signed certificate last?

You choose the expiration date when you create the certificate. Most are set to expire in one year or ten years. When it expires, you must create a new one — there is no automatic renewal process like there is with Let's Encrypt.

Can I use a self-signed certificate for a subdomain or wildcard?

Yes. When you create the certificate, you specify the domain name (Common Name) in the certificate details. You can use any domain or subdomain you want, including wildcard certificates like *.example.com. The certificate will work the same way — browsers will still show warnings because it is self-signed, not because of the domain.

What happens if my private key is stolen?

An attacker could use your private key to create a fake certificate that impersonates your server. Unlike CA-signed certificates, you cannot revoke a self-signed certificate. Your only option is to stop using it, create a new one, and install the new certificate on your server. This is one reason self-signed certificates are not suitable for production systems handling sensitive data.