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

Regenerating expired SSL certificates after 2 years in VMware vCenter Server 4.x / 5.0.x (1009092)

Last Updated: 3/20/2024Categories: TroubleshootingTotal Views: 17020Language:
Chinese (Simplified)JapaneseEnglish

2 like this article

Subscribe to get an email
newsletter with new updates

2 people found this helpful Please provide article feedback:

Symptoms

When trying to perform a discovery using the EMC Control Center application to vCenter Server, Error 39 appears.

The discovery process does not complete.

To regenerate certificate in vSphere 6.x see How to regenerate vSphere 6.x certificates using self-signed VMCA .

Resolution

For more information on upgrading to vCenter Server 5.1 or 5.5, see Implementing CA signed SSL certificates with vSphere 5.x (2034833). If you do not want to implement CA-signed SSL certificates in your environment, you can regenerate VMware default SSL Certificates during the upgrade using these steps before upgrading:

Log in to the vCenter Server system

Uninstall the current version of vCenter Server

Rename the C:\ProgramData\VMware\VMware VirtualCenter\SSL directory to SSL.old

Perform the upgrade process. This will re-generate new default certificates.

In this case, the SSL certificates are expired and the discovery process fails. There are two methods that can be used to update the SSL certificates.

Note: The SSL certificates have a lifespan of two or ten years depending on the version.

For VirtualCenter 2.5, the lifespan is two years

For vCenter Server 4.x and later, the lifespan is ten years

Method 1

With this method, it is possible to regenerate the certificates using OpenSSL. The existing rui.key file is used to accomplish this. This is the only method available if vCenter Server 4.0 is installed.

OpenSSL is a free utility that can be used to generate SSL certificates. It is available for download from http://www.openssl.org/. A version for Windows or Linux is available.

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

For special instructions on downloading the most recent version of OpenSSL (greater than version 0.9.8), see Issues viewing Storage Views, Performance Overview, and Hardware Status when OpenSSL 1.0.0 version or higher is used to create self-signed certificates (1025966).

Note: OpenSSL is pre-installed on ESX and can be used to complete these steps. It is not pre-installed on ESXi.

To regenerate an expired certificate:

Locate the rui.key file on the vCenter Server system.

Note: On versions of Windows prior to Windows Server 2008, this location is:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL

On Windows Server 2008, this location is:

C:\ProgramData\VMware\VMware VirtualCenter\SSL

Copy the existing rui.key to a system where OpenSSL is installed.

Create a new certificate and pfx file.

On Windows, run these commands:

openssl.exe req -new -x509 -days 3650 -sha1 -nodes -key rui.key -out rui.crt -subj "fqdn_of_VC"

Where fqdn_of_VC is the fully qualified host name of the vCenter Server system. If this command returns a subject that does not start with "/", use this command instead:

openssl.exe req -new -x509 -days 3650 -sha1 -nodes -key rui.key -out rui.crt -subj "/C=US/ST=CA/L=HAWTHORNE/CN=vcenter_name"

Where C = country(US) , ST = State (CA), L = City (HAWTHORNE), and CN = the name of the vCenter Server.

Note: It may be necessary to create an openssl.cnf file and add -config openssl.cnf to the command. For more information, see the Replacing vCenter Server Certificates Guide.

openssl.exe pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

On Linux or an ESXi/ESX host, run these commands:

openssl req -new -x509 -days 3650 -md5 -nodes -key rui.key -out rui.crt -subj 'fqdn_of_VC'

Where fqdn_of_VC is the fully qualified host name of the vCenter Server system.

openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Note: Ensure that you use the default password, testpassword, for self-signed certificates. Otherwise, edit the keystorepass attribute in the %PROGRAMFILES%\VMware\Infrastructure\tomcat\conf\server.xml file.

To edit the keystorepass attribute:

Open the %PROGRAMFILES%\VMware\Infrastructure\tomcat\conf\server.xml file in a text editor.

Search for <Connector port="8443"</code>. This line refers to the rui.pfx certificate file that changes when you update your certificate.

Set the keystorePass attribute to the rui.pfx certificate password. The password cannot be blank.

Stop the VMware VirtualCenter Server service. For more information, see Stopping, starting, or restarting vCenter services (1003895).

Copy the newly created rui.crt and rui.pfx files to the appropriate directory on the vCenter Server system (from step 1).

Start the VMware VirtualCenter Server service. For more information, see Stopping, starting, or restarting vCenter services (1003895).

Note: After replacing the certificates for vSphere 4.1/5.0, the database password may need to be re-encrypted, which may prevent vCenter Server from starting. To resolve this issue, see vCenter Server fails to start after replacing the default SSL certificates with custom SSL certificates (1003070).

Regenerating the vCenter Inventory Service and the vSphere Web Client certificates on vCenter Server 5.0.x

If you are running vCenter Server 5.0.x, you must also regenerate the certificate for the vCenter Inventory Service and the vSphere Web Client. To avoid conflicts between the different components' SSL certificates on the same server, VMware recommends creating each certificate with a different CN.

For example, this command regenerates certificates for the inventory service from its key:

openssl.exe req -new -x509 -days 3650 -sha1 -nodes -key rui.key -out rui.crt -subj "/C=US/ST=CA/L=HAWTHORNE/CN=WDC-WIN2K8_InventoryService"

By default, the SSL folder location for the Inventory service is:

Inventory_Service_Installation_location\Inventory Service\ssl

By default, the SSL folder location for the vSphere Web Client Client is:

vSphere_Web_Client_Installation_location\vSphere Web Client\DMServer\config\ssl

Additional notes on vSphere 4.1 / 5.0

The procedure for replacing SSL certificates has changed in vSphere 4.1. For more information, see Replacing vCenter Server 4.1 and 5.0 SSL certificates using the vpxd -p command fails with the error: failed to do early initialization (1030661).

In ESXi 4.1, you can create new self-signed certificates. For more information, see hostd fails to start with a Crypto Exception error (1021625).

In vCenter Server 4.1 and 5.0, the certificates must be reloaded to the Managed Object Browser (MOB). For more information, see:

vCenter Server 4.1: Replacing vCenter Server Certificates

vCenter Server 5.0: VMware vSphere Examples and Scenarios

Method 2 (for VirtualCenter 2.5)

With this method, a new VirtualCenter SSL certificate is generated via the installation/repair process. This method is only applicable to VirtualCenter Server 2.5, as vCenter Server 4.0 and 4.1 do not have a repair option available.

Note: For VirtualCenter 2.5 Update 2 and earlier, disconnect all ESX hosts. VirtualCenter 2.5 Update 3 and higher automatically disconnects the hosts.

To regenerate an expired certificate:

Stop the VMware VirtualCenter Server service. For more information, see Stopping, starting, or restarting vCenter services (1003895).

Browse to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL and remove these files (or move them to another folder):

rui.crt
rui.key
rui.pfx

Navigate to Control Panel > Add/Remove Programs and choose to run a Repair on the VirtualCenter Server installation.

Caution: Ensure you do not choose to initialize the database.

After the repair is complete, there are three new rui files created in:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL

Start the VMware VirtualCenter Server service. For more information, see Stopping, starting, or restarting vCenter services (1003895).

Use the VMware Infrastructure Client to connect to vCenter Server. The ESXi hosts appear in a disconnected state. This is expected because vpxd.exe cannot decrypt the vpxuser password stored in the database using the current SSL certificates.

Manually reconnect all hosts.

Related Information

Notes:

Use the recommended 2048-bit length for RSA keys for vCenter server 5.0. For more information, see Replacing Default vCenter Server 5.0 and ESXi Certificates.

Click Hosts & Clusters or cluster view, click the Hosts tab, select multiple servers (or all servers) and then choose to connect. You are prompted for the root name password for each ESXi host.

For more information if you are using VMware Site Recovery Manager, see Requirements when using trusted certificates with VMware Site Recovery Manager 1.0.x/4.0.x/4.1.x/5.x (1008390).

For information regarding certificates for SRM/VRMS, see Pairing VRMS server with vCenter Server fails with the error: Unacceptable signature algorithm: MD5withRSA (2013087).

vCenter Server fails to start after replacing the default SSL certificates with custom SSL certificates
How to stop, start, or restart vCenter Server services
Requirements when using trusted certificates with VMware Site Recovery Manager 1.0.x to 5.0.x
hostd fails to start with a Crypto Exception error
Issues viewing Storage Views, Performance Overview, and Hardware Status when OpenSSL 1.0.0 version or higher is used to create self-signed certificates
Replacing vCenter Server 4.1 and 5.0 SSL certificates using the vpxd -p command fails with the error: failed to do early initialization
Pairing VRMS server with vCenter Server fails with the error: Unacceptable signature algorithm: MD5withRSA
Configuring OpenSSL for installation and configuration of CA signed certificates in the vSphere environment
Implementing CA signed SSL certificates with vSphere 5.x
Configuring CA signed SSL certificates for VMware vCenter Single Sign-On in vSphere 5.1
2 年を超えた VMware vCenter Server 4.x / 5.0.x での期限切れ SSL 証明書の再生成
2 年后在 VMware vCenter Server 4.x/5.0.x 中重新生成已过期的 SSL 证书

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseEnglish

Attachments

Additional Resources

No results for undefined

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware VirtualCenter

VMware vCenter Server

VMware ESX Server

Related Versions:

VMware VirtualCenter 2.5.x

VMware vCenter Server 5.0.x

VMware vCenter Server 4.1.x

VMware vCenter Server 4.0.x

VMware ESX 4.0.x

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