Microsoft recently issued a security advisory and a patch that blocks any certificates with a key length less than 1024 bits. This has impacted a wide variety of systems including VMware Site Recovery Manager 5.0 and below. This article will provide you a way to quickly regenerate the self-signed SRM certificates.

Background

The Microsoft Advisory and related information can be found in Microsoft Support KB 2661254. I would encourage you to read this article as the impact is wider than just VMware SRM and other VMware products.

Although I’m going to show you a way of generating self-signed certificates here for the use with SRM I would recommend using trusted CA certificates if possible to reduce the risk of man in the middle attacks. However the effort required to set up a CA and issue the certificates is far more than what I’m about to explain. This is the quick way to work around this problem until you come up with a better solution, which may include getting CA issued certificates.

Note: This process is not officially supported by VMware and says as much in the output of the command. So use this at your own risk and I would encourage you to test it in an isolated environment prior to applying this to any production system. Always take a backup of existing certificates before making any modifications. These instructions should work for any versions of SRM 5.1 and prior.

Generate New Self Signed SSL Certificates for SRM

There is a file called CertGenUtil.exe that is shipped with SRM and used by the installer to create the default self-signed SSL certificates. The version included in 5.0 and prior only generates 512 bit keys, which are not sufficiently strong after you’ve applied the MS patch. The MS patch requires 1024 bit keys or higher. Fortunately the version of CertGenUtil.exe shipped with SRM 5.1 generates 2048 bit keys and can be used to re-generate the certificates for use with versions of SRM include 5.0 and prior. You may need to use this if you are upgrading from SRM 5.0 to 5.1 also as the certificates are not generally replaced during an upgrade process. I have not yet tested the upgrade process of SRM 5.0 to 5.1 to see if it’s any different to previous versions with regards to the update of the certificates.

To use CertGenUtil.exe you will need to create a short config XML file so that it will generate the SSL Certs Correctly. The following is an example:

<config>

<DR_CERT_SERVER>SRMSERVERIP</DR_CERT_SERVER>

<DR_CERT_ORG>YOURCO</DR_CERT_ORG>

<DR_CERT_ORG_UNIT>YOURORG</DR_CERT_ORG_UNIT>

</config>

Replace SRMSERVERIP with the IP Address of your SRM Server, YOURCO with your company and YOURORG with your OU. Save the config file in an easily accessible location on the server where you’ll install SRM 5.1, such as c:\ or c:\temp, in the example below I’ve saved the file as srm-certcfg.xml in c:\temp. Note: you only need to install SRM 5.1 to get the CertGenUtil.exe, you are not required to upgrade your environment to SRM 5.1. So it would pay to do this in a test environment with a SQL Express instance and a test VC.

By default the CertGentUtil.exe file is located in c:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

On a server installed with SRM 5.1 or that contains the SRM 5.1 CertGenUtil.exe file execute the following command:

c:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin\CertGenUtil.exe -cfg c:\temp\srm-certcfg.xml

You will notice this line appears immediately:

VMware internal use only. This program is intended for use only by the SRM installer.

Follow the on screen messages that are displayed.

Installing The New Self Signed SSL Certificates

After the certs are generated you need to install them in the trusted certs store of both SRM Server and also both of the vCenter Servers (Protected and Recovery Sites). This is as simple as logging into the systems as administrator coping the new Cert file across and double clicking it to install it in the cert store (Follow the wizard). You will need to go through SRM and do a ‘Modify’ install and use your new certs in .p12 format. You may need to restart the SRM Services on both SRM Servers before the new certificates will be loaded into memory.

Final Word

I hope this helps if you quickly need to regenerate the default self-signed SRM Certificates for 4.x and 5.x to be compliant with the new MS patch. I would recommend that you use CA signed certificates to improve security and reduce the risk of man in the middle attacks, so this should be viewed as a temporary measure. This should allow you to continue to run your existing systems till you are able to upgrade to SRM 5.1.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

VMware is in the process of working on the vSphere 5 edition of the Security Hardening Guide and will shortly make a public draft available for comment (I’ll let you know when it’s available). This will be great news to the many people who have been waiting patiently for it since the vSphere 5 release. A lot of work is going into making this edition of the Security Hardening Guide much more user friendly and easier to use and implement. Many of the locked down items will be the same as in 4.1, and of course some changes and enhancements too. Another difference this time around is there are now new implications and restrictions on functionality introduced by the recommendations due to changes at least one popular VMware vCenter Management Tool. This is where Site Recovery Manager (SRM) v5 comes into the picture.

This isn’t going to be a log article as I want your opinion and I have two Yes/No Polls for your to answer. SRM v5 introduced a lot of great new functionality, workflow improvements, more logical and useful dependency mappings and start-up orders, greater scale, greatly improved performance for recovery plans and recovery operations. The performance of recovery operations are now significantly faster to run than in the previous version. However to get that performance increase VMware has changed the mechanism used to change IP addresses and communicate with the Virtual Machines for some operations.

If you’re not sure what I’m talking about check out the vSphere 4.1 Hardening Guide and search for VMX30 or VIX.

This change is significant if you apply the security hardening recommendations. SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery. There are no other options available. You either use the VIX API and live with the security risks, or you don’t change the IP addresses on the VM’s during recovery.There is no option to use the old change of IP address mechanism that was slower but didn’t rely on the VIX API, which would have been a very good option to have in my opinion. This has already caused me design problems in a number of customer environments.

If you don’t have a need to disable the VIX API because your security policy and vSphere Hardening policy doesn’t really justify this level of security then the change to SRM is going to be no problem and in fact extremely beneficial for you. Thins will run much faster. If however you have strict security and hardening policies and some of the VM’s targeted for protection require the VIX API to be disabled, and need an IP address change during recovery, you will have a problem and need to deal with it. There are a number of potential ways to solve the problem, but none are very elegant or easy to implement.

So this leads me to the two polls. Do you have a policy to disable the VIX API, and will this cause you a problem with SRM that might force you not to use it? Please let me know and get as many of the people you know to respond to this survey. If I get enough responses I will send this feedback onto VMware to review. If nobody cares enough about it, I’ll forget it and move onto something else.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.