What a self-signed certificate does and why you need one

A self-signed certificate is an SSL certificate you create yourself instead of buying one from a certificate authority. Your local server uses it the same way a purchased certificate works — to encrypt traffic between your computer and the server and to prove the server's identity to your browser. The difference is that only you vouch for it, so your browser will show a warning the first time you visit.

You need one when you are testing a website or process on your own machine before it goes live, or when you are running internal tools that only you or your team will access. A self-signed certificate costs nothing and takes five minutes to create. The warning your browser shows is normal and expected — it is not a sign something is wrong.

If you are building something that strangers will visit on the public internet, you will eventually need a certificate from a real certificate authority. But for local work, self-signed is the standard path.

Key Takeaways

  • You create a self-signed certificate using OpenSSL, a free tool that comes built into Mac and Linux and can be installed on Windows.
  • The process takes one command line and produces two files: a certificate file and a private key file that your server reads.
  • Your browser will warn you the certificate is not trusted the first time you visit, which is normal — you can tell it to trust the certificate and continue.
  • Self-signed certificates work only for local testing; they do not work for websites the public visits.
  • You can create a new certificate whenever you need one, and each one lasts for a set number of days you choose when you create it.

Creating a certificate on Mac or Linux

Open your terminal and run this command, all on one line:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

OpenSSL will ask you a series of questions: country, state, city, organization, and common name. For local testing, you can leave most of these blank and just press Enter. For the common name, type localhost if you are testing on your own machine, or the actual hostname if others on your network will reach it (for example, myserver.local).

When the command finishes, you will have two files in that folder: cert.pem (your certificate) and key.pem (your private key). Your web server needs both of these files to run HTTPS. Do not share the key.pem file with anyone — it is what proves you created the certificate.

Creating a certificate on Windows

Windows does not come with OpenSSL, so you need to install it first. read OpenSSL from slproweb.com/products/Win32OpenSSL.html — choose the full installer, not the light version. Run the installer and accept the defaults.

Once installed, open Command Prompt (search for "cmd" in the Start menu) and navigate to the folder where you want to store your certificate files. Then run the same command as Mac and Linux:

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes

Answer the questions the same way: press Enter for most fields, and type localhost for the common name. You will end up with the same two files, cert.pem and key.pem.

Telling your web server where the certificate is

Your web server software needs to know where to find both files. The exact steps depend on which server you are running — Node.js, Python, Apache, Nginx, or something else — but the pattern is the same: you point it to the cert.pem file and the key.pem file.

If you are using Node.js with Express, for example, you would load both files and pass them to the https module. If you are using Python's built-in server, you would start it with a flag pointing to the certificate. Check your server's documentation for the exact syntax, but search for "HTTPS" or "SSL certificate" and you will find the section that shows where to point it.

Once your server is running with the certificate, visit it in your browser using https://localhost (or whatever hostname you used). Your browser will show a warning that the certificate is not trusted. This is expected. You can click through the warning — the connection is still encrypted, and the certificate is still doing its job.

Making your browser stop warning you

If you are tired of seeing the warning every time you test, you can tell your browser to trust the certificate. On Mac, open Keychain Access, drag the cert.pem file into it, find the certificate in the list, double-click it, and change "When using this certificate" to "Always Trust". On Windows, double-click the cert.pem file, click "Install Certificate", choose "Current User", and then "Place all certificates in the following store" and select "Trusted Root Certification Authorities".

On Linux, the process varies by distribution and browser. Firefox has its own certificate store separate from the system, so you would add it through Firefox's settings. Chrome uses the system store, so you would use your distribution's certificate management tool.

Once the certificate is trusted, your browser will stop warning you and the lock icon will appear normally. This only affects your own machine — other people visiting your server will still see the warning unless they also trust the certificate.

When you need a new certificate

Self-signed certificates expire. The command above creates one that lasts 365 days — you can change that number to make it last longer or shorter. When your certificate expires, your browser will warn you that it is out of date, and your server will stop serving HTTPS traffic.

When that happens, straightforward run the command again to create a new certificate. You can overwrite the old cert.pem and key.pem files, or create new ones with different names. If you are testing regularly, you might create a certificate that lasts 3650 days (ten years) so you do not have to think about it.

If you are using a certificate management tool like Let's Encrypt for local testing (which is possible but uncommon), it will handle renewal automatically. For self-signed certificates, renewal is just running the command again.

Frequently Asked Questions

Why does my browser say the certificate is not trusted?

Because you created it yourself, not a certificate authority that your browser knows about. The connection is still encrypted. Your browser is warning you that it cannot verify you are who you say you are — but since you are testing on your own machine, that is fine. This warning only appears for self-signed certificates on local servers.

Can I use a self-signed certificate on the public internet?

No. Visitors will see a scary warning and most will leave. For anything public, you need a certificate from a real certificate authority like Let's Encrypt (free), Sectigo, or DigiCert. Self-signed certificates are only for local testing and internal tools.

What if I lose the key.pem file?

You cannot recover it. You will need to create a new certificate by running the command again. This is why the key file is called a "private key" — it is unique to that certificate and cannot be recreated. Keep both files in a safe place while you are testing.

Do I need to create a new certificate for each project?

No. One certificate can work for multiple local servers as long as they all use localhost or the same hostname. If you are testing different hostnames on the same machine, you can create one certificate with multiple names in it, though that is more complex. For most local work, one certificate per machine is enough.

Can someone else use my certificate?

They can use the cert.pem file, but without the key.pem file they cannot run a server with it. The key is what matters — keep it private. If someone gets both files, they could impersonate your server on their own machine, but they could not use it on the public internet because browsers would still reject it.