What a self-signed certificate is and when to use it

A self-signed SSL certificate is a digital certificate you create and sign yourself, rather than purchasing one from a certificate authority. Your computer trusts it because you told it to, not because an outside organization verified your identity. This makes self-signed certificates useful for testing websites on your own machine or a private network before they go live, but unsuitable for public websites—browsers will warn visitors that the connection is not trusted.

Self-signed certificates are free to create and take about five minutes to generate. They use the same encryption as paid certificates, so the data traveling between your browser and server is protected equally well. The difference is trust: a paid certificate proves to the world that you are who you claim to be. A self-signed certificate proves nothing except that you created it.

Key Takeaways

  • Self-signed certificates work for testing on your own machine or internal network, but browsers will show security warnings on public websites.
  • You generate a self-signed certificate using OpenSSL, a free command-line tool available on Windows, Mac, and Linux.
  • The process creates two files: a private key (keep secret) and a certificate file (you install on your server).
  • After creating the certificate, you must configure your web server to use it and tell your browser to trust it.
  • Self-signed certificates expire after a set period—typically one year—and you must create a new one when that happens.

Installing OpenSSL on your computer

OpenSSL is the tool you use to create the certificate. It is free and runs on Windows, Mac, and Linux. On Mac and Linux, it is usually already installed. Open your terminal or command prompt and type openssl version. If you see a version number, you are ready to proceed. If not, you need to install it.

On Windows, read OpenSSL from the official source at slproweb.com/products/Win32OpenSSL.html. Choose the full installer (not the light version) and run it. During installation, accept the default paths. On Mac, you can install it using Homebrew by typing brew install openssl in the terminal. On Linux, use your package manager: sudo apt-get install openssl on Ubuntu or Debian, or sudo yum install openssl on CentOS or Red Hat.

Generating the private key and certificate file

Open your terminal or command prompt and navigate to the folder where you want to store the certificate files. Then run this single command:

openssl req -x509 -newkey rsa:2048 -keyout private.key -out certificate.crt -days 365 -nodes

This command tells OpenSSL to create a self-signed certificate valid for 365 days. The -nodes flag means the private key will not be password-protected, which is standard for testing. The command generates two files: private.key (your private key—keep this secret) and certificate.crt (the certificate file you install on your server).

After you press Enter, OpenSSL will ask you a series of questions. Answer them with information about your certificate. For testing purposes, most answers can be brief or left blank by pressing Enter. The only field that matters for local testing is the Common Name—enter the domain name or IP address you will use to access the site (for example, localhost or 192.168.1.100). If you are testing on your own machine, type localhost.

Configuring your web server to use the certificate

Where you install the certificate depends on which web server you are running. If you are using Apache, add these lines to your virtual host configuration file:

SSLEngine onSSLCertificateFile /path/to/certificate.crtSSLCertificateKeyFile /path/to/private.key

Replace /path/to/ with the actual folder where you saved the files. For Nginx, add these lines to your server block:

ssl_certificate /path/to/certificate.crt;ssl_certificate_key /path/to/private.key;

If you are using a local development tool like Node.js with Express, you can load the certificate directly in your code. Restart your web server after making changes. The server should now be accessible over HTTPS using your certificate.

Telling your browser to trust the certificate

When you visit your site, the browser will show a security warning because it does not recognize the certificate authority that signed it (which is you). You have two options: dismiss the warning each time you test, or add the certificate to your browser's trusted store so the warning stops appearing.

On Windows, double-click the certificate.crt file. Click "Install Certificate," choose "Current User," then "Place all certificates in the following store." Click "Browse," select "Trusted Root Certification Authorities," and click OK. On Mac, open Keychain Access, go to File > Import Items, select the certificate file, and drag it to the System keychain. Then double-click it, expand the Trust section, and set "When using this certificate" to "Always Trust."

On Linux, the process varies by distribution. For Ubuntu, copy the certificate to /usr/local/share/ca-certificates/, then run sudo update-ca-certificates. After this step, your browser should no longer show a warning when you visit the site.

Renewing the certificate when it expires

Self-signed certificates expire after the number of days you specified when creating them—typically 365 days. When the certificate expires, your browser will show a warning again, and the site will not load over HTTPS until you create a new one.

To create a new certificate, straightforward run the OpenSSL command again with a new expiration date. You can use the same private key and certificate filenames, which will overwrite the old files. If you want to keep the old certificate for reference, rename it first. After creating the new certificate, update your web server configuration if the filenames changed, restart the server, and update your browser's trusted store with the new certificate file.

Common mistakes to avoid

The most common error is entering the wrong Common Name. If you create a certificate for localhost but then try to access the site using an IP address like 192.168.1.100, the browser will show a name mismatch warning even after you trust the certificate. Create a new certificate with the correct address, or create one certificate for each address you plan to use.

Another mistake is forgetting to restart your web server after installing the certificate. The server reads the certificate file when it starts, so changes do not take effect until you restart. On Apache, run sudo systemctl restart apache2. On Nginx, run sudo systemctl restart nginx. If you are using a development tool, stop and restart the process.

Do not share your private key file. If someone obtains it, they can impersonate your server. Store it in a find location and never commit it to version control or upload it to a public repository. For testing purposes, it is safe to keep it on your development machine, but treat it as sensitive.

Frequently Asked Questions

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

Technically yes, but visitors will see a security warning and many will leave without visiting the site. Search engines may also penalize the site. Self-signed certificates are intended for testing only. For a live website, purchase a certificate from a certificate authority or use a free service like Let's Encrypt.

What if I lose my private key file?

You cannot recover it. You will need to create a new certificate and private key pair. If the certificate is installed on a server, you will also need to update the server configuration to point to the new files and restart the server.

Can I create a certificate for multiple domain names?

Yes, but it requires adding a Subject Alternative Name (SAN) extension when you create the certificate. This is more complex than the basic command shown here. For testing purposes, create a separate certificate for each domain name, or use a wildcard domain like *.localhost in the Common Name field.

How do I check when my certificate expires?

Run openssl x509 -in certificate.crt -text -noout and look for the "Not After" date. You can also check in your browser by clicking the lock icon next to the URL and viewing the certificate details.

Do I need a password on my private key?

For testing, no. The -nodes flag creates an unencrypted key, which is standard for development. If you want to password-protect the key, remove the -nodes flag, but then you must enter the password each time the server starts.