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!
Additionally you will need to be comfortable with Transferring Files to RES HyperDrive and probably Remotely Administering RES HyperDrive.
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/
Fixing Permissions
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!
[wpdm_file id=10]
Simon
!! Now as this file is embedded into the MSI, we 
?
). Interestingly those very same registry keys are present in HKCU!
.
I previously covered the reasons why you probably wouldn’t use RES Automation Manager for patch management (see 
..
) that RES Automation Manager could be utilised for this task. This post is not a best practice guide as to how to create, update or document your images, rather a use case on how and why we use/recommend RES Automation Manager. Heaven forbid, you might even decide to do away with Provisioning Services as a result. Either way RES Automation Manager will play very nicely with or without PVS but I couldn’t fit it into 140 characters!
assigned to the senior administrators.
s in and wait for the penny to drop!).
I will say that it should be a strategic decision to deploy RES Automation Manager. Don’t underestimate the amount of time it takes to automate and test. But I guess you already spend a lot of time testing your images?