May 08

Implementing CA signed SSL certificates with vSphere 5.0 (2015383)

Implementing CA signed SSL certificates with vSphere 5.0

    Purpose

    This article provides information on configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.0 environment. It helps you eliminate common causes for problems during certificate implementation, including configuration steps and details, and avoid common misconfigurations in the implementation of custom certificates in your environment.
    Note: This article is specifically for vSphere 5.0. If you are using vSphere 5.1, see Implementing CA signed SSL certificates with vSphere 5.1 (2034833).

Rating: 5/5


May 08

Implementing CA signed SSL certificates with vSphere 5.x (2034833)

    Purpose

    This article provides information on manually configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.1 or vSphere 5.5 environment. VMware has released a tool to automate much of the described process below. Please see Deploying and using the SSL Certificate Automation Tool 1.0.x (2041600) before following the steps in the article.
    In the case that you are unable to use the tool this article helps you eliminate common causes for problems during certificate implementation, including configuration steps and details, and helps avoid common misconfigurations in the implementation of custom certificates in your environment.
    Note: This article is specifically for vSphere 5.1 and vSphere 5.5. If you are using vSphere 5.0, see Implementing CA signed SSL certificates with vSphere 5.0 (2015383).

If your issue persists even after trying these steps:


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