Requirements when using trusted certificates with VMware Site Recovery Manager or VMware Live Site Recovery

Products

• VMware Live Recovery

Issue/Introduction

If VMware Site Recovery Manager (SRM) was used in an environment where vCenter Server is using trusted certificates, SRM must also use trusted certificates. Issues with the SRM certificates can result in error messages:
 

Call for object certificate on Server SRM Server failed. Certificate subject names do not match for remote SRM extension and local SRM certificate.

incompatible certificate trust

Or

certificate does not have an SSL client purpose .

This article provides information on the requirements of the trusted certificates used by SRM.

 

IMPORTANT Public CAs stopped issuing SSL/TLS certificates that contain internal server names or reserved IP addresses in November 2015. CAs will revoke SSL/TLS certificates that contain internal server names or reserved IP addresses on 1st October 2016. To minimize future disruption, if SSL/TLS certificates were used that contain internal server names or reserved IP addresses, obtain new, compliant certificates from a private CA before 1st October 2016.

• For information about the deprecation of internal server names and reserved IP addresses, see https://cabforum.org/internal-names/.
• For information about how the deprecation of internal server names and reserved IP addresses affects VMware products, see Frequently asked questions about Public Certificate Authority certificates with Internal Server Names and VMware Products (339722).

Environment

VMware Live Site Recovery 9.x

VMware Site Recovery Manager 8.x

Resolution

If the installed SSL certificates were issued by a trusted certificate authority (CA) on the vCenter Servers that support SRM, the certificates used by SRM must meet the following criteria:

• The certificates used by the members of an SRM server pair (a protected site and a recovery site) must have a Subject Name value that is the same on both sites. The Subject Name is constructed from:
  • A Common Name (CN) attribute, whose value must be the same for both members of the pair. A string such as “SRM” is appropriate here.
  • An Organization (O) attribute, whose value must be the same as the value of this attribute in the supporting vCenter Server’s certificate.
  • An Organizational Unit (OU) attribute, whose value must be the same as the value of this attribute in the supporting vCenter Server’s certificate.
  • All OU values for vCenter and SRM certificates must match, this ensures it is compatible with the existing OUs in the environment.

Note: If additional fields was used in a SSL certificate such as C, S, or, L, these values must also match on both sides.

The combined length of the subject name cannot exceed 80 bytes. The Subject Name includes the values supplied for CN, O, and OU, as well as a description (such as “CN=”), for example, if it's entered “SRM”, “Example Corp.”, and “example.com” as the values for CN, O, and OU respectively, the actual Subject Name would look like this:

O=Example Corp/OU=example.com/CN=SRM

SRM requires that all of these attributes be present in the Subject Name. The certificate may include additional attributes in the Subject Name, but the set of included attributes and their values must be identical for both certificates. The number of bytes in this string is determined by the encoding of the characters. Because some characters might be encoded as more than one byte, verify the length of the encoded Subject Name by using the following command:

openssl.exe x509 -in path-to-certificate-in-PEM-format -subject

Note: This command works only if the SRM certificates are in the PKCS#12 format. If the certificates are not in the PEM format, run this command to verify the subject fields:

openssl.exe pkcs12 -in path-to-certificate-in-PEM-format -nokeys -password pass:<certificate password>
-clcerts | openssl x509 -noout -subject
 

If no openssl was installed in the system, customer can use openssl that ships with SRM located by in the bin folder in the SRM installation directory (C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin by default).

 

• For releases earlier than SRM 4.0, the certificate used by each member of an SRM server pair must include a “Subject Alternative Name” attribute whose value is the fully-qualified domain name of the vCenter Server that supports it. This value is different for each member of the SRM server pair. If an openssl CA was used, modify the openssl configuration file to include a line like the following:
  
  subjectAltName = DNS: vc1.example.com

If a Microsoft CA was used, see the Microsoft article 931351 for information on how to set the Subject Alternative Name.

• For SRM 4.0 and later, the certificate used by each member of an SRM server pair must include a “Subject Alternative Name” attribute whose value is the fully-qualified domain name of the SRM server host and IP entry. This value is different for each member of the SRM server pair. If an openssl CA was used, modify the openssl configuration file to include a line like the following:
  
  subjectAltName = DNS: SRM1.example.com,DNS: xx.xx.xx.xx,IP: yy.yy.yy.yy
  
  If a Microsoft CA was used, see the Microsoft article 931351 for information on how to set the Subject Alternative Name.
   
• The certificate used by each member of an SRM server pair must include an “Extended Key Usage” attribute whose value is “serverAuth, clientAuth”. If an openssl CA was used, modify the openssl configuration file to include a line like the following:
  
  extendedKeyUsage = serverAuth, clientAuth

Notes:

• The subjectAltName is case sensitive. The SSL certificate must have the same case for the hostname and domain as the host reports when running the hostname or ipconfig /all commands.
   
• For more information on certificates, see SRM Authentication in the vLSR Administration Guide.
   
• In SRM 4.x and later releases, the CN must be a Fully Qualified Domain Name (FQDN) to obtain signed certificates from third-party certificate providers.
   
• Certificates must have same signer for both vCenter Servers and for both SRMs.
   
• The installation works correctly even if the certificates are not setup correctly. However,it cannot pair the sites in situations like trusted certificates being used on the vCenter Server, but not for the vCenter Server where SRM is installed.There should report messages such as Local and Remote Servers are using different certificate trust methods. Similar message can be seen when the Subject Alternative Name attribute in the SRM Server Certificate is not setup correctly.