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
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
Enter the database user and password again, and select to use the existing database
Once this is completed on both SRM servers I was then able to successfully establish the connection between the SRM servers: