Requirements when using trusted certificates with VMware Site Recovery Manager

Products

VMware Live Recovery

Issue/Introduction

If you are using VMware Site Recovery Manager (SRM) 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 you use SSL/TLS certificates 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 (2134735).

Resolution

If you have installed SSL certificates issued by a trusted certificate authority (CA) on the vCenter Servers that support SRM, the certificates you create for use 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 you are using additional fields 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 you supplied for CN, O, and OU, as well as a description (such as “CN=”), for example, if you 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. Your 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 customer does not have openssl installed, they 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 you are using an openssl CA, modify the openssl configuration file to include a line like the following:

subjectAltName = DNS: vc1.example.com

If you are using a Microsoft CA, see the Microsoft article 931351 for information on how to set the Subject Alternative Name.

Note: The preceding link was correct as of April 24, 2014. If you find the link is broken, provide feedback and a VMware employee will update the link.

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 you are using an openssl CA, modify the openssl configuration file to include a line like the following:

subjectAltName = DNS: SRM1.example.com,DNS: 192.168.0.100,IP: 192.168.0.100

If you are using a Microsoft CA, 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 you are using an openssl CA, 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 Site Recovery Manager Administration Guide.
If you are upgrading SRM 1.x to SRM 4.x and using certificate-based authentication, see the Release Notes for specific upgrade requirements. For more information about using trusted certificates with SRM, see How to use trusted certificates with VMware vCenter Site Recovery Manager.
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, you 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. You see 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.

For more information, see the VMware Communities article How to use trusted certificates with VMware vCenter Site Recovery Manager.

Additional Information

For translated versions of this article, see: