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.
The process of requesting certificates for vSphere 5.1 is a fairly grim, manual process. It's repetitive and easy to make a mistake on any step of the way. Since I've got to do this for quite a few VirtualCenter Servers, I thought I'd script the certificate generation if nothing else. I am following the excellent documentation provided in Implementing CA signed SSL certificates with vSphere 5.1 and more specifically in Creating certificate requests and certificates for vCenter Server 5.1 components.
The script assumes that:
- You have a working Certificate Authority
- You are in an Active Directory domain environment
- You have the relevant permissions to modify Certificate Templates, Request and Issue certificates.
- You have installed OpenSSL v1.0.1c or later.
You will need to modify the configuration section to suit your environment and the $WorkingDir folder should exist before you run the script.