Self-signed certificates work on your own network without a certificate authority

A self-signed certificate is one you create and sign yourself instead of buying one from a certificate authority. Your browser will warn you that it does not recognize the issuer — that warning is normal and expected — but the certificate will encrypt traffic between your computer and your local server just as well as a paid one does. For development, testing, or internal networks where you control all the machines connecting to the server, a self-signed certificate is the standard choice.

You do not need special software or a paid service. The tools are free and built into Windows, macOS, and Linux. The process takes minutes once you know which command to run and what information to enter.

Key Takeaways

  • Self-signed certificates encrypt local traffic without paying a certificate authority, but browsers will show a security warning because they do not recognize your signature.
  • On Windows, you can use PowerShell or the Certificate Manager; on macOS and Linux, OpenSSL is the standard tool and takes one command line.
  • You need the certificate file and the private key file both installed on your server before it will work.
  • Your server software (Apache, Nginx, Node.js, IIS) needs to be told where the certificate and key files are located.
  • The certificate is valid only for the exact domain name or IP address you enter when you create it, so plan ahead if you need multiple names.

Creating a self-signed certificate on Windows with PowerShell

Windows includes a built-in command called New-SelfSignedCertificate in PowerShell. Open PowerShell as Administrator and run this command, replacing localhost with your actual server name or IP address:

New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(1)

This creates a certificate valid for one year. PowerShell will return a thumbprint — a long string of letters and numbers. Write it down or copy it. The certificate is now stored in your Windows certificate store, but you need to export it as files before your server can use it. Right-click the certificate in Certificate Manager (search "Manage computer certificates"), select All Tasks, then Export. Choose to export the private key as a PFX file. Your server software will need the path to this PFX file.

Creating a self-signed certificate on macOS and Linux with OpenSSL

OpenSSL is installed by default on both systems. Open Terminal and run this single command, replacing localhost with your server name or IP:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=localhost"

This creates two files in your current directory: cert.pem (the certificate) and key.pem (the private key). The certificate is valid for 365 days. You can change the number to make it valid longer — use 3650 for ten years. The -nodes flag means the private key is not password-protected, which is standard for local development.

If you need the certificate to work for multiple names — for example, both localhost and 192.168.1.100 — you will need to create a configuration file first. This is more complex, so start with a single name and add multiple names only if your first certificate does not work for your use case.

Installing the certificate on your server

Where you install the certificate depends on your server software. For Node.js, pass the file paths to your HTTPS server:

const https = require('https'); const fs = require('fs'); const options = { key: fs.readFileSync('key.pem'), cert: fs.readFileSync('cert.pem') }; https.createServer(options, app).listen(443);

For Apache, edit your virtual host configuration and point to the files:

SSLCertificateFile /path/to/cert.pem SSLCertificateKeyFile /path/to/key.pem

For Nginx, do the same in your server block:

ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem;

For IIS on Windows, import the PFX file through the IIS Manager console under Server Certificates, then bind it to your site. Consult your server software's documentation if you use something else — the principle is the same: tell the server where the certificate and key files are.

Trusting the certificate on your own machine

Your browser will show a warning because it does not recognize your signature. You can dismiss the warning each time, or you can add the certificate to your system's trusted store so the warning goes away. This only works on the machine where you add it — other machines will still see the warning.

On Windows, open Certificate Manager, go to Trusted Root Certification Authorities, right-click, and import your cert.pem file. On macOS, open Keychain Access, drag cert.pem into it, then double-click the certificate and set it to Always Trust. On Linux, the process varies by distribution, but usually involves copying the certificate to /usr/local/share/ca-certificates/ and running sudo update-ca-certificates.

Renewing your certificate when it expires

Self-signed certificates expire on the date you set when you created them. When that date arrives, your server will still run, but browsers will show an expiration warning. You cannot renew a self-signed certificate — you must create a new one using the same commands above. Keep a note of the command you used so you can run it again with the same domain name and settings.

If you are using the certificate for production or for a service other people rely on, consider moving to a paid certificate from a certificate authority before expiration. For local development and testing, creating a new self-signed certificate takes the same few minutes it took the first time.

Troubleshooting common problems

If your server starts but browsers still show an error, check that you pointed the server to both the certificate file and the key file — many people forget one or the other. If the file paths are relative, make sure they are relative to where your server is running from, not where you created the files. If you created the certificate for localhost but your server is running on an IP address like 192.168.1.100, the certificate will not match and the browser will warn you. Create a new certificate with the correct name or IP address.

If you see a "permission denied" error when your server tries to read the files, check that the server process has read permission on both files. On Linux and macOS, you may need to run chmod 644 cert.pem key.pem to make them readable. If you are on Windows and the server is running as a service, the service account may not have permission to read the files — move them to a directory the service can access, or grant the service account explicit read permission.

Frequently Asked Questions

Can I use a self-signed certificate in production?

Technically yes, but you should not. Browsers will show a warning to every visitor, which damages trust and looks unprofessional. Self-signed certificates are for development, testing, and internal networks where you control the machines connecting to the server. For anything public-facing, use a paid certificate from a certificate authority.

What is the difference between a certificate and a private key?

The certificate is the public part — it tells browsers who you are and contains your public key. The private key is secret and stays on your server — it proves you are who you claim to be. Both files are needed for HTTPS to work. Never share your private key file.

How long should I make my self-signed certificate valid for?

For development, one year is standard. For internal tools you do not want to think about, ten years (3650 days) is reasonable. The longer the certificate is valid, the longer you can go without creating a new one, but there is no security downside to either choice on a local network.

Can I use a self-signed certificate for multiple domain names?

Yes, but you need to create it with a configuration file that lists all the names. This is more complex than the single-name command shown above. Start with one name, and only add multiple names if your first certificate does not work for your use case — most local servers need only one.

Do I need to restart my server after installing the certificate?

Yes. After you tell your server software where the certificate and key files are, restart the server process so it reads the new configuration. straightforward reloading the configuration file is not always enough — a full restart is safest.