How to use certificate verification with the NetApp ONTAP OpenStack Cinder driver

How to configure SSL with certificate verification

HTTPS uses SSL to make the HTTP connection secure, but SSL doesn’t actually provide much security at all unless certificate verification is enabled. In the vast majority of deployments, verification is turned off, because it’s difficult to setup properly, and therefore most of the benefit of SSL isn’t realized.

This document describes how to setup SSL certificate verification with the NetApp ONTAP OpenStack Cinder driver.

Create a CA

While it’s possible to obtain certificates from an actual CA, oftentimes that costs money or interacting with a 3rd party can take too long. The simple solution is to create your own CA.

First install easy-rsa:

We will use easy-rsa to manage our certificates. It requires that you run as root, so I assume from here on out that you’ve done:

Go to the easy-rsa directory and modify the config file. You don’t need to change anything, but the options here will set defaults which you can manually override later on.

When you’re done, source the file:

Now we’re ready to create our CA cert. This step will create the root CA’s key and certificate. Everything else depends on these files, and the security of every certificate generated relies on keeping the key file’s contents private. This command will ask you a bunch of questions about the names in the certificate. The important one is CN (Common Name) which is how this certificate will be referred to.

Next we create the Diffie-Hellman params. Expect this to take a while.

Create a cert for a SVM

Now for each SVM, we need to create a certificate and sign it. It’s important that SVM have DNS names. If you don’t have DNS configured for your SVM management LIFs, now would be a good time to set it up. If you can’t setup DNS, you’ll have to make up hostnames and manually put them on your /etc/hosts file on every OpenStack Cinder node.

For this example, I’m using a SVM called OPSK-01, which has an IP address of I have decided to make up the DNS name because I don’t have working DNS in my lab. I will add an entry to my hosts file now.

We will now create the certificate.

Now at this point we have what we need to install the certificate on the SVM. There are 3 files we need to copy/paste. I suggest dumping them to the terminal and opening another terminal window to SSH to the SVM.

Note that while the two .crt files don’t contain sensitive information, the .key file does. If the contents of this .key file fall into the wrong hands than all SSL communications to the SVM where we install it will be compromised.

Install the certs on the SVM

In a second terminal window, let’s SSH to our SVM. We can use the DNS name that we made up for this purpose.

First let’s list the installed certificates:

The existing certificate is self-signed and worthless. Let’s delete it:

At this point SSL has been disabled, if it was previously enabled.

Next we install the certificate we just created. We will copy paste the SVM cert, and then the SVM key, then it will ask us if we want to continue. We will answer yes the first time and no the second time. Note that you should only copy the text between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. You don’t need the human-readable part. Also note that you have to enter an empty line after you paste the text each time.

You should keep a copy of the private key and the CA-signed digital certificate for future reference.

Now we can re-enable SSL on this SVM. Note that the serial at the end of the command will vary depending on how many certs your CA has generated. Use tab completion and ONTAP will tell you the correct serial.

We can now end our ssh session and go back to finish up the installation on the Cinder node.

Trusting your CA

Because anyone can create a root certificate and perform security attacks on every machine that trusts that certificate, it’s important to be careful about adding trusted certificates. In this case, the root certificate is ours, and we trust ourselves, so we will install it. Just remember that after we do this, anyone who has the ca.key file we created at the beginning can compromise all SSL communications on the client where we install this certificate, so keep your key files safe.

We will copy/paste the contents of that ca.crt file into a file on each Cinder node. I have chosen the filename bswartz-ca.crt to disambiguate it from other cert files.

Last we have to run the update command which will install the certificate and make it trusted.

At this point all that’s left to do is update your cinder.conf file to enable https and to set the SVM hostname to the DNS name we created instead of the IP address.

Other SVMs

The process is repeatable for each SVM. The CA certificate can be re-used, and you just need to run the ./build-key-server script for each new SVM, and install the certificate on the SVM. Clients that trust our CA will automatically verify the new certificate.

Other clients

If there are multiple Cinder nodes, each one needs its /etc/hosts file updated for every SVM’s hostname (if you don’t have working DNS). Each Cinder node needs to have the CA certificate installed one time.

You’re done!

Now you can use HTTPS without getting errors or warnings from python libraries which correctly reject self-signed certs as insecure. Configuring SSL this way also protects from MITM (man in the middle) attacks which are way easier to perform than most people believe.

Ben Swartzlander
Ben has been working in the storage industry as a software engineer for more than 15 years and has extensive experience with storage systems, network protocols, virtualization, and open source projects. Ben has been a contributor to the OpenStack project for nearly 5 years.

Leave a Reply