Creating Java or OVS Keystores for TLS/SSL/HTTPS
What is TLS/SSL?
TLS stands for Transport Layer Security, and SSL stands for Secure Sockets Layer. They are different but are used interchangeably in conversation. Regardless of which implementation is used, they both boil down to the same encryption technique under the hood, umbrellaed underneath asymmetric cryptography. So, for our purposes, we can think of them as one in the same. Both facilitate secure communication of data from point A to point B.
In order for the secure connection to be established, we must first configure both endpoints with public and private keys. I won't give a full SSL/TLS primer, but in short, each end of a secure connection has a public key, a private key, and a certificate signed by a certificate authority. The public keys are just that – public. Anyone can see then and you won't disclose any secret information by disclosing them. The same is true for the certificates – they are public as well and can be seen by anyone. On the other hand, the private keys are secret and should never be accessible by anyone or anything besides the application using that key.
Here's a day in the life of a SSL connection:
When a secure handshake first takes place, each side will provide the other side with it's own public key. For example, A will send A_public to B and B will send B_public to A. Upon receipt of the public keys, each side will cross-reference the public keys to the certificates stored in the local keystore. Each side will try to match the public key in hand with a valid certificate. For example, A will take B_public and look for the corresponding B_certificate in its keystore. The certificates serve as validators for the public keys received. They are typically issued by a certificate authority, which is a 3rd party entity that will only grant certificates to trusted machines. So, if a public key is matched to a valid certificate, then the endpoint will assume the public key can be trusted. (Now, it's often a hassle if not a cost issue to have an official certificate made for a public key. So, many machines self-sign their certificates, which is okay, but it's not as secure, since anyone can sign their own certificates. We will self-sign our certificates in this tutorial.)
After each side of the connection verifies the public key received matches a valid certificate, the secure connection will be initialized. You might wonder how the connection can be secure if the public keys are known to anyone. The answer lies in the private keys, which are not disclosed. When a public/private key pair is made, the public key can be used to encrypt some plaintext data, but after encrypted, only the private key made with that public key can decrypt the data or ciphertext. The reason for this phenomenon is way beyond the scope of this tutorial but is backed by some serious discrete math theory. Given this fact, if B has A_public and A has B_public, B can send a message to A by encrypting the plaintext into ciphertext using its copy of A_public. If it sends the ciphertext to A, A will decrypt the message into plaintext using A_private (which is a secret). No matter who might see the message in between A and B, even if they know A_public, they will be unable to render the message as plaintext without also having knowledge of A_private. In this way, A and B can communicate both directions in a secure manner by simply encrypting each message with the public key of the recipient.
Again, the key (no pun intended) to all of this working is keeping all private keys secret. As soon as a private key is leaked, a man-in-the-middle attack is possible, since anyone with a private key can decrypt a message encrypted with the private key's corresponding public key.
In order for two devices to be able to communicate securely with TLS/SSL, they each must:
- Have a private and public key pair.
- Have a signed certificate (either self or authority).
- Provide their signed certificate to the correspondent node ahead of time (web browsers normally mask this process from you).
Preparing Your Keys and Certificates
In the context of Floodlight (a Java application) and OVS, we need to prepare two pairs of keys – one for Floodlight and one for OVS. We also need to generate a certificate for each. (We will share the certificates later on.)
Floodlight Key/Cert. Preparation
Java has its own key management framework, accessible from the keytool terminal program. keytool can be used to generate, import, export, view, and do pretty much any operation on keys and the keystore. By default, your JVM keystore is in $JAVA_HOME/jre/lib/security/<keystore-name>.jks, however, we will start with a clean slate and to make sure we don't mess up any existing keystore you might have. First, change directories to a known location where you want the keystore to reside. I'll change to my checked out copy of Floodlight. Then, invoke the keytool utility to create a new certificate, public, and private key. I specify an alias for the key, which will be helpful when referring to it later on. The keystore parameter specifies the name of the keystore file. Also, the storepass parameter creates a password for the keystore. By default, the JVM keystore has the password of changeit, so I am using the same for this tutorial (but if you are going to have a permanent or semi-permanent deployment, I highly recommend you come up with something else). The keytool utility will prompt you for general information. The last thing it will ask for is a password for the key itself, which can be different from the keystore password. For simplicity, I am setting the key's password the same as the keystore itself.
Ryans-MacBook-Pro:~ ryan$ cd /Users/ryan/Desktop/floodlight/ Ryans-MacBook-Pro:floodlight ryan$ keytool -genkey -keyalg RSA -alias floodlight -keystore keystore.jks -storepass changeit -validity 360 -keysize 2048 What is your first and last name? [Unknown]: Ryan Izard What is the name of your organizational unit? [Unknown]: BSN What is the name of your organization? [Unknown]: BSN What is the name of your City or Locality? [Unknown]: Santa Clara What is the name of your State or Province? [Unknown]: CA What is the two-letter country code for this unit? [Unknown]: US Is CN=Ryan Izard, OU=BSN, O=BSN, L=Santa Clara, ST=CA, C=US correct? [no]: yes Enter key password for <floodlight> (RETURN if same as keystore password): Ryans-MacBook-Pro:floodlight ryan$
At this point, you will have a new file called keystore.jks in your working directory. This is your keystore and contains the key of the alias you defined; mine is "floodlight."
What we want to do next is copy the certificate to OVS. However, the key formats of the Java keystore and OVS's are different, so we need to convert the certificate to a format the OVS keystore can understand. This involves two steps. First, export the JKS keystore to the PKCS12 format.
Ryans-MacBook-Pro:floodlight ryan$ keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype jks -deststoretype pkcs12 Enter destination keystore password: Re-enter new password: Enter source keystore password: Entry for alias floodlight successfully imported. Import command completed: 1 entry successfully imported Ryans-MacBook-Pro:floodlight ryan$
Then, use openssl to convert the PKCS12 file to a PEM file, which is readable by OVS.
Ryans-MacBook-Pro:floodlight ryan$ openssl pkcs12 -in keystore.p12 -out keystore.pem Enter Import Password: MAC verified OK Enter PEM pass phrase: Verifying - Enter PEM pass phrase: Ryans-MacBook-Pro:floodlight ryan$
At this point, our working directory contains keystore.jks – the Java keystore, keystore.p12 – the intermediate PKCS12 keystore, and keystore.pem – the PEM keystore readable by OVS.
Display the contents of keystore.pem. You will see the private key and a certificate for alias "floodight." The private key is of course private. The certificate, however, is what we want to give to OVS and looks something like this:
Ryans-MacBook-Pro:floodlight ryan$ cat keystore.pem
<private key here>
Bag Attributes
friendlyName: floodlight
localKeyID: <some hex key ID here>
subject=/C=US/ST=CA/L=Santa Clara/O=BSN/OU=BSN/CN=Ryan Izard
issuer=/C=US/ST=CA/L=Santa Clara/O=BSN/OU=BSN/CN=Ryan Izard
-----BEGIN CERTIFICATE-----
<some obscure-looking ASCII version of the actual certificate here>
-----END CERTIFICATE-----
From this output, copy the certificate from "Bag Attributes" to "-----END CERTIFICATE-----" to another plain text file and save it as "cacert.pem".
As soon as you have saved this file, you no longer need the files above we generated to expose the certificate in PEM format. So, for security reasons, remove them from the directory. (Note this method does not securely remove the files, so the contents are still on the disk just not accessible by the file names anymore. You might wish to securely erase the files on disk in a production environment.)
Ryans-MacBook-Pro:floodlight ryan$ rm keystore.pem keystore.p12
So, at this point, you will be left with keystore.jks – the password-protected Java keystore and cacert.pm – the certificate signing alias "floodlight"'s public key. The latter is what we want to provide OVS in order for it to verify the public key sent by the controller.
To finish up, copy cacert.pem from your working directory to your OVS installation at "/var/lib/openvswitch/pki/controllerca/cacert.pem". Note, this can be on the localhost if OVS is also running there, or on another machine entirely. It is important to use this directory, since we will assume Floodlight's certificate will be located there in the following steps.
Open vSwitch Key/Cert. Preparation
A prerequisite to using OVS with SSL is that you have built OVS with SSL support. If you have not done so, the following may fail to execute. Simply download the necessary SSL packages for your distribution according to the OVS installation guide and reinstall OVS before proceeding.
Just as we had to create a public and private key, along with a certificate for Floodlight, we must do the same for OVS. This time around though, things will be much simpler, since OVS has built-in tools for just this purpose and we do not have to work around the Java keystore. Create the public key, private key, and certificate for OVS by doing the following:
$ cd /etc/openvswitch $ sudo ovs-pki req+sign sc switch sc-req.pem Mon Mar 9 13:32:31 PDT 2015 fingerprint 6024524eb2284248735a526f1f75e2e3c06b3cdd $
At the conclusion of the above, we have created three new files – the OVS public key, the OVS private key, and the OVS certificate, which is self-signed. We need to point OVS to it's newly-generated public and private keys, along with the controller certificate "cacert.pem" we created in the steps for Floodlight/Java above. (This should be in the correct directory as depicted below, otherwise OVS will not be able to locate it.)
$ sudo ovs-vsctl set-ssl \ > /etc/openvswitch/sc-privkey.pem \ > /etc/openvswitch/sc-cert.pem \ > /var/lib/openvswitch/pki/controllerca/cacert.pem $
OVS now has a public and private key, and also has a copy of the controller's certificate. Let's provide a copy of the certificate to the controller so that it can validate the OVS public key upon the TLS/SSL handshake. Copy OVS's switch certificate PEM file from "/var/lib/openvswitch/pki/switchca/cacert.pem" to the Floodlight controller machine. Once it's there import it to your existing Java keystore as show below, replacing "/path/to/certificate/copied/from/ovs/cacert.pem" with the actual location of your copied PEM file. Be certain to type "yes" when prompted to trust the certificate.
Ryans-MacBook-Pro:floodlight ryan$ keytool -import -alias "openvswitch" -keystore keystore.jks -file /path/to/certificate/copied/from/ovs/cacert.pem Enter keystore password: Owner: CN=OVS switchca CA Certificate (2014 May 22 15:25:49), OU=switchca, O=Open vSwitch, ST=CA, C=US Issuer: CN=OVS switchca CA Certificate (2014 May 22 15:25:49), OU=switchca, O=Open vSwitch, ST=CA, C=US Serial number: 1 Valid from: Thu May 22 18:25:49 EDT 2014 until: Sun May 19 18:25:49 EDT 2024 Certificate fingerprints: MD5: <some hex string here> SHA1: <ditto> SHA256: <ditto> Signature algorithm name: MD5withRSA Version: 1 Trust this certificate? [no]: yes Certificate was added to keystore
Congratulations! Your Java keystore now has a copy of the OVS key's certificate, and (if you completed the prior steps) your OVS now has a copy of the Java key's certificate. When the two applications try to conduct a handshake over SSL/TLS, the public keys exchanged should be able to be verified/cross-referenced against the stored certificates for each party.