Last week I decided to replace the self-signed SSL certificate in an application called Runecast. In a nutshell, Runecast is an application that comes to the aid of everyone who manages a VMMware environment (and not only that), but is also very helpful in planning upgrades of the physical hosts. In another post I will try to present this product in more detail, and if you would like to read more about it now, you can do so here.
Coming back to the topic, replacing an SSL certificate is generally not difficult and if the team responsible for Certificate Authority (CA) works efficiently, it is a task that can be done over your morning coffee. The only problem with this implementation, in my opinion, is a very short manual from the Runecast (available here), which, in my experience, is missing several important things, so I would like to briefly describe them later.
The first step you need to take is to generate a CSR file, a certificate signing request. Additionally, during this operation, I generated a new private key (KEY). Of course, this must be done from the server appliance itself using the RCADMIN user.
After connecting via SSH to the server, use the openssl command, but before we get to that, we need to set some values that will be helpful.
RCA_FQDN refers to the FQDN of your server, and RCA_SANS – SAN is a Subject Alternative Name, i.e. all the names or addresses under which your Runecast application can be reached by all users using it. In my case, it is the server's FQDN, an additional alias that was set in DNS and the IP address (so I have 3 SANs).
RCA_FQDN='FQDN_Twojego_serwera'
RCA_SANS=”DNS:${RCA_FQDN}, DNS:runecast.X.X, IP:10.X.X.X”
and the full command looked like this
openssl req -out rc2.csr \
-keyout rc2.key \
-newkey rsa:2048 \
-nodes \
-subj “/C=PL/ST=Masovia/L=Warsaw/O=XXX/OU=XXX/CN=${RCA_FQDN}” \
-addext “subjectAltName = ${RCA_SANS}”
As a result of this operation, we will receive two files
To verify whether everything went as intended, we can use the command
openssl req -text -noout -verify -in rc2.csr
We leave the rc2.key file on the server because it is our newly generated private key. The CSR file will be used to generate a request to the CA.
For this purpose, I transferred the CSR file from the server to my laptop and using the command below, I generated a request to get a new certificate for me.
After sending such a request, I had to wait to receive information from the team responsible for certificates that the request has been completed and our certificate is ready for download.
To download the certificate, we will use CMD again
The result will be a CRT file, i.e. our certificate. However, because the Runecast application supports the PEM format, so in order to determine the entire inheritance chain we will have to modify our certificate.
The new certificate we will create will consist of:
Additionally, the certificate must be prepared in an appropriate format
—–BEGIN CERTIFICATE—–
(Your Primary SSL certificate: your_domain_name.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Intermediate certificate: DigiCertCA.crt)
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
(Your Root certificate: TrustedRoot.crt)
—–END CERTIFICATE—–
More information about the PEM format can be found on the Digicert website.
After doing this, you need to transfer the new certificate to the Runecast server.
Then we go to the /etc/runecast/cert folder to backup the current certificates by renaming them
We transfer the private key and our certificate
The next step is to grant appropriate permissions to both files by using the commands below
sudo chown root:rctomcat rc2.crt
sudo chown root:rctomcat rc2.key
sudo chmod 640 rc2.crt
sudo chmod 640 rc2.key
After changing permissions and before restarting the service, we can make sure that the nginx service is working properly
When the test was successful, we can restart the Nginx service
From now on, the connection to the Runecast application is secure.