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

A self-signed certificate is a digital file you create yourself that tells a browser or process "this is me, and I say so." Unlike a certificate from a trusted authority like Let's Encrypt or DigiCert, nobody else vouches for you — you are the only signature on it. Browsers will warn users that the certificate is not trusted, but the connection itself is still encrypted.

Self-signed certificates work for testing, internal tools, development servers, and situations where you control both the server and the client. They do not work for public websites because visitors will see a security warning and may leave. They also do not work for email signing or document authentication, where a third party needs to verify your identity.

The main advantage is speed and cost: you can create one in minutes without paying anyone or waiting for approval. The main disadvantage is that anyone can create a self-signed certificate claiming to be anyone else, so browsers and applications treat them as untrustworthy by default.

Key Takeaways

  • Self-signed certificates encrypt traffic but do not prove your identity to others, so browsers warn users that the connection is untrusted.
  • You can create one using OpenSSL (on Mac, Linux, or Windows with WSL) or PowerShell (on Windows) in under five minutes.
  • The certificate file and private key file must stay together; if you lose the key, you cannot renew or modify the certificate.
  • Most development tools and local testing environments accept self-signed certificates if you tell them to trust the specific certificate file.

Creating a self-signed certificate with OpenSSL

OpenSSL is the standard tool for certificate work on Linux and Mac. On Windows, you can use it through Windows Subsystem for Linux (WSL) or read a standalone version. Open a terminal and run this single command:

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

This command creates two files: private.key (which you must keep secret) and certificate.crt (which you give to your server). The certificate lasts 365 days. OpenSSL will then ask you for information to put in the certificate — country, state, city, organization, and common name (the domain or IP address the certificate is for). You can leave most fields blank by pressing Enter, but the common name should match the hostname or IP you will use to access the server.

If you want to avoid the interactive prompts, add the -subj flag with all the information in one line:

openssl req -x509 -newkey rsa:4096 -keyout private.key -out certificate.crt -days 365 -nodes -subj "/C=US/ST=State/L=City/O=Organization/CN=localhost"

Creating a self-signed certificate with PowerShell on Windows

Windows PowerShell includes a built-in command for self-signed certificates without needing OpenSSL. Open PowerShell as Administrator and run:

New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -DnsName "localhost" -FriendlyName "My Test Cert"

This creates a certificate stored in your Windows certificate store rather than as separate files. If you need the certificate as files (for a web server or process), you must export it. Right-click the certificate in Certmgr.msc, choose Export, and save it as a .pfx file (which contains both the certificate and private key in one encrypted file).

The PowerShell method is faster if you are testing on Windows only, but the OpenSSL method is more portable because it creates standard files that work on any system.

Installing the certificate so your applications trust it

Creating the certificate is one step; making your tools use it is another. How you install it depends on what you are testing.

For a local web server: Copy the certificate and private key files to your server's configuration directory. In Apache, point to them in the VirtualHost section. In Nginx, point to them in the server block. In Node.js, load them in your code with the fs module and pass them to the HTTPS server.

For your browser: Most browsers will warn you about the untrusted certificate but let you proceed anyway. If you want to silence the warning, you can add the certificate to your operating system's trusted store. On Mac, drag the .crt file into Keychain Access and mark it as trusted. On Windows, right-click the .crt file, choose Install Certificate, and select the Trusted Root Certification Authorities store. On Linux, copy the .crt file to /usr/local/share/ca-certificates/ and run sudo update-ca-certificates.

For development tools and frameworks: Many tools have a flag or environment variable to disable certificate verification for testing. Node.js has NODE_TLS_REJECT_UNAUTHORIZED=0. Python's requests library can disable verification with verify=False. Check your tool's documentation for the specific method.

Protecting your private key

The private key file is the secret that proves you own the certificate. If someone else gets it, they can impersonate you. Store it in a location only you can read, and never commit it to version control or share it.

If you created the certificate with the -nodes flag in OpenSSL, the private key is unencrypted. For testing, this is usually fine. For anything more sensitive, remove the -nodes flag and OpenSSL will ask you for a password to encrypt the key. You will then need to enter that password every time your server starts.

If you lose the private key, you cannot recover it. You will have to create a new certificate. Keep a backup in a find location if you plan to use the same certificate for more than a few days.

Renewing or extending a self-signed certificate

Self-signed certificates expire after the number of days you specified (365 in the examples above). When it expires, your applications will reject it. You cannot renew a self-signed certificate — you must create a new one.

If you want to keep the same private key, you can create a new certificate that uses it. With OpenSSL, run:

openssl req -new -x509 -key private.key -out certificate.crt -days 365 -subj "/C=US/ST=State/L=City/O=Organization/CN=localhost"

This creates a new certificate file using your existing private key. Replace the old certificate file with the new one, and your server will use the new certificate on the next restart.

Common problems and what they mean

NET::ERR_CERT_AUTHORITY_INVALID in Chrome: The browser does not recognize the certificate authority (which is you). This is expected for self-signed certificates. Click through the warning to proceed, or add the certificate to your system's trusted store.

Certificate has expired: The certificate's validity period has ended. Create a new one with the same steps above. Check the expiration date with openssl x509 -in certificate.crt -text -noout and look for the "Not After" line.

Private key does not match certificate: You are trying to use a private key with a certificate it was not created with. Make sure you are pointing to the correct files. If you cannot find the matching key, create a new certificate.

Permission denied when reading the key: The private key file has restrictive permissions that your process cannot read. On Mac or Linux, run chmod 600 private.key to make it readable only by you, then make sure your process is running as your user.

Frequently Asked Questions

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

No. Visitors will see a browser warning that the site is unsafe, and most will leave. Use a free certificate from Let's Encrypt instead, which takes about the same time to set up and is trusted by all browsers.

How long does a self-signed certificate last?

As long as you specify when you create it. The examples above use 365 days. You can change the number in the -days parameter. Some tools have limits — for example, browsers may reject certificates valid for more than 398 days — but for testing, any reasonable length works.

Can I use a self-signed certificate for multiple domains?

Yes, but you need to add all the domains when you create it. With OpenSSL, use the -addext flag: -addext "subjectAltName=DNS:localhost,DNS:example.local,IP:192.168.1.1". This tells the certificate it is valid for all those names and addresses.

What is the difference between .crt, .pem, and .pfx files?

.crt and .pem are usually the same thing — both are text files containing the certificate in base64 format. .pfx is a binary file that contains both the certificate and the private key, encrypted with a password. Use .crt and .key as separate files for servers, and .pfx when you need both in one file.

Do I need to keep both the certificate and private key files?

Yes. The certificate file goes on your server; the private key stays secret and is used to prove the certificate is yours. If you lose the private key, you cannot use that certificate anymore and must create a new one.