Self-signed Custom SSL Certificates

Keeping your application secure is essential, and one way to achieve this is by using an SSL-encrypted (Secure Sockets Layer) connection. Our platform offers two options: Built-In SSL for a quick and easy solution, and Custom SSL certificates for more control.

Custom SSL certificates need to be signed by a trusted authority, like Let’s Encrypt. This signature verifies the certificate’s legitimacy, ensuring users can trust the connection to your application.

But you also have the option of self-signing your custom certificate. This creates a secure connection, but with a catch: because it’s not signed by a trusted authority, users will see a warning message when they try to access your application. This warning can discourage them from visiting your site, as it raises a red flag about the security of the connection.

Since most users will hesitate to proceed through a warning message, we recommend against using self-signed certificates for production environments. However, they can still be valuable for specific situations:

• Development and Testing: Perfect for internal testing where trust isn’t a major factor.
• Limited Audience Sites: A self-signed certificate might be acceptable if you have a private website with a small, trusted audience.

Generate a Self-Signed SSL Certificate

To generate a self-signed certificate, you’ll first need to acquire a Domain Name (e.g., mysite.com) from your domain registrar.

Once you’ve secured your domain name, you can proceed with generating your SSL certificate using your preferred tool. For this example, we’ll use OpenSSL. Depending on the operating system you’re using, follow the appropriate steps:

• For Windows
• For Linux/MacOS/FreeBSD

Alternatively, you can generate the necessary files using our Elastic Cloud Virtual Private Server.

For Windows

Download the most recent OpenSSL version from the official website. After downloading, extract the archive and navigate to the bin folder. Double-click on the openssl.exe file to run the tool. The files created using OpenSSL will appear in the same bin directory by default.

Step 1: To begin, generate an SSH private key for your root certificate (which is used to sign all issued certificates). Create it as follows:

genrsa -out {filename} {length}

Where:

• {filename} represents the name of the output key file with a .key extension (e.g., host.key).
• {length} denotes the private key length in bits (e.g., 2048).”

Step 2: Next, you should generate the root CA certificate based on the prepared key. Use the req command with the x509 option flag to output a self-signed root certificate instead of a certificate request:

req -config {config_path} -x509 -new -key {keyname} -days {days} -out {filename}

Where:

• {config_path} is the path to the openssl.cnf configuration file, located in the directory with the extracted OpenSSL files (specified according to the C:\path\to\openssl.cnf format).
• {keyname} is your root key name (the one you generated in the previous step, rootCA.key in our case).
• {days} is the number of days the current certificate will be valid.
• {filename} is the preferred name of the output certificate file with a .crt extension (e.g., rootCA.crt). Ensure to set the required information for your CA certificate by answering the questions prompted during the process.”

Provide the necessary information for your CA certificate by responding to the questions that appear during the process.

As a result, you’ll obtain a self-signed root certificate for your own Certificate Authority (CA).

Step 3: Now, you can create a private key and self-signed certificate for your purchased hostname. Let’s begin with the key: generate it using the same method you used for the root key.

genrsa -out {filename} {length}

Where:

• {filename} represents the name of the output key file with a .key extension (e.g., host.key).
• {length} denotes the private key length in bits (e.g., 2048).

Step 4: Next, you’ll need a certificate signing request (CSR). Execute the following command:

req -config {config_path} -new -key {keyname} -out {filename}

Where:

• {config_path} is the path to the openssl.cnf configuration file, located in the directory with the extracted OpenSSL files (specified in the C:\path\to\openssl.cnf format).
• {keyname} is your server key name (the one you generated in the previous step, host.key in our case).
• {filename} is the desired name of the output request file with a .csr extension (e.g., host.csr).

You’ll see a set of questions appear again. Answer them to complete the certificate information with your data.

Step 5: The final step is to generate your self-signed certificate based on the created request using the root CA certificate. For that, we’ll use the x509 command with the following options:

• req indicates that a certificate request input file format is expected.
• CAcreateserial initiates the creation of the CA serial number file (if it does not exist).

x509 -req -in {requestname} -CA {CA_certificate} -CAkey {CA_key} -CAcreateserial -out {filename} -days {days}

Where:

• {requestname} is the name of the input request file (host.csr in our case).
• {CA_certificate} specifies the CA certificate that will be used for signing (rootCA.crt in our case).
• {CA_key} sets the CA private key to sign the certificate with (rootCA.key in our case).
• {filename} is the desired name of the output certificate file with a .crt extension (e.g., host.crt).
• {days} is the number of days the current certificate will be valid.

Great! Now, you have a self-signed SSL certificate for your application.

For Linux/MacOS/FreeBSD

If you don’t have the OpenSSL tool installed yet, you can get it using the appropriate command for your OS package manager. For example, for the Ubuntu/Debian Linux distribution, use the following command:

sudo apt-get install openssl

When the installation process is completed, proceed to generate the required files. All files created with OpenSSL will appear in the home directory of your local machine user by default.

Step 1: To begin, generate an SSH private key for your root certificate, which is responsible for signing all issued certificates. Create it as follows:

openssl genrsa -out {filename} {length}

Where:

• {filename} – name of the output key file with a .key extension (e.g., rootCA.key)
• {length} – private key length in bits (e.g., 2048)

Step 2: Next, generate the root CA certificate using the prepared key. Use the `req’ command with the `x509` option flag to output a self-signed root certificate instead of a certificate request:

openssl req -x509 -new -key {keyname} -days {days} -out {filename}

Where:

• {keyname} – your root key name (the one you generated in the previous step, rootCA.key in our case)
• {days} – number of days the current certificate will be valid
• {filename} – the preferred name of the output certificate file with a .crt extension (e.g., rootCA.crt)

Set the required information for your CA certificate by answering the questions that appear.

As a result, you’ll receive a self-signed root certificate for your own CA.

Step 3: Now, you can create a private key and self-signed certificate for your purchased domain. Let’s start with the key: generate it like you did for the root one.

openssl genrsa -out {filename} {length}

Where:

• {filename} – name of the output key file with a .key extension (e.g., host.key)
• {length} – private key length in bits (e.g., 2048)

Step 4: Next, generate a certificate signing request (CSR). Execute the following command:

openssl req -new -key {keyname} -out {filename}

Where:

• {keyname} – your server key name (the one you’ve generated in the previous step, host.key in our case)
• {filename} – the desired name of the output certificate file with a .csr extension (e.g., host.csr)

You’ll see a set of questions appear again. Answer them to complete the certificate information with your data.

Step 5: Finally, generate your self-signed certificate based on the created request, using the root CA certificate. For this, use the x509 option with the following flags:

• req: Indicates that a certificate request input format is expected.
• CAcreateserial: Initiates the creation of the CA serial number file (if it does not exist).

openssl x509 -req -in {requestname} -CA {CA_certificate} -CAkey {CA_key} -CAcreateserial -out {filename} -days {days}

Where:

• {requestname}: Name of the input request file (host.csr in our case).
• {CA_certificate}: Specifies the CA certificate that will be used for signing (rootCA.crt in our case).
• {CA_key}: Sets the CA private key to sign a certificate with (rootCA.key in our case).
• {filename}: Desired name of the output certificate file with a .crt extension (e.g., host.crt).
• {days}: Number of days the current certificate will be valid.

Great! Now you have the self-signed SSL certificate for your application.

Elastic Cloud VPS

You also have the possibility to create your self-signed certificate using the Elastic VPS server. Here’s how:

Step 1: Create an environment with Elastic VPS inside.

Step 2: Connect to it in a preferred way (using Public IP or via SSH Gateway).

Step 3: Access the OpenSSL shell with the corresponding openssl command.

Step 4: Create a self-signed certificate following the Linux/MacOS/FreeBSD section of this guide (the only difference is all the commands should be executed without the openssl word at their beginning, as you are already inside the OpenSSL shell).

Step 5: Once the generation process is finished, download the created certificate files (e.g., via Configuration File Manager) to apply them to the necessary environment afterwards.

That’s it! If you enter the bound custom domain name (or the attached external IP address) into your browser’s address bar with the https:// connection protocol, you’ll see the mentioned warning message opened, informing you that the used SSL certificate is not trusted.

Since it’s your site, click the “Proceed anyway” button (or a similar one depending on your browser).

After that, you’ll be redirected to your site via the encrypted protocol.

Now, you can be sure all interactions with your application are performed safely.