Apr 30

Windows 8 / Windows Server 2012 Operating System does not boot or install on ESXi or ESX (2006859)

Windows 8 / Windows Server 2012 Operating System does not boot or install on ESXi or ESX (2006859)

Symptoms

  • Windows 8 / Windows Server 2012 fails to boot or install on any version of ESXi or ESX
  • Windows 8 / Windows Server 2012 is not working
  • You cannot use Windows 8 / Windows Server 2012 in ESXi or ESX

Purpose

This article provides information on using Windows 8 / Windows Server 2012 in a vSphere environment.

Resolution

Note: Windows 8 / Windows Server 2012 is not supported on ESXi/ESX 4.0 or 4.1.

Windows 8 / Windows Server 2012 is fully supported for ESXi 5.5/5.1 and ESXi 5.0 Update 1, ESXi 5.0 Update 2 and ESXi 5.0 Update 3.

Note: For Windows Server 2012, you must install the patch ESXi500-201209001(Patch 04) on ESXi 5.0 Update 1. For more information, see VMware ESXi 5.0, Patch Release ESXi500-201209001 (2032584) and Upgrading to vCenter Server 5.0 best practices (2003866). After applying this patch, the ESXi build should display as 821926.
 
For more information, see:
Note:The information below relates only to pre-release versions of Windows 8 / Windows Server 2012. For complete support, install the GA version.
 
Consider this guidance, which is based on testing Windows 8 / Windows Server 2012 up to build 8224:
  • Windows 8 Developer Preview / Windows Server 2012 Release Candidate does not boot on ESXi 5.0. To resolve this issue, you must install patch ESXi500-201112001 (Patch 02):
    1. Download and install ESXi500-201112001 (Patch 02). For more information, see VMware ESXi 5.0, Patch Release ESXi500-201112001 (2007680).
    2. Create a new virtual machine configured for either Windows 7 or Windows 2008 R2.
    3. Enable 3D graphics or do not install VMware’s WDDM video driver.
    4. Install Windows 8 / Windows Server 2012 from Media.
    5. Install VMware Tools.

      Note: VMware does not recommend installing VMware’s WDDM video driver. Use the default VESA driver.

  • If you experience a black screen after installing VMware’s WDDM video driver in a virtual machine with Windows 8 / Windows Server 2012, enable 3D graphics or reinstall the operating system and VMware Tools without VMware’s WDDM video driver.
  • VMware does not currently recommend using USB xHCI with Windows 8 / Windows Server 2012. To work around this issue, remove the USB xHCI controller or use the USB EHCI+UHCI controller.

    Note: Any changes to the virtual hardware must be preceded by a full shutdown on the command line (shutdown /s /t 0). Otherwise, the Windows 8 / Windows Server 2012 hibernate-shutdown may not fully detect hardware changes and you may experience a blue diagnostic screen or triple fault at boot.

  • The vmxnet3 virtual NIC is supported in a Windows 8 / Windows Server 2012 virtual machine with ESXi 5.0 Update 1, ESXi 5.0 Update 2 and ESXi 5.1. For more information, see the VMware Guest OS Compatibility List.

Additional Information

To be alerted when this article is updated, click Subscribe to Document in the Actions box.

For further information on supported Guest Operating systems, see the Hardware, Host Operating System, and Guest Operating System Compatibility Guides.

For further information, see Windows 8 Release Preview and Windows Server 2012 Release To Manufacturing (RTM) / Release Candidate fail when starting for the first time after the installation (2021887).

See Also

Mar 09

Deploying and using the SSL Certificate Automation Tool 1.0.x (2041600)

About the SSL Certificate Automation Tool

With the underlying architectural changes in vCenter Server 5.1, multiple certificates are needed for various components to securely interact with one another. For those customers who need to install custom certificates, this has meant spending additional time generating and installing certificates for each component.

The SSL Certificate Automation Tool is a command-line utility that automates the Self- or CA-signed certificate renewal process. Of particular significance is the Update Steps Planner, which allows you to plan the sequence of certificate updates for the components. This prevents errors in the process that might otherwise occur. Note that the tool does not generate custom certificates for you; you are expected to generate these certificates offline following the instructions in this document. Afterward, the rest of the document describes the certificate tool functions and features.

Prior to the SSL Certificate Automation Tool, version 1.0.1, all certificate requests and certificates had to be created manually. As of version 1.0.1, the tool automates the creation of certificate requests. It does not automate the submission of the certificate requests to a CA. For instructions on generating supported certificate requests and certificates for the vCenter services, see  Generating certificates for use with the VMware SSL Certificate Automation Tool (2044696).

Supported platforms

The SSL Certificate Automation Tool is only available to machines running Windows operating systems. The tool has been tested and verified on these Windows versions:

  • Windows 2003 R2 SP2
  • Windows 2008 R2 SP1
  • Windows 2012 Standard

Compatibility

The SSL Certificate Automation Tool 1.0 and 1.0.1 works with your vSphere 5.1 environment only.

  • SSL Certificate Automation Tool 1.0 is supported with vSphere 5.1
  • SSL Certificate Automation Tool 1.0.1 is supported with vSphere 5.1 Update 1 and later, excluding vSphere 5.5
  • SSL Certificate Automation Tool 5.5 is supported with vSphere 5.5

If you need to replace the certificates on a vSphere 5.5 environment, see Deploying and using the SSL Certificate Automation Tool 5.5 (2057340) .

Prerequisites

To run the SSL Certificate Automation Tool, you must have:

  • Administrative privileges on the server(s) you are running the tool on. Although non-administrator users can download and launch the tool, all operations will fail without the proper permissions.
  • Access to each server that has vSphere components for which the SSL certificate will be updated.
  • All vCenter Server components which will have their certificates updated have already been installed and are running.
  • The new certificates already exist and you know the location of the new certificates. For increased security, generate each certificate and private key on the machine where it will be used. The new SSL certificate for each vSphere component must have a unique base distinguished name (DN).

Certificate Requirements

You can obtain the CA-signed certificates before you run the tool, or you can have the tool generate the certificate requests for you. Before you run the tool to replace certificates, ensure that the new SSL certificate for each vSphere component has a unique Subject Distinguished Name encoded within the certificate.

Note : A unique organizational unit (OU) is not mandatory. The OU is only a part of the DN. Having a unique OU is one way to achieve unique DN, but is certainly not the only way.

The certificates and private keys must meet these requirements:

  • Private key algorithm: RSA
  • Private key length: >= 1024
  • Private key standard: PKCS#1 or PKCS#8
  • Private key storage: PEM

Recommended certificate signature algorithm are:

  • sha256WithRSAEncryption 1.2.840.113549.1.1.11
  • sha384WithRSAEncryption 1.2.840.113549.1.1.12
  • sha512WithRSAEncryption 1.2.840.113549.1.1.13

The certificate chain format must meet these requirements:

  • Single PEM file that contains a sequence of PEM (base64) encoded X.509 certificates ordered from the leaf certificate to and including the self-signed authority certificate.
  • The file should not contain any comments, spaces and tabs, before, between and after certificates.
  • Each certificate begins with -----BEGIN CERTIFICATE------ and ends with -----END CERTIFICATE------, each on a new line with no spaces before or after, respectfully.
  • No extra certificates are in the file.
  • The certificate chain is complete. That is, either the file contains all certificates forming the chain or the certificate chain is incomplete but can be completed using certificates from the Windows trust store.

The path or file name for certificates and keys does not contain any of these special characters:

  • ^ (caret)
  • % (percent)
  • & (ampersand)
  • ; (semicolon)
  • ) (closing parenthesis)

Note : The tool exits or reports an error if it encounters any of these special characters.

Solution

Before you begin

Consider this information before beginning your certificate updates:

  • If you are running the vCenter Server services in a virtual machine, take a snapshot of the virtual machine before starting the process to expedite recovery times in case of failure. Be sure to also remove the snapshot once the process is successful.
  • Updating certificates for third-party components such as load balancers and on non-Window OS machines must be done manually.
  • Any character input containing the ^ (caret) character are not allowed.
  • If the path or file name of the tool or new certificates contain any of the special characters ^ (caret), % (percent), & (ampersand), ; (semicolon), or ) (closing bracket), the tool will fail and either exit, throw an exception, or report that certificate or key files are not found.
  • Shut down any dependent solutions which are running in the environment to prevent failures of these services. The solutions which must be shut down while updating the certificates are:
    • VMware Site Recovery Manager
    • vSphere Data Recovery
    • vCloud Director
    • Any third-party solution which may be connecting to vCenter Server
  • Be sure to review the Known issues section of this article.

Installing or upgrading the SSL Certificate Automation Tool

You must install and deploy the SSL Certificate Automation Tool on each machine on which a vSphere component resides. However, you can use the tool on a single machine to do the initial planning.

There are three possible configurations for installing the SSL Certificate Automation Tool:

  • Single virtual machine (all services in one machine): All services are located on the same virtual machine. In this case, the SSL Certificate Automation Tool must be deployed on one virtual machine.
  • Multiple virtual machines (machine per service): Each service is located on a different virtual machine. In this case, the SSL Certificate Automation Tool must be deployed on each virtual machine running one of the seven services.
  • Mixed mode (multiple services per machine): Some services are run on one virtual machine but others run on a different virtual machine. In this case, the SSL Certificate Automation Tool must be deployed on all the machines which have services that are to be updated, and machines where there are deployed services which are communicating with the ones that are to be updated. Use the Update Steps Planner to determine the exact order of the steps for deployment.

To install the SSL Certificate Automation Tool:

Important: Ensure that the installation path for the SSL Certificate Automation tool does not contain any spaces.

  1. Download the SSL Certificate Automation Tool. This download is located in the Drivers and Tools section of the vSphere and vCloud Suite download pages.
  2. Copy the tool to each machine on which a vSphere component resides.
  3. Use an unzipping utility to unzip the file into any directory, preserving the directory structure.

To upgrade the SSL Certificate Automation Tool from a previous version:

Important: Ensure that the installation path for the SSL Certificate Automation tool does not contain any spaces.

  1. Download the SSL Certificate Automation Tool. This download is located in the Drivers and Tools section of the vSphere and vCloud Suite download pages.
  2. Copy the tool to each machine on which a vSphere component resides.
  3. Use an unzipping utility to unzip the file into a different directory than the previous version of the tool was using, preserving the directory structure.Note: Upgrading to a newer version of the SSL Certificate Automation Tool is simple because no installation is required. VMware also recommends removing the older version of the tool to avoid confusion. To remove the older version, simply delete the folder where the older tool resides.

Using the SSL Certificate Automation Tool

After the tool is installed, it is ready to start the process of updating certificates. Before beginning, however, it is possible to predefine default values to partially automate the process. Although it is not required, this can help avoid errors in the subsequent configuration steps. If you are not predefining the default values, proceed to the Running the Update Steps Planner section below.

Predefining default values

Predefining the default values in the tool helps prevent typing errors and save time. This lets the tool automatically include specific information that you have defined as the default instead of prompting you for it. For security reasons, only passwords cannot be saved when defining default values.

To predefine default values:

  1. Open the ssl-environment.bat file in a text editor, such as Notepad.
  2. For each relevant component you want to update, enter the required parameters and the option parameters you want to change. For example, for vCenter Server you can edit the vc_cert_chain, vc_private_key, and vc_username parameters.When you include the information in the ssl-environment.bat file, the SSL Certificate Automation Tool saves this information and uses it to automatically pre-fill required input during certificate updates, trust updates, and rollback operations.
  3. After you have entered all the information, save and close the ssl-environment.bat file.
  4. To apply the default values, run the ssl-environment.bat file from the command line.Note: The values created by ssl-environment.bat file are read only when the tool starts up. If you run the ssl-environment.bat file while the SSL Certificate Automation Tool is running, the values are not read.

After completing these steps, proceed to the Running the Update Steps Planner section.

Running the Update Steps Planner

The Update Steps Planner is an option which allows you to determine the order in which you should proceed to properly update the SSL configuration. VMware recommends that you follow the steps presented in the Update Steps Planner exactly as they are presented to ensure that the configuration is properly updated.

To run the Update Steps Planner:

  1. Log into any machine on which the SSL Certificate Automation Tool is installed.
  2. From a command line, navigate to the location into which you unzipped the tool and run the command:ssl-updater.bat
  3. At the main menu, choose 1. Plan your steps to update SSL certificates to determine the steps needed to update the SSL certificates.
  4. Enter the numbers representing the services to update.To update more than one SSL certificate, separate the numbers with a comma. For example, to update the SSL certificates on Single Sign-On, vCenter Server, and the vSphere Web Client, type:1,3,4To update the certificate on all services that are supported by the tool, type 8. The menu selections show all of the supported services.Note: The vSphere Web Client and the Log Browser reside on the same machine.
  5. The Update Steps Planner shows what you need to do and the order in which to do it. Perform the tasks in the order the Planner presents.Important: When using the Update Steps Planner, enter all of the services you will update. If you enter the services separately, the Planner cannot correctly determine the order of the steps. Performing the steps in the incorrect order can cause the update process to fail. To ensure that you have the order correct, leave the console open to the full list of steps or save the list to a text file. This allows you to track your progress.This image shows an example session when using the Update Steps Planner:
  6. After making a copy the output, type 9 to return to the main menu.

After completing these steps, proceed to the Updating SSL certificates and trusts section.

Generating Certificate Requests

Version 1.0.1 of the SSL Certificate Automation Tool introduces new functionality to help in the creation of certificate requests. This functionality helps prevent common configuration issues when generating supported certificates for use with the vCenter Server services.

For instructions on using the new certificate request functionality and generating supported certificates for the vCenter Server services, see   Generating certificates for use with the VMware SSL Certificate Automation Tool (2044696).

Updating SSL certificates and trusts

The Update Steps Planner shows the exact steps which must be followed (given the services selected) to ensure successful completion. To simplify the process as much as possible, the services are listed individually in the main menu with the trust and certificate update options for each specific service.

For example, to update the Inventory Service configuration, choose Inventory Service from the menu. You are then prompted to Update the Inventory Service Trust to Single Sign-On, and Update the Inventory Service SSL Certificate options in this menu.

In general, you must run these commands one after another, and as such the workflow is as simple as possible given the steps required to ensure a successful certificate implementation.

Note: The Ctrl+C option to cancel the current command does not work while running the tool.

After you select an option, type the information requested at the appropriate prompts, such as the locations of the new SSL chain and private key, passwords, and so on. When complete, the operation proceeds and either a success message is presented or an error explaining the problem which occurred. For more information on troubleshooting failures, see the Troubleshooting section of this article.

After a step is successful, proceed to the next step as described in the Update Steps Planner. You might need to navigate to a different machine to continue the process. If this is necessary, deploy and start the tool on the applicable machine.

Note: Keep the tool running on each machine to save time and to avoid re-entering input because the Update Steps Planner might require that you return to that machine for a later step.

After all of the steps provided by the Update Steps Planner are complete, you have successfully updated your certificates. Proceed to the Exiting the SSL Certificate Automation Tool section.

Exiting the SSL Certificate Automation Tool

After you have completed your update plan, you can select the appropriate menu options to exit from the tool. Closing the command prompt window will also abort the current session, and any incomplete or in-process actions will be lost.

Note: The Ctrl+C option to cancel the current command does not work while running the tool. You must either close the window and launch the tool again or enter invalid data to force a failure.

Troubleshooting

If a specific update command fails, there are several options which you can use to troubleshoot. You can also refer to the Known issues section of this article.

Rollback

The SSL Certificate Automation Tool has built-in rollback functionality. During the update operation, each action taken backs up the original state that the service configuration was in. If for any reason the update is not successful, you might need to roll back the failed step.

For each service there is an option to rollback the configuration. Run this command to restore the state of the configuration that was in place before beginning the update process. The SSL Certificate Automation Tool automatically saves a copy of the existing certificate configuration in a backup folder, ensuring that you can roll back to the previously used certificate to keep the entire system up and running.

The SSL Certificate Automation Tool log

To determine the cause of a failure, updates and actions are logged for each command, which makes it simple to verify what has been done. By default, the logs are kept in the /log directory in the directory that the SSL Certificate Automation Tool has been installed into. If your corporate policy or environment requires it, you can change the log folder before starting the tool. Set the default log directory using the LOGS_FOLDER variable in the ssl-environment.bat file.

To review the log:

  1. Open the /log directory.
  2. Locate the log for the action you want to verify. For example, the sso-update-ssl.log file. If there are multiple logs for the same action, use the log file date and time to determine the correct log file to use.
  3. Open the log file with any text editor and search for the error during the execution.

After you have identified the issue by searching the log file, correct the problem and execute the failed step again.

Known issues

This section lists known issues when using the SSL Certificate Automation Tool. Ensure that you review this list of known issues to determine if your environment may be affected:

  • vCenter Single Sign-On Password cannot contain spacesIf the Single Sign-On password has a space in it, the configuration of the Inventory service will fail. The only workaround for this issue is to use a Single Sign-On password without a space in it.Note: A previously known issue with the Single Sign-On password and special characters may present itself when replacing vSphere certificates. For more information about the special characters, see vSphere 5.1 Single Sign On (SSO) installation fails with error: Error 29133. Administrator login error. (2035820).
  • Registering vSphere Update Manager fails if using a Fully Qualified Domain Name (FQDN)Registering vSphere Update Manager to vCenter Server with the Fully Qualified Domain Name in vCenter Server 5.1 EP1/P01 is not supported. To prevent failures, use the IP address to register to vCenter Server instead. This issue is resolved in vCenter Server 5.1 Update 1.
  • vCenter Orchestrator may fail to connect when using multiple vCenter ServersWhen updating certificates, be sure to update the vCenter Orchestrator to vCenter Trust for each vCenter Server which is used with vCenter Orchestrator.
  • vCenter Server to Single Sign-On Trust operation fails causing the tool to exit abruptlyIn this release, if there are spaces in the path used for the certificates, the vCenter Server to Single Sign-On Trust update operation will fail causing the tool to abruptly exit. To work around this issue, ensure that the path does not contain spaces.
  • Rollback may fail if the backup directory is changedIf the backup directory used for previous SSL certificate update operations is changed in the ssl-environment.bat file, rollback will fail unless the original directory is reset before attempting rollback.
  • vCenter Server will not start if an incorrect database password is enteredWhen updating the vCenter Server certificate, the database password is requested so that it can be encrypted with the new certificate. Enter the password carefully because the SSL Certificate Automation Tool does not check the validity of the password.If the password is entered incorrectly, vCenter Server will not start. To resolve this issue, navigate to the vCenter Server installation directory and run this command from the command line to reset the password:vpxd.exe -p
  • Log Browser may fail after vCenter Single Sign-On certificate is updatedAfter installing and updating the certificate for vCenter Single Sign-On, the Log Browser may fail with an Unauthorized Access message. To resolve this issue, run the Update Log Browser trust to Single Sign-On command. This only occurs if updating the certificates one service at a time, in a one-by-one replacement procedure.
  • Updating the vCenter Server Certificate may fail with an error if multiple service IDs exist for the lookup serviceWhen updating the certificate for vCenter Server using the SSL Certificate Automation Tool, the step may fail with the error:The certificates that’s provided as input may not be a unique certificateThis may be caused by vpxd having multiple service IDs for the Lookup service in the vpxd.cfg file.
  • Previously upgraded vCenter Server installations which have replaced certificates may need manual interventionIf your installation of vCenter Server has been upgraded from a previous release, you may need to perform some steps prior to running the SSL Certificate Automation Tool. For more information, see Validating and correcting errors for an upgraded vCenter Server using the SSL Certificate Automation Tool (2048202).
  • vSphere Web Client reports the error: Failed to verify the SSL certificateAfter running the SSL Certificate Automation Tool, the vSphere Web Client may report the error:Failed to verify the SSL certificate for one or more vCenter Server SystemsTo resolve this issue, see vSphere 5.1 Web Client reports this SSL warning after an installation or upgrade: Failed to verify the SSL certificate for one or more vCenter Server Systems (2036505).
  • Error reported when the path to the certificate chains is incorrectWhen the path to the certificate chains is incorrect, you see the error:Exception in thread “main” java.io.FileNotFoundException: C:\certs\wrongfile\rui.crt (The system cannot find the file specified)
    at java.io.FileInputStream.open(Native Method)
    at java.io.FileInputStream.<init>(Unknown Source)
    ….This is expected behavior. Correct the path to the chain file and run the step again.
  • One-by-One Installation of inventory service fails when using 4096-bit certificatesIf you are performing a one-by-one service installation with 4096-bit certificates, installation of the Inventory Service freezes. To use 4096-bit certificates, do not use a one-by-one installation. Install all components and then update the certificates for the components. This is a known issue.
  • Client Not authenticated error when connecting to VMware Inventory service in Linked Mode ConfigurationsWhen updating all certificates while running in a Linked mode configuration, logins may fail to the inventory service for 10 minutes after the certificates have been updated. After this time, authentication is successful and functionality is restored.
  • SSL Certificate Automation Tool may fail if custom ports are used for componentsIf custom ports are used for the installation of vCenter Server services, configuration of certificates with the SSL Certificate Automation Tool may fail. This is a known issue. To work around this issue, use the default ports.
  • After replacing the vCenter Server certificate, collection from vCenter Operations Manager no longer works.When updating certificates, this will break the trust with vCenter Operations Manager and will prevent data collection. To resolve this issue, see When attempting to access VMware vCenter Operations Manager 5.x, an error is displayed: Not Authorized (2041162).
  • If the Managed Object Browser of the vCenter Server has been disabled per the VMWare vSphere Hardening Guide, this causes the vCenter Server SSL Certificate Update process to fail.

    While upgrading, the Automation Tool reports the error:[Tue 01/28/2014 – 11:07:13.83]: Validating the input parameters…
    STATE : 4 RUNNING
    HTTPError: Unable to open or read page.
    HTTP Error 503: Service Unavailable
    [Tue 01/28/2014 – 11:07:14.77]: “Cannot log in to vCenter.”
    [Tue 01/28/2014 – 11:07:14.78]: The vCenter certificate update failed. 
    To resolve this issue, see vCenter Server Managed Object Browser (MOB) reports a 503 Service Unavailable error (2042554).
Mar 09

Generating certificates for use with the VMware SSL Certificate Automation Tool (2044696)

Purpose

This article provides information on configuring Certificate Authority (CA) signed SSL certificates for use with the SSL Certificate Automation Tool. The tool helps eliminate common causes for problems with the creation of the certificates, including configuration steps and details, and helps avoid common configuration issues which cause failures while implementing custom certificates with the tool.Note: This article is specifically for vSphere 5.1 and vSphere 5.5 when using the SSL Certificate Automation Tool.

Resolution

Creating CA signed certificates for vSphere is a complex task. Therefore, VMware has worked to simplify the process by creating a tool to help automate the process. Before you can run the tool, however, you must have correctly created certificates to be able to utilize the tool. This article provides the steps to create the appropriate certificates. The steps are:

Remember that each component of the vCenter Server configuration requires its own certificate. Before attempting these steps, ensure that:

  • You have a vSphere 5.1 or vSphere 5.5 environment.
  • The environment has been pre-installed for all components for which you will be installing certificates.

Creating Certificate Requests

There are seven separate components in vCenter Server 5.1 and 5.5 that utilize certificates to encrypt communication. This article can be used if the components are on the same server and if they are on different servers, as long as you have a separate certificate for each component.

As of the SSL Certificate Automation tool version 1.0.1, the certificate requests can be created directly from the tool, automating many manual steps. For more details on manually creating the requests rather than generating them from the tool, see the Additional Information section of this article.

When creating the requests, the SSL Certificate Automation Tool ensures that by default the requests have the proper uniqueness. The requirements for the certificate requests are that they:

  • Have the subject alternative name field included in them.
  • Have unique Subject Distinguished Name (DN) for the certificate. The SSL Certificate Automation tool uses OrganizationalUnitNames for the components to achieve this uniqueness.
  • Include digitalSignature, keyEncipherment, and dataEncipherment components for Key Usage.

To generate the certificate requests:

  1. From the SSL Certificate Automation tool, select Option 2 to Generate Certificate Requests.Note: VMware recommends that the certificate request (and consequently the private key) are generated on the system which is being used for the service.
  2. Select the option for the service you are generating the certificate request for.
  3. Enter the information requested for the certificate request. By default the SSL Certificate Automation tool automatically populates much of the information required. The following is a description of the information requested:
    1. DNS Name – the fully qualified domain name of the server. For example: server.domain.com
    2. IP address – the IP address of the server. For example: 10.0.0.10
    3. Short name – the short hostname of the server. For example: server
    4. Country – the two digit country code. For example: US
    5. State or Province – The state or province for the certificate. For example: California
    6. City or Locality – The city for the certificate. For example: Palo Alto
    7. Organization – The name of the organization for the certificate. For example: VMware
    8. Organizational Unit name – The organizational unit name for the certificate. By default VMware specifies a default value of <service-servername> and uses it to ensure that the DN of the certificate is unique. Do not change this unless there is another field which makes the DN of the certificate unique.Note: Unique DNs are a hard requirement for vSphere 5.1. vCenter Single Sign-On uses the certificates to ensure that communication details are secure.
    9. Enter the directory where the CSR will be saved. By default, the CSRs and KEYs are saved in the SSL-TOOL-DIRECTORY\Requests directory.Important: Ensure that the directory in which the SSL Certificate Automation Tool is extracted and the specified CSR directory above do not have spaces in the names or CSR Generation will fail.
    10. Repeat steps 2 and 3 for each service which you are generating a certificate for.
This is a sample configuration for vCenter Single Sign-On:
After completing this section, you now have the rui.csr and rui.key files located in each of the respective directories as specified for the different services.
Important:  When generating a certificate request, the private key (rui.key) is also generated.  The private key is the sensitive data for the certificate, and as such VMware recommends that you generate each certificate request, and consequently the private key, on the system which it is to be used.
To validate that the CSR is created properly, run the command:C:\OpenSSL-Win32\bin>openssl req -in <File path to created certificates>\rui.csr -noout -text
 
Note: The above uses the default path to the OpenSSL tool.  If another path was used please substitute.

Alternatively, in a Windows Server on which vCenter Server is installed, run this command from the command prompt:
C:\Program Files\VMware\Infrastructure\Inventory Service\bin\openssl.exe req -in rui.csr -noout -text

After running the command, verify the output to ensure that all of the parameters entered in the tool are properly set.
Note:  The SSL Certificate Automation tool uses RFC standard formatting for the CSR.  As a result the Subject Alternate name uses IP: syntax for the IP address. This prevents issues with certificate verification during operation of the product, however does not suppress the certificate warming when navigating to the IP address of the service from the vSphere Client and the Internet Explorer Browser.  This is an issue with how certificates are recognized in the Microsoft Certificate Store. Ignore the error, or navigate to the Fully Qualified Domain name to avoid the error.Proceed to the Obtaining the certificate section to obtain the certificate.

Obtaining the Certificate

After the certificate request is created, it must be given to the certificate authority for generation of the actual certificate. The authority presents a certificate back and a copy of their root certificate. For the certificate chain to be trusted, the root certificate must be installed on the server. Follow the appropriate section below for the steps for the certificate authority in question.

For Commercial CAs, to create each certificate request:

  1. Take the certificate request (rui.csr, as generated above) and send it to the authority in question.
  2. The authority sends back the generated certificate.

For Microsoft CAs, to create each certificate request:

Note: Based on the requirements of the key, ensure that the WebServer Template has been copied to allow for encryption of user data. This can be normally found in Certificate Manager > Extensions > Key Usage > Allow encryption of user data.

  1. Log into the Microsoft CA certificate authority Web interface. By default, it is http://servername/CertSrv/.
  2. Click the Request a certificate link.
  3. Click advanced certificate request.
  4. Click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file link.
  5. Open the certificate request in a plain text editor and paste the text from the Begin to the End request into the Saved Request box:-----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST-----

    Note: Do not copy the actual -----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST-----. Only copy the text in between these lines. You may see = (equal) signs near the Begin and End lines (for example, ==—–END). In this case, you must copy the = (equal) signs.
  6. Select the Certificate Template as the appropriate Web Server template. This is generally a copy of the Web Server Template with Allow encryption of user data setting set.
  7. Click Submit to submit the request.
  8. Click Base 64 encoded on the Certificate issued screen.
  9. Click the Download Certificate link.
  10. Save the certificate as rui.crt in the appropriate c:\certs\<service> folder.
  11. Repeat steps 2 to 10 for each additional service.
  12. Navigate back to the home page of the certificate server and click Download a CA certificate, certificate chain or CRL.
  13. Click the Base 64 option.
  14. Click the Download CA Certificate chain link.
  15. Save the certificate chain as cachain.p7b in the c:\certs folder.
  16. Double-click the cachain.p7b file and navigate to C:\certs\cachain.p7b > Certificates.
  17. Right-click the certificate listed and click All Tasks > Export.
  18. Click Next.
  19. Select Base-64 encoded X.509 (.CER), then click Next.
  20. Save the export to C:\certs\Root64.cer and click Next.Note: This assumes there are no intermediate certificates in the Certificate Authority. Before exporting the certificate into Base-64 encoded X.509 (.CER), if there are two or more levels in the Certificate Authorities and if you have multiple certificates on the .p7b file, you will not be able to export them to Base64 at the same time. You must export them one by one instead. For example, create files named C:\certs\Root64-1.cer, C:\certs\Root64-2.cer, etc.
  21. Click Finish.
To verify that all of the settings are correct, double-click the rui.crt file and validate that the proper alternative names and subjects are in each certificate. When complete, the certificates are generated and you now have the rui.crt file for each service and the Root64.cer root certificate.Note: If you have intermediate certificates, you should have a root64-#.cer file for each intermediate certificate all the way to the root certificate.
Install the root certificate into the Trusted Root Certificate Authorities > Local Computer certificate store on each Windows system which has a service installed or which will be used to connect a client to the services.  If you are using intermediate certificates you should install them into the Intermediate Certificate Authorities > Local Computer certificate store.
Note:  There should be no text before the —–BEGIN CERTIFICATE—– or after the —–END CERTIFICATE—– in the .crt, or .cer files.
After completing this section, proceed to the Creating the PEM files section.

Creating the PEM files

Once the certificates and keys are created, you must create a PEM certificate chain for each certificate. The chain must contain all certificates in the chain, in the order in which they lead to the root certification authority.

Note: If they are out of order, the validation of the certificate chain will fail.

To create the chain:

  1. Create a file called chain.pem, located in the folder for the service that you are creating the chain for.
  2. Open the rui.crt file in Notepad and copy the contents of the file into the chain.pem file for that service.
  3. Open the Root64.cer file in Notepad and paste the contents of the file into the chain.pem file right after the certificate section. Be sure that there is no whitespace in the file in between certificates.Note: Complete this action for each intermediate certificate authority as well.
  4. Once complete, the file looks similar to this example:Note: The certificates shown in this example are truncated for ease of reading with the text added to the right indicating the order in which the certificates should be pasted into the file. Do not copy this example or add the text to your .pem file. Ensure there are no spaces before or after any of the —–BEGIN CERTIFICATE—– or —–END CERTIFICATE—– lines.-----BEGIN CERTIFICATE-----
    MIIFxTCCBK2gAwIBAgIKYaLJSgAAAAAAITANBgkqhkiG9w0BAQUFADBGMRMwEQYK
    CZImiZPyLGQBGRYDbmV0MRYwFAYKCZImiZPyLGQBGRYGbW5uZXh0MRcwFQYDVQQD
    Ew5tbm5leHQtQUQtMS1DQTAeFw0xMzAyMDExNjAxMDNaFw0xNTAyMDExNjExMDNa <-----Certificate
    SMhYhbv3wr7XraAnsIaBYCeg+J7fKTFgjA8bTwC+dVTaOSXQuhnZfrOVxlfJ/Ydm
    NS7WBBBFd9V4FPyRDPER/QMVl+xyoaMGw0QKnslmq/JvID4FPd0/QD62RAsTntXI
    ATa+CS6MjloKFgRaGnKAAFPsrEeGjb2JgMOpIfbdx4KT3WkspsK3KPwFPoYza4ih
    4eT2HwhcUs4wo7X/XQd+CZjttoLsSyCk5tCmOGU6xLaE1s08R6sz9mM=
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
    K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
    GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Intermediate Certificate
    /Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
    TLqwbQm6tNyFB8c=
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
    K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
    GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Root Certificate
    /Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
    TLqwbQm6tNyFB8c=
    -----END CERTIFICATE-----
  5. Save and close the file.
  6. Repeat these steps for each service for which you are replacing the certificate.

After completing this procedure, you now have rui.key and chain.pem files for each service you are implementing custom certificates for. Copy these files to the appropriate server for use with the SSL Certificate Automation Tool.

Additional Information

As of Version 1.0.1 of the SSL Certificate Automation Tool, the certificate requests can be generated directly from the tool. If for some reason, you are not able to use the automated process in the tool, the manual steps can still be used as noted below.

Creating the OpenSSL configuration files manually

There are seven separate components in vCenter Server 5.1 that utilize certificates to encrypt communication. This article can be used if the components are on the same server and if they are on different servers, as long as you have a separate certificate for each component.
If generating certificates manually, the latest version of OpenSSL v0.9.8 must been downloaded from http://slproweb.com/products/Win32OpenSSL.html and has been installed in the default directory. This article assumes it has been installed in C:\OpenSSL-Win32. If it has been installed elsewhere, substitute the alternative location appropriately.Important: OpenSSL version 0.9.8 must be used.
The OpenSSL configuration when generating requests must:
  • Have the subject alternative name field included in them
  • Have unique OrganizationalUnitNames for the components
  • Include digitalSignature, keyEncipherment, and dataEncipherment components for Key Usage

On the system where you will be generating the certificates, create a folder in which you can store the certificates for the different components. These steps use the C:\certs folder as an example.

In the C:\certs folder, create seven other folders so that you can organize each of the certificates. These steps use these seven folders:

  • InventoryService
  • SSO
  • vCenter
  • WebClient
  • LogBrowser
  • UpdateManager
  • Orchestrator

After this is done, create OpenSSL configuration files for each service. Here is an example of a completed configuration file:

Note: Each SSL Certificate requires a unique Distinguished Name (DN). The examples in this article use the OrganizationalUnitName (OU) field to achieve this uniqueness, based on a configuration where all components are installed on the same server. If the services are all on separate servers, they have a unique DN by default.

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:vc51-1, IP:10.0.0.10, DNS:vc51-1.vmware.com

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NY
localityName = New York
0.organizationName = VMWare
organizationalUnitName = vCenterInventoryService
commonName = vc51-1.vmware.com

Note: The country name is always the two digit country code for the country.

The procedure below provides detailed step-by-step instructions for the creation of each of the unique requests if you want to implement custom certificates for all components. They include the detailed changes which are required to be made in each certificate file to achieve the uniqueness required.

Note: At least one subjectAltName should be in place for each server that matches the commonName field. You do not need to include the IP address as a subjectAltName if policies prohibit the use of it, but this configuration is recommended by VMware.

  1. For the Inventory Service, create a file in C:\certs\InventoryService called inventoryservice.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = vCenterInventoryService
    commonName = server.domain.com
  2. For vCenter Single Sign-On (SSO), create a file in C:\certs\SSO called sso.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = vCenterSSO
    commonName = server.domain.com
  3. For the VirtualCenter Server Service, create a file in C:\certs\vCenter called vcenter.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = vCenterServer
    commonName = server.domain.com
  4. For the vSphere Web Client, create a file in C:\certs\WebClient called webclient.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = vCenterWebClient
    commonName = server.domain.com
  5. For the VMware Log Browser, create a file in C:\certs\LogBrowser called LogBrowser.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = vCenterLogBrowser
    commonName = server.domain.com
  6. For vSphere Update Manager, create a file in C:\certs\UpdateManager called UpdateManager.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = VMwareUpdateManager
    commonName = server.domain.com
  7. For vCenter Orchestrator, create a file in C:\certs\Orchestrator called Orchestrator.cfg. Paste this text into the file, changing the elements in Red:[ req ]
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    [ v3_req ]
    basicConstraints = CA:FALSE
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:ServerShortName, IP:ServerIPAddress, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Company Name
    organizationalUnitName = VMwareOrchestrator
    commonName = server.domain.com

After completing this section, the OpenSSL configuration files are configured. Proceed to the Generating certificate requests section of this article.

Generating certificate requests manually

Once OpenSSL has been configured, you must generate a certificate request for each of the components.

To generate the certificate requests:

  1. Launch a command prompt and navigate to the OpenSSL directory. By default, this is C:\OpenSSL-Win32\bin.
  2. Run this command to create the Inventory Service certificate request and export the private key:openssl req -new -nodes -out c:\certs\InventoryService\rui.csr -keyout c:\certs\InventoryService\rui-orig.key -config c:\certs\InventoryService\inventoryservice.cfg
  3. Convert the key to be in the proper RSA format for the Inventory Service to use:openssl rsa -in c:\certs\InventoryService\rui-orig.key -out c:\certs\InventoryService\rui.key
  4. Run this command to create the vCenter SSO certificate request and export the private key:openssl req -new -nodes -out c:\certs\sso\rui.csr -keyout c:\certs\sso\rui-orig.key -config c:\certs\sso\sso.cfg
  5. Convert the key to be in the proper RSA format for vCenter Server SSO to use:openssl rsa -in c:\certs\sso\rui-orig.key -out c:\certs\sso\rui.key
  6. Run this command to create the vCenter Server Service certificate request and export the private key:openssl req -new -nodes -out c:\certs\vCenter\rui.csr -keyout c:\certs\vCenter\rui-orig.key -config c:\certs\vCenter\vcenter.cfg
  7. Convert the key to be in the proper RSA format for vCenter Server to use:openssl rsa -in c:\certs\vCenter\rui-orig.key -out c:\certs\vCenter\rui.key
  8. Run this command to create the vSphere Web Client certificate request and export the private key:openssl req -new -nodes -out c:\certs\WebClient\rui.csr -keyout c:\certs\WebClient\rui-orig.key -config c:\certs\WebClient\webclient.cfg
  9. Convert the key to be in the proper RSA format for the vSphere Web Client to use:openssl rsa -in c:\certs\WebClient\rui-orig.key -out c:\certs\WebClient\rui.key
  10. Run this command to create the vSphere Log Browser certificate request and export the private key:openssl req -new -nodes -out c:\certs\LogBrowser\rui.csr -keyout c:\certs\LogBrowser\rui-orig.key -config c:\certs\LogBrowser\logbrowser.cfg
  11. Convert the key to be in the proper RSA format for the Log Browser to use:openssl rsa -in c:\certs\LogBrowser\rui-orig.key -out c:\certs\LogBrowser\rui.key
  12. Run this command to create the vSphere Update Manager certificate request and export the private key:openssl req -new -nodes -out c:\certs\UpdateManager\rui.csr -keyout c:\certs\UpdateManager\rui-orig.key -config c:\certs\UpdateManager\updatemanager.cfg
  13. Convert the key to be in the proper RSA format for vSphere Update Manager to use:openssl rsa -in c:\certs\UpdateManager\rui-orig.key -out c:\certs\UpdateManager\rui.key
  14. Run this command to create the vCenter Orchestrator certificate request and export the private key:openssl req -new -nodes -out c:\certs\Orchestrator\rui.csr -keyout c:\certs\Orchestrator\rui-orig.key -config c:\certs\Orchestrator\Orchestrator.cfg
  15. Convert the key to be in the proper RSA format for vCenter Orchestrator to use:openssl rsa -in c:\certs\Orchestrator\rui-orig.key -out c:\certs\Orchestrator\rui.key

After completing this section, you now have the rui.csr and rui.key files located in each of the respective directories for the different services. To validate that the CSR is created properly, you can run the command:

openssl req -in rui.csr -noout -text

After running the command, verify the output to ensure that all of the parameters entered in the .cfg file are properly set.

Proceed to the Obtaining the certificate section in the Resolution area of this article.

See Also

Mar 09

Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 (2036744)

Purpose

This article guides you through the configuration of certificates signed by a Certificate Authority (CA) for the vCenter Server Appliance 5.1. This process addresses common issues during certificate implementation, including configuration steps and pointers to avoid misconfiguration.
Note: This article is specific to vSphere 5.1. If you are using vSphere 5.5, see Configuring Certificate Authority (CA) signed certificates for vCenter Server Appliance 5.5 (2057223).

Resolution

Managing CA signed certificates for the vCenter Server appliance is a complex task. In many organizations it is required to maintain proper security for regulatory requirements.
These workflows are required for successful implementation:

These steps must be followed to ensure successful implementation of a custom certificate for vCenter Server Appliance.
Before attempting these steps, ensure that:

These are the requirements for the certificates that the vCenter Server Appliance uses:

  • Key Length – The key length currently must be a maximum of 2048 bytes from key file (PEM encoded).
  • Key File Format – Only PKCS1 is supported by all components. Make sure the base64 encoded key is in PKCS1 format. You may get RSA private keys in PKCS8 format when using some OpenSSL commands, the signal of PKCS8 key is:----- BEGIN PRIVATE KEYFor PKCS1, it is:----- BEGIN RSA PRIVATE KEYOpen the key file to correct it. If it is in PKCS8 format, run this command to convert it to PKCS1:openssl rsa -in pk8.key -out pk1.key
  • Cert File Format – Only some components support the PEM format of cert file. Make sure your cert file can be loaded by all components. Remove everything before the -----BEGIN CERTIFICATE to ensure that this is the first line of the file.
  • Certificate content – The commonName field in the Subject must be the hostname. subjectAltname must include the hostname and IP address of the host.
  • Elliptic Curve Keys – These are not currently supported.

Generating the certificate requests

For each component of the vCenter Server Appliance, you must have a custom certificate that has an appropriate organizational unit name encoded within the certificate. This means that seven different certificates are required for each vCenter Server appliance:
  • vCenter Server / Single Sign On (SSO)
  • vSphere Inventory Service
  • vSphere Web Client
  • Open LDAP
  • VMware Appliance Management Interface (VAMI)
  • vSphere Log Browser
  • vSphere Auto Deploy

To simplify the process, this article provides the steps to create different openssl.cfg files for each component.
This article uses /ssl/service to store all of the files before the certificates are installed.

To generate the appropriate configuration files:

  1. Open a text editor on the system where OpenSSL is installed.
  2. Paste this text into the file, replacing the information in red where appropriate:[ req ]default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword[v3_req ]basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:server, IP:ServerIPAddress,DNS:server.domain.com[ req_distinguished_name ]countryName = country
    stateOrProvinceName = state
    localityName = city
    0.organizationName = Organization Name
    organizationalUnitName = Vmware vCenter Service Certificate
    commonName = server.domain.com
  3. Save the file as openssl_vpxd.cfg, but do not close it.
  4. To create the inventory service configuration file, modify the organizationalUnitName to Vmware Inventory Service Certificate and save the file as openssl_inventoryservice.cfg.
  5. To create the vSphere Web Client configuration file, modify the organizationalUnitName to Vmware vCenter Web Client Service Certificate and save the file as openssl_webclient.cfg.
  6. To create the Open LDAP configuration file, modify the organizationalUnitName to Vmware LDAP Service Certificate and save the file as openssl_slapd.cfg.
  7. To create the VAMI configuration file, modify the organizationalUnitName to Vmware vCenter VAMI Certificate and save the file as openssl_vami.cfg.
  8. To create the VMware Log Browser configuration file, modify the organizationalUnitName to Vmware Logbrowser Service Certificate and save the file as openssl_logbrowser.cfg.
  9. To create the vSphere AutoDeploy configuration file, modify the organizationalUnitName to Vmware vCenter autodeploy Service Certificate and save the file as openssl_autodeploy.cfg.

When complete, there are seven different configuration files each with a different organizationalUnitName. Next, generate the certificate request and corresponding key for each of the certificates.

To generate a certificate request:

  1. Launch a command prompt and navigate into the OpenSSL directory as previously configured in the Configuring OpenSSL article.
    By default, the OpenSSL directory is located at:C:\OpenSSL-Win32\bin
  2. Run this command, replacing service with the appropriate file:openssl req -new -nodes -out rui_service.csr -keyout rui_service.key -config openssl_service.cfgFor example, to generate the vCenter SSO certificate, run:openssl req -new -nodes -out rui_vpxd.csr -keyout rui_vpxd.key -config openssl_vpxd.cfgNote: There are no prompts because all information was provided in the openssl.cfg file from above.
  3. Repeat this step for each of the seven different openssl.cfg files. By the end of this section, you have seven different .csr files and seven different .key files.
When the certificate requests are created, proceed to Getting the certificate.

Getting the certificate

After the certificate requests are generated, they must be given to the certificate authority for generation of the actual certificate. The authority responds with a signed certificate and, if appropriate, a copy of their root certificate. For the certificate chain to be trusted, the root certificate must be installed on the server which is requesting the certificate.Follow the appropriate section for the certificate authority in question.If using commercial non-Microsoft CAs:
  1. Take each certificate signing request (rui.cs, as generated above) and send them to the commercial certificate signing authority.
  2. The CA sends back the generated certificates and the certificate chain file (normally a .PEM file) to ensure that the certificates are trusted.
  3. Proceed to the Installation and configuration of the certificates section of this article to complete the configuration of the custom certificates.

If using a Microsoft CA:

  1. Log into the Microsoft CA certificate authority web interface. By default, it is:http://servername/CertSrv/
  2. Click the Request a certificate link.
  3. Click advanced certificate request.
  4. Click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file link.
  5. Open the certificate request in a plain text editor and paste this text into the Saved Request box:-----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST-----
  6. Select the Certificate Template as Web Server.Note: VMware recommends that you create a copy of the Web Server Certificate and add the Subject Alternative Name field to it. This allows you to specify more than a single name to be valid on the certificate, such as vcenter.domain.com and vcenter. Users can connect to more than one name and communication will still be valid.
  7. Click Submit to submit the request.
  8. Click Base 64 encoded on the Certificate issued screen.
  9. Click the Download Certificate link.
  10. Save the certificate on the desktop of the server as rui_service.crt, where service is the service you are creating a certificate for.Note: By default, Microsoft CA certificates are generated with the .cer format. Either use Save As or change it to .crt before continuing with this procedure.
  11. Repeat steps 2 to 10 to create each of the seven certificates from the seven certificate request files generated in the previous section of this document.
  12. Navigate back to the home page of the certificate server and click Download a CA certificate, certificate chain or CRL.
  13. Click the Base 64 option.
  14. Click the Download CA Certificate chain link.
  15. Save the certificate chain as cachain.p7b.

When complete, you have seven certificates (rui_service.crt) and the cachain.pem file generated. Proceed to Installation and configuration of the certificates to complete the configuration of the custom certificates.

Installation and configuration of the certificates

After the certificates have been created, you must validate that the certificates are in the proper format. Edit the certificate with a tool such as Notepad or vi and validate that the file begins with -----BEGIN CERTIFICATE-----. Remove all text before the -----BEGIN CERTIFICATE----- in the rui.crt files.

To complete the installation and configuration of the certificates in the vCenter Server Appliance:

Note: Before proceeding, ensure to back up the existing rui.crt, rui.key, and rui.pxf files.

  1. Stop the VMware VirtualCenter Server service and the SSO service using these commands:service vmware-sso stop
    service vmware-vpxd stop
  2. Create a directory using the mkdir command to store the files. This article uses directories named /ssl/service on the vCenter Server Appliance for the file operations. Be sure to create the appropriate directories as you proceed through the article.
  3. Copy rui_vpxd.crt, rui_vpxd.key, and cachain.p7b to the /ssl/vpxd directory on the vCenter Server Appliance.
  4. Rename rui_vpxd.crt to rui.crt by running the command:mv rui_vpxd.crt rui.crt
  5. Rename rui_vpxd.key to rui.key by running the command:mv rui_vpxd.key rui.key
  6. Run this command to convert the cachain.p7b file to cachain.pem:openssl pkcs7 -print_certs -in cachain.p7b -out cachain.pem
  7. Create the rui-ca-cert.pem file by running the command:cp cachain.pem rui-ca-cert.pem
  8. Create the .pfx file by running the command:openssl pkcs12 –export –out rui.pfx –in rui.crt -inkey rui.key –name rui –passout pass:testpassword
  9. Create the root cert chain required for VPXD/SSO by running the command:cat rui.crt rui-ca-cert.pem > chain.pem
  10. Add the CA chain to the default location by running the command:cp chain.pem /etc/ssl/certs/rootca.pem
  11. Create a hash pointer to this file by running the command:ln -s /etc/ssl/certs/rootca.pem /etc/ssl/certs/`openssl x509 -hash -noout -in /etc/ssl/certs/rootca.pem`.0
  12. Change the certs by running the command:/usr/sbin/vpxd_servicecfg certificate change chain.pem rui.keyWait until you receive this response:VC_CFG_RESULT = 0The process of replacing vCenter Server and vCenter SSO certificates is complete. This process replaces these files:/etc/vmware-vpx/ssl/rui.crt
    /etc/vmware-vpx/ssl/rui.key
    /etc/vmware-vpx/ssl/rui.pfx
    /etc/vmware-vpx/ssl/sms.truststore
    /etc/vmware-sso/keys/sso.crt
    /etc/vmware-sso/keys/sso.key
    /opt/vmware/etc/lighttpd/server.pem
  13. Copy the rui.ca-cert.pem file to the /etc/vmware-vpx/ssl directory by running the command:cp rui-ca-cert.pem /etc/vmware-vpx/ssl
  14. Change the permissions on the file by running the command:chmod 400 /etc/vmware-vpx/ssl/rui-ca-cert.pem
  15. Restart the vCenter Server Appliance.
  16. Unregister the Inventory Service from SSO by running the commands:cd /etc/vmware-sso/register-hooks.d
    ./02-inventoryservice --mode uninstall --ls-server https:// server.domain.com:7444/lookupservice/sdk
  17. Copy rui_inventoryservice.crt, rui_inventoryservice.key, and a copy of the cachain.pem file as created in step 4 of this section to the /ssl/inventoryservice directory on the vCenter Server Appliance.
  18. Rename rui_inventoryservice.crt to rui.crt by running the command:mv rui_inventoryservice.crt rui.crt
  19. Rename rui_inventoryservice.key to rui.key by running the command:mv rui_inventoryservice.key rui.key
  20. Create the rui-ca-cert.pem file by running the command:cp cachain.pem rui-ca-cert.pem
  21. Create the .pfx file by running the command:openssl pkcs12 –export –out rui.pfx –in rui.crt -inkey rui.key –name rui –passout pass:testpassword
  22. Copy rui.key, rui.crt, rui.pfx, and rui-ca-cert.pem to the /usr/lib/vmware-vpx/inventoryservice/ssl directory with the cp command.
  23. Change the permissions on these files by running these commands:chmod 400 rui-ca-cert.pem rui.key rui.pfx
    chmod 644 rui.crt
  24. Run these commands to register the Inventory Service back to SSO:cd /etc/vmware-sso/register-hooks.d
    ./02-inventoryservice --mode install --ls-server https:// server.domain.com:7444/lookupservice/sdk --user root --password password_of_root user
  25. To re-register the Inventory Service to vCenter Server the next time the service starts, run the command:rm /var/vmware/vpxd/inventoryservice_registered
  26. Run these commands to restart and register the service:service vmware-inventoryservice stop
    service vmware-vpxd stop
    service vmware-inventoryservice start
    service vmware-vpxd start
    When complete, these files have been replaced:/usr/lib/vmware-vpx/inventoryservice/ssl/rui-ca-cert.pem
    /usr/lib/vmware-vpx/inventoryservice/ssl/rui.crt
    /usr/lib/vmware-vpx/inventoryservice/ssl/rui.key
    /usr/lib/vmware-vpx/inventoryservice/ssl/rui.pfx
  27. Unregister the vSphere Web Client from SSO by running the commands:cd /etc/vmware-sso/register-hooks.d
    ./10-vmware-vsphere-client --mode uninstall --ls-server https:// server.domain.com:7444/lookupservice/sdk
  28. Copy rui_webclient.crt, rui_webclient.key, and a copy of the cachain.pem file as created in step 4 of this section to the /ssl/vsphere-client directory on the vCenter Server Appliance.
  29. Rename rui_webclient.crt to vsphere-client.crt by running the command:mv rui_webclient.crt vsphere-client.crt
  30. Rename rui_webclient.key to vsphere-client.key by running the command:mv rui_webclient.key vsphere-client.key
  31. Create the vsphere-client-ca-cert.pem file by running the command:cp cachain.pem vsphere-client-ca-cert.pem
  32. Create the .pfx file by running the command:openssl pkcs12 –export –out vsphere-client.pfx –in vsphere-client.crt -inkey vsphere-client.key –name rui –passout pass:testpassword
  33. Copy vsphere-client.key, vsphere-client.crt, vsphere-client.pfx, and vsphere-client-ca-cert.pem to the /usr/lib/vmware-vsphere-client/server/SerenityDB/keys directory with the cp command.
  34. Change the permissions on the files by running these commands:chmod 400 vsphere-client-ca-cert.pem vsphere-client.key vsphere-client.pfx
    chmod 644 vsphere-client.crt
  35. Run these commands to re-register the web client to SSO:cd /etc/vmware-sso/register-hooks.d
    ./10-vmware-vsphere-client --mode install --ls-server https:// server.domain.com:7444/lookupservice/sdk --user root --password password_of_root user
  36. Run these commands to restart the service and ensure that it is registered:service vsphere-client stop
    service vsphere-client start
    When complete, these files have been replaced:/usr/lib/vmware-vsphere-client/server/SerenityDB/keys/vsphere-client-ca-cert.pem
    /usr/lib/vmware-vsphere-client/server/SerenityDB/keys/vsphere-client.crt
    /usr/lib/vmware-vsphere-client/server/SerenityDB/keys/vsphere-client.key
    /usr/lib/vmware-vsphere-client/server/SerenityDB/keys/vsphere-client.pfx
  37. For OpenLDAP, start by copying rui_slapd.crt, rui_slapd.key, and a copy of the cachain.pem file as created in step 4 of this section to the /ssl/slapd directory on the vCenter Server Appliance.
  38. Rename rui_slapd.crt to slapd.crt by running the command:mv rui_slapd.crt slapd.crt
  39. Rename rui_slapd.key to slapd.key by running the command:mv rui_slapd.key slapd.key
  40. Create the slapd-ca-cert.pem file by running the command:cp cachain.pem slapd-ca-cert.pem
  41. Create the .pfx file by running the command:openssl pkcs12 –export –out slapd.pfx –in slapd.crt -inkey slapd.key –name rui –passout pass:testpassword
  42. Copy slapd.key, slapd.crt, slapd.pfx, and slapd-ca-cert.pem to the /etc/openldap/ssl directory with the cp command.
  43. Change the permissions on the files by running these commands:chmod 400 slapd-ca-cert.pem slapd.key slapd.pfx
    chmod 644 slapd.crt
    chown ldap:root slapd.*
  44. Run these commands to restart the service and ensure that it is registered:
    service vmware-vpxd stop
    service vmware-vpxd start
    When complete, these files have been replaced:/etc/openldap/ssl/slapd-ca-cert.pem
    /etc/openldap/ssl/slapd.crt
    /etc/openldap/ssl/slapd.key
    /etc/openldap/ssl/slapd.pfx
  45. For VAMI, start by copying the rui_vami.crt, rui_vami.key, and a copy of the cachain.pem file as created in step 4 of this section to the /ssl/vami direcory on the vCenter Server Appliance.
  46. Rename rui_vami.crt to vami.crt by running the command:mv rui_vami.crt vami.crt
  47. Rename rui_vami.key to vami.key by running the command:mv rui_vami.key vami.key
  48. Create the vami-ca-cert.pem file by running the command:cp cachain.pem vami-ca-cert.pem
  49. Create the .pfx file by running the command:openssl pkcs12 –export –out vami.pfx –in vami.crt -inkey vami.key –name rui –passout pass:testpassword
  50. Unregister the service from vSphere SSO by running the commands:cd /etc/vmware-sso/register-hooks.d
    ./10-vami --mode uninstall --ls-server https:// server.domain.com:7444/lookupservice/sdk
  51. Copy vami.key, vami.crt, vami.pfx, and vami-ca-cert.pem to the /etc/vmware-sso/keys directory with the cp command.
  52. Change the permissions on the files by running these commands:chmod 400 vami-ca-cert.pem vami.key vami.pfx
    chmod 644 vami.crt
  53. Run these commands to re-register the vami service to SSO:cd /etc/vmware-sso/register-hooks.d
    ./10-vami --mode install --ls-server https:// server.domain.com:7444/lookupservice/sdk --user root --password password_of_root user
  54. Restart the vCenter Server appliance.When complete, these files have been replaced:/etc/vmware-sso/keys/vami-ca-cert.pem
    /etc/vmware-sso/keys/vami.crt
    /etc/vmware-sso/keys/vami.key
    /etc/vmware-sso/keys/vami.pfx
  55. Unregister the service from SSO by running the commands:cd /etc/vmware-sso/register-hooks.d
    ./09-vmware-logbrowser --mode uninstall --ls-server https:// server.domain.com:7444/lookupservice/sdk
  56. Copy the rui_logbrowser.crt, rui_logbrowser.key, and a copy of the cachain.pem file as created in step 4 of this section to the /ssl/logbrowser directory on the vCenter Server Appliance.
  57. Rename rui_logbrowser.crt to rui.crt by running:mv rui_logbrowser.crt rui.crt
  58. Rename rui_logbrowser.key to rui.key by running the command:mv rui_logbrowser.key rui.key
  59. Create the rui-ca-cert.pem file by running the command:cp cachain.pem rui-ca-cert.pem
  60. Create the .pfx file by running the command:openssl pkcs12 –export –out rui.pfx –in rui.crt -inkey rui.key –name rui –passout pass:testpassword
  61. Copy rui.key, rui.crt, rui.pfx, and rui-ca-cert.pem to the /usr/lib/vmware-logbrowser/conf directory with the cp command.
  62. Change the permissions on the files by running these commands:chmod 400 rui-ca-cert.pem rui.key rui.pfx
    chmod 644 rui.crt
  63. Run these commands to re-register the log browser service to SSO:cd /etc/vmware-sso/register-hooks.d
    ./09-vmware-logbrowser --mode install --ls-server https:// server.domain.com:7444/lookupservice/sdk --user root --password password_of_root user
  64. From the /ssl/vpxd folder (or the location where you stored the VPXD/SSO certificates), run this command to create a .pfx that includes the SSO certificate (rui.crt), SSO key (rui.key), and the CA certificate (cachain.pem):openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile cachain.pem -name "rui" -passout pass:testpassword -out ruiSTS.pfx
  65. Convert this to a JAVA keystore by running the command:keytool -v -importkeystore -srckeystore ruiSTS.pfx -srcstoretype pkcs12 -srcstorepass testpassword -srcalias rui -destkeystore rui.jks -deststoretype JKS -deststorepass changeit -destkeypass changeitNote: Do not change the destination store password from changeit.
  66. Copy the file to the machine that will be used to log into the vSphere Web Client.
  67. Log into the vSphere WebClient as admin@system-domain.
  68. Navigate to Administration > Sign-On and Discovery > Configuration, then click the STS Certificate tab.
  69. Click Edit > Browse.
  70. Navigate to rui.jks.
  71. When prompted, enter changeit as the password and click OK. The rui key chain is shown in the interface.
  72. Click rui.
  73. Click OK.
  74. When prompted for the password, enter changeit. You see another chain added, and the certificate is available in the GUI.
  75. When complete, restart the Log Browser, Inventory, and vpxd services by running the commands:service vmware-inventoryservice stop
    service vmware-inventoryservice start
    service vmware-logbrowser stop
    service vmware-logbrowser start
    service vmware-vpxd stop
    service vmware-vpxd start
    When complete, these files have been replaced:/usr/lib/vmware-logbrowser/conf/rui-ca-cert.pem
    /usr/lib/vmware-logbrowser/conf/rui.crt
    /usr/lib/vmware-logbrowser/conf/rui.key
    /usr/lib/vmware-logbrowser/conf/rui.pfx
  76. For Auto Deploy, start by copying the rui_autodeploy.crt and rui_autodeploy.key to the /ssl/autodeploy directory on the vCenter Server Appliance.
  77. Rename rui_autodeploy.crt to waiter.crt by running the command:mv rui_autodeploy.crt waiter.crt
  78. Rename rui_autodeploy.key to waiter.key by running the command:mv rui_autodeploy.key waiter.key
  79. Copy the waiter.key and the waiter.crt files to /etc/vmware-rbd/ssl.
  80. Change the permissions and ownership on the waiter files by running the commands:chmod 644 waiter.crt
    chmod 400 waiter.key
    chown deploy:deploy waiter.crt waiter.key
  81. Re-register the service to the vCenter Server with the commands:/etc/init.d/vmware-rbd-watchdog stop
    rm /var/vmware/vpxd/autodeploy_registered
    service vmware-vpxd restart
    When complete, these files have been replaced:/etc/vmware-rbd/ssl/rui.crt
    /etc/vmware-rbd/ssl/rui.key

Additional Information

If you need to roll back or generate the default certificates:
  1. Go to http://vcenter_ip_address or fqdn:5480.
  2. Click the Admin tab.
  3. Click Toggle certificate setting under Actions.
  4. Restart the vCenter Server Appliance. During the restart, the certificates are regenerated.
  5. Click the Admin tab and disable the Toggle certificate setting.

See Also

Mar 09

Configuring Certificate Authority (CA) signed certificates for vCenter Server Appliance 5.5 (2057223)

Purpose

This article guides you though the configuration of Certificate Authority (CA) certificates for the vCenter Server Appliance 5.5. This process addresses common issues during certificate implementation, including configuration steps and pointers to avoid misconfiguration.Note: This article applies specifically to vSphere 5.5. If you are using vSphere 5.1, see Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 (2036744).

Resolution

Managing CA-signed certificates for the vCenter Server Appliance is a complex task. In many organizations it is required to maintain proper security for regulatory requirements.These workflows are required for successful implementation:

These steps must be followed to ensure successful implementation of a custom certificate for vCenter Server Appliance. Before attempting these steps, ensure that:

Requirements for the certificates used by vCenter Server Appliance

  • Key Length – The key length currently must be a maximum of 2048 bytes Before proceeding, confirm from key file (PEM encoded).
  • Key File Format – Only PKCS1 is supported by all components. Make sure the base64 encoded key is in PKCS1 format. You may get RSA private keys in PKCS8 format when using some OpenSSL commands; the signal of the PKCS8 key is:----- BEGIN PRIVATE KEYFor PKCS1, it is:----- BEGIN RSA PRIVATE KEYOpen the key file to correct it. If it is in PKCS8 format, run this command to convert it to PKCS1:openssl rsa -in pk8.key -out pk1.key
  • Cert File Format – Only some components support the PEM format of cert file. Make sure your cert file can be loaded by all components. Remove everything before the -----BEGIN CERTIFICATE to ensure that this is the first line of the file.
  • Certificate content – The commonName field in the Subject must be the hostname. The Subject Alternative Name subjectAltname must include the host FQDN and IP address. Otherwise, un-registering the Inventory service from SSO fails.
  • Elliptic Curve Keys – These are not currently supported.

Generating the certificate requests

For each component of the vCenter Server Appliance, you must have a custom certificate that has a unique Subject Distinguished Name encoded within the certificate.

Note: A unique organizationUnitName (OU) is not essential, but it is recommend by VMware; the requirement for proper certificate requests and therefore certificate generation is for a unique Subject Distinguished Name. The OU is just a part of the distinguished name (DN), and having a unique OU is one way to achieve a unique DN, but it is not the only method.

This means that four different certificates are required for each vCenter Server Appliance:

  • vCenter Server / vCenter Single Sign-On (SSO)
  • vCenter Inventory Service
  • VMware Log Browser
  • vSphere AutoDeploy

Note: The vSphere Web Client and the Virtual Appliance Management Infrastructure (VAMI) use the same SSL certificate as vCenter Server. vSphere Auto Deploy does not register a solution user and does not require a unique certificate (the vCenter vServer certificate can be safely reused); however, the steps provided will install a unique certificate.

To simplify the process, this article provides the steps to create different openssl.cfg files for each component.

This article uses /ssl/service to store all of the files on the vCenter Server Appliance before the certificates are installed. This article also uses C:\Certs to store all files on the system creating the certificate requests and certificate generation before uploading to the vCenter Server Appliance.

To generate the appropriate configuration files:

  1. On the system where you are generating the certificates, create a folder in which you can store the certificates for the difference components. These steps use the C:\Certs folder.
  2. In the C:\Certs folder, create three other folders to organize your certificate requests. These steps use these four folders:
    • vCenterSSO
    • InventoryService
    • LogBrowser
    • AutoDeploy
  3. Open a text editor on the system where OpenSSL is installed.
  4. Create an OpenSSL configuration file for each service.A sample configuration file appears similar to:[ req ]
    default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword
    [ v3_req ]
    basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:vcva55, IP: 10.0.0.10, IP:ServerIPv6Address, DNS: vcva55.vmware.com[ req_distinguished_name ]
    countryName = US
    stateOrProvinceName = NY
    localityName = New York
    0.organizationName = VMware
    organizationalUnitName = vCenterApplianceUniqueServer
    commonName = vcva55.vmware.comPaste this text into the file, replacing the information in red where appropriate.Note: The country name is always the two-digit country code for the country.Steps 4 to 9 discuss the changes that need to be made in each certificate file.
  5. Save the file as openssl_generic.cfg in c:\certs\ .Note: If you are not using IPv6 in your environment, this can be omitted from the subjectAltName.
  6. For the VirtualCenter Server Service configuration file, modify the organizationalUnitName to VMware vCenter Service Certificate and save the file as openssl_vpxd.cfg in c:\certs\vCenterSSO\.[ req ]
    default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword[ v3_req ]
    basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:server, IP:ServerIPv4Address, IP:ServerIPv6Address, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Organization Name
    organizationalUnitName = VMware vCenter Service Certificate
    commonName = server.domain.com
  7. For the vCenter Inventory Service configuration file, modify the organizationalUnitName to VMware Inventory Service Certificate and save the file as openssl_inventoryservice.cfg in c:\certs\InventoryService\.[ req ]
    default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword[ v3_req ]
    basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:server, IP:ServerIPv4Address, IP:ServerIPv6Address, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Organization Name
    organizationalUnitName = VMware Inventory Service Certificate
    commonName = server.domain.com
  8. To create the VMware Log Browser configuration file, modify the organizationalUnitName to VMware LogBrowser Service Certificate and save the file as openssl_logbrowser.cfg in c:\certs\LogBrowser\.[ req ]
    default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword[ v3_req ]
    basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:server, IP:ServerIPv4Address, IP:ServerIPv6Address, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Organization Name
    organizationalUnitName = VMware LogBrowser Service Certificate
    commonName = server.domain.com
  9. To create the vSphere Auto Deploy configuration file, modify the organizationalUnitName to VMware vSphere Autodeploy Service Certificate and save the file as openssl_autodeploy.cfg in c:\certs\AutoDeploy\.[ req ]
    default_md = sha512
    default_bits = 2048
    default_keyfile = rui.key
    distinguished_name = req_distinguished_name
    encrypt_key = no
    prompt = no
    string_mask = nombstr
    req_extensions = v3_req
    input_password = testpassword
    output_password = testpassword[ v3_req ]
    basicConstraints = CA:false
    keyUsage = digitalSignature, keyEncipherment, dataEncipherment
    extendedKeyUsage = serverAuth, clientAuth
    subjectAltName = DNS:server, IP:ServerIPv4Address, IP:ServerIPv6Address, DNS:server.domain.com[ req_distinguished_name ]
    countryName = Country
    stateOrProvinceName = State
    localityName = City
    0.organizationName = Organization Name
    organizationalUnitName = VMware vSphere Autodeploy Service Certificate
    commonName = server.domain.com

When complete, there are three different configuration files each with a different organizationalUnit Name. Next, generate the certificate request and corresponding key for each of the certificates.

To generate a certificate request:

  1. Launch a command prompt and navigate into the OpenSSL directory as previously configured in the Configuring OpenSSL article.By default, the OpenSSL directory is located at:C:\OpenSSL-Win32\bin
  2. Run this command to create the vCenter Server and vCenter Single Sign-On certificate request and export the private key:openssl req -new -nodes -out c:\certs\vCenterSSO\rui_vpxd.csr -keyout c:\certs\vCenterSSO\rui_vpxd.key -config c:\certs\vCenterSSO\openssl_vpxd.cfg
  3. Run this command to create the vCenter Inventory Service certificate request and export the private key:openssl req -new -nodes -out c:\certs\InventoryService\rui_inventoryservice.csr -keyout c:\certs\InventoryService\rui_inventoryservice.key -config c:\certs\InventoryService\openssl_inventoryservice.cfg
  4. Run this command to create the vSphere Log Browser certificate request and export the private key:openssl req -new -nodes -out c:\certs\LogBrowser\rui_logbrowser.csr -keyout c:\certs\LogBrowser\rui_logbrowser.key -config c:\certs\LogBrowser\openssl_logbrowser.cfg
  5. Run this command to create the vSphere AutoDeploy certificate request and export the private key:openssl req -new -nodes -out c:\certs\AutoDeploy\rui_autodeploy.csr -keyout c:\certs\AutoDeploy\rui_autodeploy.key -config c:\certs\AutoDeploy\openssl_autodeploy.cfg

After running these commands, you now have the rui_service.csr and rui_service.key files located in each respective directory.

When the certificate requests are created, proceed to the Getting the certificates section.

Getting the certificates

After the certificate requests are generated, they must be given to the certificate authority for generation of the actual certificate. The authority responds with a signed certificate and, if appropriate, a copy of their root certificate. For the certificate chain to be trusted, the root certificate must be installed on the server which is requesting the certificate.

Follow the appropriate section for the certificate authority used.

If you are using commercial non-Microsoft CAs:

  1. Take each certificate signing request (rui.csr, as generated above) and send them to the commercial certificate signing authority.
  2. The CA sends back the generated certificates and the certificate chain file (normally a .PEM file) to ensure that the certificates are trusted.
  3. Proceed to the Installation and configuration of the certificates section of this article to complete the configuration of the custom certificates.

If you are using a Microsoft CA:

  1. Log in to the Microsoft CA certificate authority web interface. By default, it is:http://servername/CertSrv/
  2. Click the Request a certificate link.
  3. Click advanced certificate request.
  4. Click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file link.
  5. Open the certificate request (rui_service.csr, as generated above for each component) in a plain text editor and paste this text into the Saved Request box:-----BEGIN CERTIFICATE REQUEST----- to -----END CERTIFICATE REQUEST-----
  6. Select the Certificate Template as Web Server.Note: VMware recommends that you create a copy of the Web Server Certificate and add the Subject Alternative Name field to it. This allows you to specify more than a single name to be valid on the certificate, such as vcenter.domain.com and vcenter. Users can connect to more than one name and communication will still be valid.
  7. Click Submit to submit the request.
  8. Click Base 64 encoded on the Certificate issued screen.
  9. Click the Download Certificate link.
  10. Save the certificate as rui_service.crt, in the appropriate c:\certs\<service>\ folder.For example:rui_vpxd.crtNotes:
    • Before proceeding, confirm that the three key usages are present on the .crt file by viewing its properties. This can be found by opening the rui.crt, clicking the Details tab, and locating the Key Usage row under Field. The default install of Windows Server 2008 with the CA role will not create *.crt files properly. You must first modify the digitalSignature,  keyEncipherment, and dataEncipherment fields on the CA server’s Web Server template before continuing. For more information, see Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 5.x (2062108).
    • By default, Microsoft CA certificates are generated with the .cer format. Either use Save As or change it to .crt before continuing with this procedure.
  11. Repeat Steps 2 to 10 for each of the additional service.
  12. Navigate back to the home page of the certificate server and click Download a CA certificate, certificate chain or CRL.
  13. Click the Base 64 option.
  14. Click the Download CA Certificate chain link.
  15. Save the certificate chain as cachain.p7b in the c:\certs\ directory.

When complete, you have four certificates (rui_service.crt) for each of the services and the either the cachain.pem (for non-Microsoft CA providers) or the cachain.p7b (if the certificates are generated using a Microsoft CA) file generated in their respective c:\certs\<services> folders. Proceed to the Installation and configuration of the certificates section to complete the configuration of the custom certificates.

Installation and configuration of the certificates for all the components

After the certificates are created, you must validate that the certificates are in the proper format. Edit the certificate with a tool such as Notepad or vi and validate that the file begins with -----BEGIN CERTIFICATE-----. Remove all text before the -----BEGIN CERTIFICATE----- in the rui.crt files.

To complete the installation and configuration of the certificates in the vCenter Server Appliance:

Note: Before proceeding, ensure you back up the existing rui.crt, rui.key, and rui.pfx files.

  1. Connect to the vCenter Server Appliance via SSH.
  2. Stop the VMware VirtualCenter Server service and the vCenter Single Sign-On service using these commands:service vmware-stsd stop
    service vmware-vpxd stop
  3. Create a directory using the mkdir command to store the files. This article uses directories named /ssl/service on the vCenter Server Appliance for the file operations. Be sure to create the appropriate directories as you proceed through the article. Use these models as examples:mkdir ssl
    mkdir ssl/vpxd
    mkdir ssl/inventoryservice
    mkdir ssl/logbrowser
    mkdir ssl/autodeploy
  4. Using WinSCP from the system you created all of the SSL certificates on, copy rui_vpxd.crt, rui_vpxd.key, and cachain.p7b file from c:\certs\vCenterSSO to the /ssl/vpxd directory on the vCenter Server Appliance.Note: In this step, ignore the cachain.p7b file if the certificate is obtained using a non-Microsoft CA..
  5. Rename rui_vpxd.crt to rui.crt by running the command:cp ssl/vpxd/rui_vpxd.crt ssl/vpxd/rui.crt
  6. Rename rui_vpxd.key to rui.key by running the command:cp ssl/vpxd/rui_vpxd.key ssl/vpxd/rui.key
  7. From the vCenter Server Appliance, run the following commands to convert the cachain.p7b file to chain.pem:cd ssl/vpxd/openssl pkcs7 -print_certs -in cachain.p7b -out cachain.pemNote: This step can be ignored if the certificate is obtained using a non-Microsoft CA..
  8. Open the cachain.pem file with VI editor. For more information, see Editing files on an ESX host using vi or nano (1020302).
  9. Using VI editor, remove any text before the first “-----BEGIN CERTIFICATE-----” and after “—–END CERTIFICATE—–“.Note: This assumes there are no intermediate certificates in the Certificate Authority. If you are using two or more levels in the Certificate Authorities, remove any text in between the —–END CERTIFICATE—– of the intermediate thumbprint and -----BEGIN CERTIFICATE----– of the Root CA thumbprint. Before editing, review the chain.pem file to ensure all intermediates and the Root CA server thumbprints are present. If the file does not contain the authority certificate, obtain it from the Certification Authority and append it manually.This should result in a concatenated file similar to the model below:—–BEGIN CERTIFICATE—–
    Thumbprint Intermediate(n) CA Server
    —–END CERTIFICATE—–
    —–BEGIN CERTIFICATE—–
    Thumbprint Intermediate(2) CA Server
    —–END CERTIFICATE—–
    —–BEGIN CERTIFICATE—–
    Thumbprint Intermediate(1) CA Server
    —–END CERTIFICATE—–
    —–BEGIN CERTIFICATE—–
    Thumbprint Root CA Server
    —–END CERTIFICATE—–
  10. Create the chain.pem file for vCenter Server service by running the commands:cat rui.crt cachain.pem > chain.pem
  11. Replace the SSL certs by running the command:/usr/sbin/vpxd_servicecfg certificate change chain.pem rui.keyWait until you receive this response:VC_CFG_RESULT = 0Note: The command prints the outcome code using this syntax:VC_CFG_RESULT=CODEStatus code 0 means success. For details on all possible error conditions, see Decoding non-zero VC_CFG_RESULT for failed vpxd_servicecfg certificate changes (2057248).
  12. Ensure the vCenter Single Sign-On service is started before continuing by running the command:service vmware-stsd start
  13. Unregister the vCenter Inventory Service from vCenter Single Sign-On by running the commands:cd /etc/vmware-sso/register-hooks.d./02-inventoryservice --mode uninstall --ls-server https://server.domain.com:7444/lookupservice/sdk
  14. Using WinSCP from the system you created all of the SSL certificates on, copy rui_inventoryservice.crt and rui_inventoryservice.key from c:\certs\InventoryService to the /ssl/inventoryservice directory on the vCenter Server Appliance.
  15. Copy the edited cachain.pem file from Step 9 to the /ssl/inventoryservice directory using the following command:cd
    cp ssl/vpxd/cachain.pem ssl/inventoryservice/
  16. Rename rui_inventoryservice.crt to rui.crt by running the command:cp ssl/inventoryservice/rui_inventoryservice.crt ssl/inventoryservice/rui.crt
  17. Rename rui_inventoryservice.key to rui.key by running the command:cp ssl/inventoryservice/rui_inventoryservice.key ssl/inventoryservice/rui.key
  18. Create the chain.pem file for vCenter Inventory Service by running the commands:cd ssl/inventoryservice
    cat rui.crt cachain.pem > chain.pem
  19. Create the *.pfx file by running the command:openssl pkcs12 -export -out rui.pfx -in chain.pem -inkey rui.key -name rui -passout pass:testpassword
  20. Copy the rui.key, rui.crt, and rui.pfxfiles to the /usr/lib/vmware-vpx/inventoryservice/ssl directory:
    cp rui.key /usr/lib/vmware-vpx/inventoryservice/ssl
    cp rui.crt /usr/lib/vmware-vpx/inventoryservice/ssl
    cp rui.pfx /usr/lib/vmware-vpx/inventoryservice/ssl
  21. Change the permissions on these files by running these commands:cd /usr/lib/vmware-vpx/inventoryservice/ssl/
    chmod 400 rui.key rui.pfx
    chmod 644 rui.crt
  22. Run these commands to register the vCenter Inventory Service back to vCenter Single Sign-On:cd /etc/vmware-sso/register-hooks.d./02-inventoryservice –mode install –ls-server https://server.domain.com:7444/lookupservice/sdk –user sso_administrator –password sso_administrator_passwordNote: As there is a plain-text password on the above command, to avoid the history file showing the contents of the password because it is in plain text in the command above, run the unset HISTFILE command prior to executing step 22.Note: The default SSO administrator username for vCenter Single Sign-On 5.5 is administrator@vSphere.localAfter a successful registration, you see output similar to:Logbrowser Successful Reg
  23. To re-register the vCenter Inventory Service to vCenter Server the next time the service starts, run this command:rm /var/vmware/vpxd/inventoryservice_registered
  24. Run these commands to restart and register the service:service vmware-inventoryservice stop
    service vmware-vpxd stop
    service vmware-inventoryservice start
    service vmware-vpxd start
  25. Unregister the VMware Log Browser service from vCenter Single Sign-On by running the commands:cd /etc/vmware-sso/register-hooks.d./09-vmware-logbrowser –mode uninstall –ls-server https://server.domain.com:7444/lookupservice/sdk
  26. Using WinSCP from the system you created all of the SSL certificates on, copy the rui_logbrowser.crt, rui_logbrowser.key from c:\certs\LogBrowser to the /ssl/logbrowser directory on the vCenter Server Appliance
  27. Copy the edited cachain.pem file from Step 9 to the /ssl/logbrowser directory using the following commands:cdcp ssl/vpxd/cachain.pem ssl/logbrowser
  28. Rename rui_logbrowser.crt to rui.crt by running the command:cp ssl/logbrowser/rui_logbrowser.crt ssl/logbrowser/rui.crt
  29. Rename rui_logbrowser.key to rui.key by running the command:cp ssl/logbrowser/rui_logbrowser.key ssl/logbrowser/rui.key
  30. Create the chain.pem file for VMware Log Browser Service by running the commands:cd ssl/logbrowsercat rui.crt cachain.pem > chain.pem
  31. Create the *.pfx file by running the command:openssl pkcs12 -export –out rui.pfx –in chain.pem -inkey rui.key –name rui –passout pass:testpassword
  32. Copy rui.key, rui.crt, and rui.pfx files to the /usr/lib/vmware-logbrowser/conf directory:cp rui.key /usr/lib/vmware-logbrowser/conf
    cp rui.crt /usr/lib/vmware-logbrowser/conf
    cp rui.pfx /usr/lib/vmware-logbrowser/conf
  33. Change the permissions on the files by running these commands:cd /usr/lib/vmware-logbrowser/conf
    chmod 400 rui.key rui.pfx
    chmod 644 rui.crt
  34. Run these commands to re-register the VMware Log Browser service to vCenter Single Sign-On:cd /etc/vmware-sso/register-hooks.d./09-vmware-logbrowser –mode install –ls-server https://server.domain.com:7444/lookupservice/sdk –user sso_administrator –password sso_administrator_passwordNote: The default SSO administrator username for vCenter Single Sign-On 5.5 is administrator@vSphere.localA successful registration will output the following:
  35. When complete, restart the Log Browser service by running the commands:service vmware-logbrowser stop
    service vmware-logbrowser start
    Note: If you plan to skip the replacement of certificates for any of the components, such as vSphere Auto Deploy, you must restart the vCenter Server Appliance after the last certificate is replaced/services restarted. Proceed to step 40.
  36. Using WinSCP from the system you created all of the SSL certificates on, copy the rui_autodeploy.crt and rui_autodeploy.key from c:\certs\AutoDeploy to the /ssl/autodeploy directory on the vCenter Server Appliance.
  37. Copy the rui_autodeploy.crt and rui_autodeploy.key to the /etc/vmware-vpx/ssl/ directory: cd
    cp ssl/autodeploy/rui_autodeploy.crt /etc/vmware-rbd/ssl/waiter.crt
    cp ssl/autodeploy/rui_autodeploy.key /etc/vmware-rbd/ssl/waiter.key
  38. Change the permissions and ownership on the waiter files by running these commands:cd /etc/vmware-rbd/ssl/
    chmod 644 waiter.crt
    chmod 400 waiter.key
    chown deploy:deploy waiter.crt waiter.key
  39. Re-register the service to the vCenter Server with the commands:
    service vmware-rbd-watchdog stop
    rm /var/vmware/vpxd/autodeploy_registered
    service vmware-vpxd restart
  40. Restart the vCenter Server Appliance. For more information, see Stopping, starting, or restarting vCenter Server Appliance services (2054085).

Additional Information

To roll back or generate the default certificates:

  1. Go to http://vcenter_ip_address or http://fqdn:5480.
  2. Click the Admin tab.
  3. Click Toggle certificate setting under Actions.
  4. Restart the vCenter Server Appliance. During the restart, the certificates are regenerated.
  5. Click the Admin tab and disable the Toggle certificate setting.

See Also