While hosting your application, you can face the problem of securing the data operated inside, especially if this data is private and should be transferred between clients and a server. One of the commonly used ways to ensure such protection is encrypting this communication with the help of the SSL (Secure Sockets Layer) protocol.
In order to establish the SSL connection, your web server needs to have the appropriate certificate applied. With Jelastic Cloud, you can use two types of certificates: Jelastic SSL and Custom SSL. The first one is the most rapid method to enable the SSL protection for your environment with the default hostname (this can be done directly through the environment topology wizard). Otherwise, if you’d like to get more functionality and bind the custom domain name for your application, the right choice is to use the Custom SSL certificate (we’ve covered the process of its generation and installation in one of our previous publications).
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 visitors to pass through the warning message, that highly recommends they leave your web page because of the untrusted secure connection.
Such a denotation can confuse inexperienced users, so we suggest using the self-signed certificates only for non-production purposes. It’s a good solution for development/testing instances or for your own private site with a small audience, aimed to gain the increased security without passing the checks and waiting for approval from the CA.
So, let’s find out how to create a Self-Signed Custom SSL 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) using any domain registrar.
Once that is done, you can proceed to generation of your SSL certificate with the help of any preferred tool. We’ll use OpenSSL as an example.
Perform the steps below in order to create an SSL certificate using your local machine (the instruction varies due to your operating system: Windows or Linux/MacOS/FreeBSD) or Elastic Virtual Private Server at Jelastic Cloud.
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:
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:
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.
where
{filename} - name of the output key file with .key extension (e.g. host.key)
{length} - private key length in bits (e.g. 2048)
4. Next thing you need is a certificate signing request (CSR). Execute the following command:
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.
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)
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:
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:
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:
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.
where
{filename} - name of the output key file with .key extension (e.g. host.key)
{length} - private key length in bits (e.g. 2048)
4. The next thing you need is a certificate signing request (CSR). Execute the following command:
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.
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)
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 opensslcommand
- 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:
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)
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.
for a node in your environment it was attached to (i.e. for the NGINX-balancer server in the case of 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).
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 confident that interaction with your application is performed safely.
To confirm that it really is that simple, register now to start a 2-week free trial period, deploy your application, and install a self-signed certificate in just a few minutes!