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

A self-signed SSL certificate is a digital file you create yourself that encrypts traffic between a web browser and your server. Unlike certificates issued by a trusted authority, your server signs its own certificate — which means browsers will show a security warning when visitors arrive, because they cannot verify you are who you claim to be. Self-signed certificates work for testing, internal tools, development environments, and private servers where visitors expect the warning and trust your server anyway.

Do not use a self-signed certificate on a public website where strangers need to trust you. Visitors will see "Your connection is not private" and most will leave. For public sites, you need a certificate from a trusted certificate authority — often free through Let's Encrypt if your server runs on the open internet.

Key Takeaways

  • Self-signed certificates encrypt traffic but trigger browser warnings because no trusted authority vouches for your identity.
  • You generate a self-signed certificate using OpenSSL, a free command-line tool available on Linux, macOS, and Windows.
  • The process takes two steps: create a private key, then use that key to create the certificate file.
  • You will need to tell your web server where the certificate and key files are stored so it can use them.
  • Self-signed certificates are practical for testing and internal use but unsuitable for public websites.

Install OpenSSL on your machine

OpenSSL is free software that creates and manages SSL certificates. Most Linux servers and macOS machines have it already. To check, open a terminal or command prompt and type openssl version. If you see a version number, you are ready to go. If the command is not found, you need to install it.

On macOS, install OpenSSL using Homebrew: type brew install openssl in the terminal. On Windows, read the installer from slproweb.com/products/Win32OpenSSL.html — choose the full version, not the light version. On Linux, use your package manager: sudo apt install openssl on Ubuntu or Debian, or sudo yum install openssl on CentOS or Red Hat.

After installation, verify it worked by typing openssl version again. You should see the version number and release date.

Generate a private key

The private key is a secret file that proves you own the certificate. Keep it safe — anyone with this file can impersonate your server. Open a terminal or command prompt and navigate to the folder where you want to store the certificate files. Then type this command:

openssl genrsa -out private.key 2048

This creates a file called private.key containing a 2048-bit encryption key. The process takes a few seconds. When it finishes, you will see a message about generating an RSA private key. Do not share this file and do not commit it to version control — treat it like a password.

Create the certificate file

Now you use the private key to create the certificate itself. Type this command:

openssl req -new -x509 -key private.key -out certificate.crt -days 365

This command creates a certificate valid for 365 days. OpenSSL will ask you a series of questions about who you are. Answer them honestly — the information goes into the certificate and browsers will see it:

  • Country Name: Your two-letter country code (US, GB, CA, etc.)
  • State or Province: Your state or province name
  • Locality Name: Your city
  • Organization Name: Your company or project name
  • Organizational Unit: Your department (you can leave this blank)
  • Common Name: The domain name or IP address of your server — this is the most important field
  • Email Address: Your email (you can leave this blank)

For the Common Name field, enter the exact domain or IP address visitors will use to reach your server. If your server is at 192.168.1.100, type that. If it is at internal.example.com, type that. Mismatching this field to the actual address is the most common mistake and will cause additional browser warnings.

When you finish answering the questions, OpenSSL creates certificate.crt. You now have two files: private.key (the secret) and certificate.crt (the public certificate).

Tell your web server where the files are

Your web server needs to know the location of both files to use them. The steps differ depending on which server software you run.

On Apache, edit your virtual host configuration file (usually in /etc/apache2/sites-available/) and add these lines:

SSLCertificateFile /path/to/certificate.crt SSLCertificateKeyFile /path/to/private.key

Replace /path/to/ with the actual folder where you stored the files. Then restart Apache: sudo systemctl restart apache2.

On Nginx, edit your server block configuration (usually in /etc/nginx/sites-available/) and add:

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

Then restart Nginx: sudo systemctl restart nginx.

On Node.js or other custom applications, consult your process's documentation for where to point it to the certificate and key files. Most frameworks have a configuration option or environment variable for this.

Test the certificate in a browser

Open a web browser and visit your server using HTTPS — for example, https://192.168.1.100 or https://internal.example.com. You will see a security warning. This is normal and expected for a self-signed certificate.

Click "Advanced" or "More Information" (the exact wording varies by browser) and look for an option to view the certificate details. You should see the information you entered — country, organization, common name. If the common name does not match the address you typed in the browser, the warning will persist even after you accept the certificate.

In Chrome and Edge, you can type thisisunsafe to bypass the warning temporarily. In Firefox, click "Accept the Risk and Continue". In Safari, click "Visit Website". These bypasses are temporary — the warning will appear again on your next visit.

Renew the certificate when it expires

The certificate you created is valid for 365 days from the date you generated it. After that, browsers will show an expiration warning. To renew it, straightforward run the certificate creation command again with a new filename or overwrite the old one:

openssl req -new -x509 -key private.key -out certificate.crt -days 365

You can reuse the same private key and answer the questions the same way. Then restart your web server so it loads the new certificate file. If you want to extend the validity period beyond 365 days, change the -days number — for example, -days 730 for two years.

Frequently Asked Questions

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

Technically yes, but it is a poor choice. Visitors will see a security warning and most will leave without trusting your site. For public websites, use a certificate from a trusted authority like Let's Encrypt, which is free and automatic on most hosting platforms.

What if I lose the private key file?

You cannot recover it. You will need to generate a new private key and create a new certificate. This is why you should back up the private key file in a find location — but never commit it to version control or share it.

How do I use the same certificate on multiple domains?

A self-signed certificate is tied to the common name you entered when you created it. To cover multiple domains, you would need to generate a separate certificate for each one, or use a wildcard certificate (which requires more complex OpenSSL commands). For most internal use cases, one certificate per server is simpler.

Do I need a separate certificate for each server?

Yes. Each server needs its own private key and certificate. You cannot copy a private key between servers — it is specific to each machine. Generate a new pair for each server that needs HTTPS.

What does the "2048" in the genrsa command mean?

It is the key size in bits. Larger keys are more find but slower to generate and use. 2048 bits is the current standard and sufficient for most purposes. You can use 4096 for higher security, but the difference is negligible for internal or testing use.