Loading

×Sorry to interrupt
CSS Error

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

Skip to main content

My Subscriptions

Loading

Knowledge Base

Requirements when using trusted certificates with VMware Site Recovery Manager (1008390)

Last Updated: 9/29/2023Categories: InformationalTotal Views: 25701Language:
Chinese (Simplified)JapaneseEnglish

Subscribe to get an email
newsletter with new updates

Please provide article feedback:

Details

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).

Solution

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:

日本語: VMware Site Recovery Manager 1.0.x/4.0.x/4.1.x/5.x で信頼性のある証明書を使用するときの要件 (2077550)

简体中文: 在 VMware Site Recovery Manager 1.0.x/4.0.x/4.1.x/5.x 中使用受信任证书时的要求 (2087403)

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

Result 1 of 1

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware vCenter Site Recovery Manager

Related Versions:

Take Our Survey

Was this article helpful?

YES

NO

Copyright © 2005-2024 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries.

Terms of Use

Your California Privacy Rights

Privacy

Accessibility

Cookie Settings

Support Assistant