Self-Signed Custom SSL Certificate

One of the ways to secure your application is to use the encrypted with SSL (Secure Sockets Layer) connection. With Jelastic Cloud, you can use both Jelastic SSL and Custom SSL certificates.

Herewith, all custom SSL certificates require to be signed, and usually this is done by the Certificate Authority (CA) companies. In this case, your certificate becomes reliable after signing, so others can trust it and any connection to your site or application is performed without issues.

Nevertheless, you can sign your custom certificate yourself and still receive a secure connection, but such a certificate will be untrusted. As a result, while opening your application it will require a visitor to pass through the warning message, that highly recommends him to leave your web page, because of the untrusted secure connection.

Most of these users will leave such a page, so we suggest that you don’t use the self-signed certificates for production solutions, but it can still be used for development/testing examples or for your own private site with a small audience.

So, let’s find out how to generate such a certificate and apply it to the Jelastic environment.

Generate a Self-Signed SSL Certificate

In order to generate a self-signed certificate, you need to buy a Domain name first (e.g. mysite.com). You can do this using any domain registrar.

Once that is done, you are ready to proceed to generation of your SSL certificate with the help of any preferred tool. We’ll use OpenSSL as an example. Depending on the operating system you are using, perform the following steps:

You are also able to generate the required files using our Elastic Virtual Private Server.

For Windows

Download the latest OpenSSL tool version. Extract the received archive and run the tool by double-clicking the openssl.exe file in the bin folder. Subsequently, the files created with OpenSSL will appear in the same bin directory by default.

1. First, you need to generate an SSH private key for your root certificate (this is what signs all issued certificates). Create it as follows:

genrsa -out {filename} {length}

where

{filename} - name of the output key file with .key extension (e.g. rootCA.key)

{length} - private key length in bits (e.g. 2048)

2. Then you should generate the root CA certificate based on the prepared key. Use the req command with the x509 option flag for outputting 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} - path to the openssl.cnf configuration file, located in the directory with extracted OpenSSL files (specified according to the C:\path\to\openssl.cnf format)
{keyname} - your root key name (the one you’ve 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 .crt extension (e.g. rootCA.crt).

Set the required information for your CA certificate by answering the appeared question.

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

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

genrsa -out {filename} {length}

where

{filename} - name of the output key file with .key extension (e.g. host.key)

{length} - private key length in bits (e.g. 2048)

Note: DO NOT protect your key with a passphrase, otherwise you'll get an error during its addition to the Jelastic dashboard.

4. Next thing you need is a certificate signing request (CSR). Execute the following command:

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

where

{config_path} - path to the openssl.cnf configuration file, located in the directory with extracted OpenSSL files (specified according to the C:\path\to\openssl.cnf format)
{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 request file with .csr extension (e.g. host.csr).

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

IMPORTANT: Note that the Common Name parameter value has to be equal to your purchased domain name, otherwise your certificate won't be validated.

5. The final step is generation of your self-signed certificate based on the created request with the help of a root CA certificate. For that, we’ll use the x509 command with the following options:

  • -req - means that certificate request input file format is expected
  • -CAcreateserial - initiates 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} - 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} - the desired name of the output certificate file with .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.

For Linux/MacOS/FreeBSD

In case you don’t have the OpenSSL tool installed yet, get it with the appropriate command (according to your OS package manager) executed within your terminal. E.g. for Ubuntu/Debian Linux distribution use the following one:

sudo apt-get install openssl

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

1. First, you need to generate an SSH private key for your root certificate (this is what signs all issued certificates). Create it as follows:

openssl genrsa -out {filename} {length}

where

{filename} - name of the output key file with .key extension (e.g. rootCA.key)

{length} - private key length in bits (e.g. 2048)

2. Then you should generate the root CA certificate based on the prepared key. Use the req command with the x509 option flag for outputting 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’ve 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 .crt extension (e.g. rootCA.crt).

Set the required information for your CA certificate by answering the appeared question.

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

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

openssl genrsa -out {filename} {length}

where

{filename} - name of the output key file with .key extension (e.g. host.key)

{length} - private key length in bits (e.g. 2048)

Note: DO NOT protect your key with a passphrase, otherwise you'll get an error during its addition to the Jelastic dashboard.

4. The next thing you need is 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 .csr extension (e.g. host.csr).

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

IMPORTANT: Note that the Common Name parameter value has to be equal to your purchased domain name, otherwise your certificate won't be validated.

5. The final step is generation of your self-signed certificate, based on the created request with the help of the root CA certificate. For that, we’ll use the x509 option with the following flags:

  • -req - means that certificate request input format is expected
  • -CAcreateserial - initiates 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 .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 VPS

You also have the possibility to create your self-signed certificate using the Elastic VPS server. For that you need to:

  • create an environment with Elastic VPS inside
  • connect to it in the preferred way (using Public IP or via SSH Gateway)
  • access the OpenSSL shell with the corresponding openssl command
  • 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)

Once the generation process is finished, you need to download the created certificate files (in order to apply them to the necessary environment afterwards). To do this, exit the OpenSSL shell using the exit command and run a simple HTTP server:

python -m SimpleHTTPServer  

It will be used for downloading the required files. Therefore, access the started server by means of typing the next URL into your browser’s address bar:

http://{vps_ip}:{port}

where

{vps_ip} - external IP of your VPS node; can be found by clicking the Additionally button for your CentOS server (the required address will be the second one) or in the email with its administration data you’ve previously received

{port} - port number the HTTP server has been run at (can be seen just after the line with executed command, 8000 in our case)

Depending on your hosting provider, you can be faced with an unavailability to establish the connection to this server due to the enabled firewall protection. In this case, return to your VPS console and enter the following line to it:

/etc/init.d/iptables stop

Then, run your HTTP server again and refresh the browser page with the abovementioned URL specified.

You’ll see the list of files, available inside the directory you’ve run the HTTP server in.

Download the required certificate files (circled above) to your local machine.

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

Adjust Environment Topology and Set A Record

1. In order to be secured with any custom SSL certificate (regardless if it is signed by a real CA or the self-signed one), your environment should be configured in a proper way, i.e.:

  • contain at least one application server
  • have a single entry point with the Public IP address enabled

The detailed instruction can be seen in the Adjust Environment Topology section of the Custom SSL document.

2. Once all of the required configurations are performed, you need to bind your application’s Public IP to the previously purchased domain name by means of setting an A Record. This can be done with the help of the DNS Manager of the chosen domain registrar.

In order to get the Public IP address of your application, select the additional button  for a node in your environment it was attached to (i.e. for the NGINX-balancer server in the case of .NET/Python/Node.js usage, or for the application server in all other cases).

You’ll see the list of IPs, wherein the second one is the required Public IP address.

For additional information, see the corresponding instruction (starting from the 5th step of the Domain Name and A Record Settings section).

Upload Self-Signed SSL Certificate to the Environment

The last thing you need to do is to add the created certificate files to your environment.

1. Click the Settings button for the appropriate environment.

2. In the opened tab, choose the Custom SSL option within the left-hand list.

Upload Server key, Intermediate certificate (CA) and Domain certificate into the appropriate fields (in our case, the required files are host.key, rootCA.crt and host.crt respectively).

If you've received an error at this stage, ensure your private SSH host key is not protected with a passphrase. Otherwise, remove the protection with the following command and try to upload the files again:

openssl rsa -in {keyname} -out {new-keyname}

Click Save.

3. When the servers in your environment are automatically restarted, you can ensure everything works properly. For that, enter the binded custom domain name (or the attached external IP address) into your browser’s address bar with the https:// connection protocol specified instead of the default http:// one.

You’ll see the page with warning message opened, informing you that the used SSL certificate is not trusted. Since it’s your site, click the Proceed anyway button (or the similar one depending on your browser).

For some browsers (e.g. Mozilla FireFox), even if you’ve decided to proceed, it’s required to add this page to your browser’s exceptions list before you are able to continue.

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

That’s all! For now, you can be sure interaction with your application is performed safely.