How to Create a Self-Signed SSL Certificate

In this guide, Servers99 explain exactly what an SSL certificate is, when you should (and shouldn't) use a self-signed version, and walk you through the exact OpenSSL commands to generate one that complies with modern standards.

When you’re setting up a new server, security is usually the first thing on your mind. You already know that you need an SSL certificate to encrypt traffic and keep data safe. But what if you are just testing an application, running a development environment, or configuring an internal server? Paying for a commercial certificate or dealing with rate limits isn't always practical.

This is where a self-signed SSL certificate comes in handy.

What is an SSL Certificate?

An SSL (Secure Sockets Layer) certificate is a digital ID card for your website or server. It does two main things:

Encryption : It scrambles the data sent between a user's browser and your server, which helps protect sensitive data from interception and tampering.
Authentication: It verifies the identity of your server. When a user visits your site, the SSL certificate guarantees they are communicating with the real server, not an imposter.

Normally, these certificates are issued by a trusted Certificate Authority (CA) like Let’s Encrypt, DigiCert, or GoDaddy. Because browsers trust these companies, they show a secure connection when a user visits your site.

What is a Self-Signed SSL Certificate?

A self-signed certificate can provide the exact same encryption strength as a CA-issued certificate, but it does not provide trusted identity verification. Instead of a trusted third-party CA verifying your identity, you are signing the certificate yourself. This lack of a trusted validation chain is why browsers show warnings when you use them.

When to use a self-signed certificate:

Local development and testing environments.
Internal corporate networks (Intranets) where you can manually trust the certificate.
Admin panels or backend services not exposed to the public internet.

When NOT to use it:

Live production websites.
E-commerce stores or public-facing applications.

How to Generate a Self-Signed SSL Certificate

Modern web browsers and operating systems have gotten stricter about security. Today, browsers require the Subject Alternative Name (SAN) extension and expect proper extensions like Extended Key Usage (EKU). While strict validity limits mainly apply to CA-issued certificates, using shorter lifetimes for self-signed certificates is still considered best practice.

The tutorial below uses OpenSSL and includes these configurations to ensure it works smoothly on current environments, preventing edge-case validation issues. We will also use Elliptic Curve Cryptography (ECC) and SHA-256 for optimal security.

Step 1: Navigate to your working directory

First, log in to your server via SSH as the root user or a user with sudo privileges. Let's move to a secure directory to generate our files.

Bash

cd /etc/pki/tls/private/

⚠️

Depending on your Linux distribution, this folder might be /etc/ssl/private/. You can also just do this in your home directory /root and move the files later.

Step 2: Generate and Secure the Private Key

We are going to generate a private key using the prime256v1 elliptic curve. This is a highly secure, modern standard.

Bash

openssl ecparam -name prime256v1 -genkey -out server.key

⚠️

Crucial Security Step: Keep this server.key file completely secret. If anyone gets access to this file, they can decrypt your traffic. We need to restrict file permissions immediately so only the owner (root) can read it:

Bash

 chmod 600 server.key

Step 3: Create the Certificate Signing Request (CSR)

Next, we create the CSR. This file contains the details about your organization and domain.

⚠️

Note: Since you are self-signing, a CSR is technically optional, but we are including it here as it is standard practice and good for understanding how the CA process works

Bash

openssl req -new -key server.key -out server.csr

OpenSSL will prompt you to enter several details. You can leave most of them blank by typing a period (.), but make sure to fill in the Common Name with your server's domain name or IP address.

Plaintext

Country Name (2 letter code) [XX]: US
State or Province Name (full name) []: New York
Common Name (eg, your name or your server's hostname) []: yourdomain.com
Email Address []: [email protected]

Step 4: Create the Extension File (SAN, EKU, Basic Constraints)

To prevent modern clients from rejecting your certificate, you must define the DNS names/IPs it covers, specify its usage, and declare that it is not a CA.

Create a temporary text file. Replace yourdomain.com and 10.0.0.30 with your actual domain and server IP address.

Bash

echo 'subjectAltName = DNS:yourdomain.com, IP:10.0.0.30
extendedKeyUsage = serverAuth
basicConstraints = CA:FALSE' > /tmp/altname.txt

Step 5: Generate the Final Self-Signed Certificate

Now, we will combine the CSR, the private key, and our extension file to create the certificate (server.crt). We are explicitly using -sha256 and setting the validity to 825 days to align with modern best practices.

Run:

Bash

 openssl x509 -in server.csr -out server.crt -req -signkey server.key -extfile /tmp/altname.txt -days 825 -sha256

Step 6: Verify Your Files

Let's check the directory to make sure our files were created successfully.

Run:

Bash

ls -l server.*

You should see server.key (your secured private key) and server.crt (your new SSL certificate). You can safely delete the .csr and .txt files if you wish.

Pro Tip: The Modern OpenSSL One-Liner

If you are an advanced user and want to skip the CSR and temporary text files entirely, you can generate the private key and the self-signed certificate in a single, powerful command:

Run:

Bash

openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
-keyout server.key -out server.crt -days 825 -nodes -sha256 \
-subj "/CN=yourdomain.com" \
-addext "subjectAltName=DNS:yourdomain.com,IP:10.0.0.30" \
-addext "extendedKeyUsage=serverAuth" \
-addext "basicConstraints=CA:FALSE"

(Don't forget to run chmod 600 server.key afterward!)

Next Steps and Bypassing Browser Warnings

Congratulations! You have successfully generated a modern self-signed SSL certificate

To use it, point your web server (like Nginx or Apache) to the server.crt and server.key files inside their configuration blocks.

Dealing with "Not Private" Warnings: When you visit the site for the first time, your browser will still flag the connection as insecure. Because the certificate lacks a trusted CA validation chain, the browser cannot independently verify your identity.

Quick bypass: Simply click "Advanced" and "Proceed" to bypass the warning for that specific session.
Permanent fix for internal use: For internal networks or local development, you can eliminate these browser warnings entirely by manually importing your server.crt file into your OS trust store (like Windows Certificate Manager or macOS Keychain) or directly into your Browser trust store.

Conclusion

If you are looking for high-performance, secure infrastructure to host your web applications, check out our Dedicated Server Hosting Plans. We provide full root access, allowing you to configure your server environment exactly how you need it.