Generating and Installing CA Signed Certificates for VMware SRM 5.5

Written by

Published on 5/3/2014 - Read in about 5 min (887 words)

Published under Microsoft and VMware #ca #Certificate Services #Certificate Services #certificates #Security #Site Recovery Manager (SRM) #srm #VMWare

This article is now 9 years old! It is highly likely that this information is out of date and the author will have completely forgotten about it. Please take care when following any guidance to ensure you have up-to-date recommendations.

I’m fairly new to SRM, but even so this one seemed like a real head-scratcher! If you happen to be using CA signed certificates on your “protected site” vCenter and “recovery site” vCenter servers, when you come to linking the two SRM sites you encounter SSLHandShake errors – basically SRM assumes you want to use certificates for authentication because you’re using signed certificates. If you use the default self-signed certificates, SRM will default to using password authentication (see SRM Authentication). Where the process fails is during the “configure connection” stage, if either one of your vCenter servers does not have CA signed and the other does (throws an error that they are using different authentication methods) or that you are using self-signed certificates for either SRM installation (throws an error that the certificate or CA could not be trusted).

SRM server ‘vc-02.definit.local’ cannot do a pair operation. The reason is: Local and remote servers are using different authentication methods.

There are several assumptions/details about the environment I’m using for this process to work:

Microsoft Certificate Services is installed and the Certificate Authority (CA) is configured, and is trusted on all domain computers
A certificate template has been configured for VMware certificates (as per KB2062108). Mine is called VMware-SSL.
There are 2 vCenter Servers, VC-01 and VC-02
There are 2 SRM servers, SRM-01 and SRM-02
DNS is configured and resolving correctly – forward (A) and reverse (PTR) – for each server

Generate a certificate request using MMC

The first step is to generate a custom request from the Certificates snap-in on each SRM server. Open MMC and add the Certificates snap-in for the local computer.

Run through the wizard

Select the Active Directory enrolment policy – this just gets the CA and Certificate Template details from AD rather than having to manually enter it.

Select the Certificate Template you created (KB2062108) and click next. Expand the “Details” and click the properties button to open the certificate properties.

On the Subject tab, add a Common Name (CN). The CN must be identical on both servers, I suggest using “SRM”, but it can be anything you like so long as it’s the same for both. Then add an Alternative Name for DNS short name and FQDN (in my case, SRM-02 and SRM-02.definit.local), and also the SRM server’s IP address.

Select the Private Key tab and expand the “Key Options”. Check “Make private key exportable”. Expand “Select Hash Algorithm” and change it to sha512.

Finally, export the request file to the local hard drive – I saved mine as C:\SRM-02.req.

Submit the request using certreq.exe

The next step is to submit the request file to your CA using the certreq.exe tool using the following command:

certreq –submit SRM-02.req

You’re then prompted to select your CA

After this you’re prompted to save the certificate response – I saved my under c:\SRM-02.cer

Import the certificate

It’s important to import the certificate response to the machine certificate store in order to “pair” it with the private key that was generated with the request, so import the file into the Personal certificate store for the machine.

Check that you have the little key symbol, indicating that there’s a private key for this certificate. You can also use certeq to do this, but I do it via MMC to check the private key is there.

certreq –accept SRM-02.cer

Export the certificate

The certificate needs to be exported as a PKCS#12 format certificate, with the private key – but it’s important not to export the chain, just the certificate, as SRM will not accept a chain.

Back in MMC, right click the certificate and select Export…

Run through the wizard, making sure to select the option to export the private key

Uncheck all of the options for the PFX export, and then provide a strong password (but less than 32 characters) to secure the certificate.

Specify a file name and location and finish the wizard.

The last (but crucial) step is to rename the certificate from a .pfx file to a .p12 file:

move SRM-02.pfx SRM-02.p12

Reconfigure SRM

Run the SRM installer executable to reconfigure SRM with the new certificate. Select the “Modify” option.

Re-enter the credentials for your vCenter server, then at the Certificate selection screen selct to use a PKCS#12 certificate

Specify the file, and enter the password used earlier in the export process.

If it fails complaining that the FQDN does not match the IP address:

Failed to validate certificate
The host name (vc-02.definit.local) in the Subject Alternative Name of the provided certificate does not identically match the SRM host name (192.168.1.61)

Edit the extensions.xml file in C:\Program Files\VMware\VMware vCenter Site Recovery Manger\config\ and replace the IP (SRM host name) with the FQDN (in the Subject Alternative Name) – I did a search/replace.

Next, import the configuration XML using the following command:

cd C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin
srm-config.exe -cmd updateext -cfg ..\config\vmware-dr.xml -extcfg ..\config\extension.xml
net stop vmware-dr && net start vmware-dr

Try again to import the p12 certificate, and you can carry on through the wizard