We’ve had to replace numerous HyperDrive SSL certificates already as the self-signed SSL certificates generated by the RES HyperDrive appliance won’t cut it if you want to use the appliance in production or if iOS/OS X devices are deployed. Fellow RES guru Rob Aarts has an article published on RESguru.com, but I’ve had differing experiences and our process is slightly different.
Unfortunately (for seemingly me in particular) I always appear to receive a “SSL key not valid” error when trying to import the certificate via the wizard (Nomadesk are aware of the problem and are investigating):
RES do have a KB article (login required) that details how to manually replace the certificate. There are some fairly simple steps that you follow, but as with all the RES HyperDrive documentation so far, there are some holes in it if you’ve never performed the actions before.
In the post I will assume that you have you SSL certificate in 2 parts; the public certificate (.crt file) and the private key (.key file). If you need to know how to generate these files from a .pfx file, I suggest you refer to the instructions in the Replacing the Default XenServer WSS Certificate post first and look for the “Converting the Certificate to a .CRT and .KEY Pair” section. Note: there must not be a password on the .key file!
Preparing the Files
The RES HyperDrive appliance requires 3 files; the public certificate file, the private key file and the CA intermediaries. These files need to be named localhost.crt, localhost.key and ca-bundle.crt respectively.
It is probably easier to rename these files before copying them to the appliance (and it’ll keep the post shorter!).
Backup the Self-Signed Certificate
Once connected to the RES HyperDrive appliance console you can backup the existing certificate files with the following commands:
mv /etc/pki/tls/certs/localhost.crt /etc/pki/tls/certs/localhost.crt.old mv /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-bundle.crt.old mv /etc/pki/tls/private/localhost.key /etc/pki/tls/private/localhost.key.old
If you get any permissions errors, remember to elevate to root with the su – command first.
Transfer the Files
The next step is to transfer the files to the HyperDrive appliance. I’ll assume that you’ve copied these to the appliance via SSH/SCP and they reside in the /home/hyperdrive directory. If you’ve used RES Automation Manager you can put them wherever needed 😉
Move the Files
Now that we’ve backed up the original self-signed certificate and copied the new files in they’ll need to be relocated. Move the files with the following commands:
mv /home/hyperdrive/localhost.crt /etc/pki/tls/certs/ mv /home/hyperdrive/ca-bundle.crt /etc/pki/tls/certs/ mv /home/hyperdrive/localhost.key /etc/pki/tls/private/
I don’t actually know what permissions are needed by RES HyperDrive but my assumption is that they probably need to mirror what was there before. Fix the permissions by running the following commands:
chmod 0644 /etc/pki/tls/certs/localhost.crt chmod 0644 /etc/pki/tls/certs/ca-bundle.crt chmod 0600 /etc/pki/tls/private/localhost.key
If you copied the files in via SSH/SCP then they will be owned by the hyperdrive account. To reset the file owner on the files back, run:
chown root:root /etc/pki/tls/certs/localhost.crt chown root:root /etc/pki/tls/certs/ca-bundle.crt chown root:root /etc/pki/tls/private/localhost.key
Restart the Web Server
Once the files have been replaced and updated, restart the web server by running the service httpd restart command and BINGO!
Pre-canned RES AM Building Blocks
If you have integrated RES HyperDrive with an existing RES Automation Manager installation (remember you get a complimentary RES AM license) I’ve included a building block (click the red brick to download) that will perform the required configuration for you. Note: remember to replace the localhost.crt, ca-bundle.crt and localhost.key files in the \virtualengine.co.uk\RES HyperDrive\ resources folder before running it!