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.