In the previous article I described my first impressions after launching the successor to Cisco VIRL, the Cisco Modeling Labs 2.0. I pointed out that one of the potentially strong points of CML 2.0 will be its API. However, for the proper functioning of the API, it would be appropriate to change the default SSL certificate. I have prepared an instructions on how to do it – this is unfortunately not an easy task, but anyone can install their own SSL certificate in CML 2.0

Why install own SSL certificate?

It is not essential to install own SSL certificate. Nothing prevents you from leaving the default certificate signed with an internal CA called VIRL Labs CA. The only thing we’re going to face is browser warnings that CA is not trusted. Also, running any scripts that use the API will require that you ignore invalid certificates. And what if such a server we would like to issue to the Internet to remotely manage simulations? Or write a phone application for such management? Then the built-in certificate will certainly not pass.

A few years ago, for the needs of my lab and home network, I launched the Certificate Authority service. I also created a set of scripts for generating keys and signing requests. I installed CA certificates as trusted on my devices. Thanks to this, on the one hand, I am sure that I connect to my device, on the other hand, I do not have to bypass security mechanisms built into the API.

If you want to build a similar infrastructure at your place, you can follow the description that I posted on my English-language blog a few years ago.

Let’s create the SSL certificate

In CML 2.0, certificates are used in two places. Those are the Lab Manager listening on port 443 and System Maintenance Controls on port 9090. I only exchanged the certificate in the first one because it is responsible for access to the GUI and API interface. It seemed to me that it would be a relatively simple operation and possible to be performed by the GUI or CMS administration panel. Nothing could be more wrong! Unfortunately, this is another thing that has not been thought of in CML 2.0 and requires a combination of things. Seriously, the form in the administrative panel would be enough. Even my almost 10-year-old NAS has it ….

We need to generate an encryption key, CSR (Certificate Signing Request), and sign it in our CA infrastructure. We can create the key and CSR on a machine with CML 2.0, but it will simplify your task. All we need is a computer with Linux and OpenSSL. We also need to know the IP address and FQDN (if we have given it) of our virtual machine with CML 2.0. For me, they are 172.16.1.5 and cml.virl.lan respectively. The key and CSR generating command looks like this:

SAN = DNS: cml.virl.lan, IP: 172.16.1.5 openssl req -new -nodes -out cml.virl.lan.csr -keyout cml.virl.lan.key -subj "/CN=cml.virl.lan "-config etc / server-SAN-env.conf

In my network, all certificates must have the Subject Alternative Name extension, hence the need to define the SAN variable and use the appropriate CA service configuration. I have not tested whether the certificate without SAN will work correctly in CML 2.0. We sign the CSR request generated this way using our CA.

openssl ca -config etc / signing-ca.conf -in cml.virl.lan.csr -out cml.virl.lan.crt -extensions server_ext

In this way, we generated the key and our CA certificate. We can proceed with the installation.

Installing new SSL certificate in CML 2.0

If there is no dedicated form used to change the certificate, we must manually replace it. Unfortunately, the SSH service in CML 2.0 will connect us with CLI to manage simulations, not the operating system. We have two alternatives. First, we can log in to the system administrator account using the virtual machine console. The second way is to call the command line from the System Maintenance Controls panel. Then we need to use for example SCP to copy the certificate and key files to the virtual machine operating system with CML 2.0.

The CML 2.0 interface is launched using the nginx. The configuration files are located in the /etc/nginx directory. Among them, the file with the key (privkey.pem) and certificate (fullchain.pem). The easiest way to back up these files and upload your own key and certificate that you created earlier. Let’s remember that to perform this operation, we need to increase our privileges using sudo.

Finally, we return to the System Maintenance Controls panel, go to the Services tab and find The nginx HTTP and reverse proxy server service. We enter its settings and restart. After restarting the service, we will see that it identifies itself with our certificate. If the restart fails, the reason information should be displayed on the console screen. For me, to my surprise, nginx did not require that the service certificate be accompanied by the certificates of CA itself and Signing CA.