Search the VMware Knowledge Base (KB)
View by Article ID

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

  • 56 Ratings

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.

Generating 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 a command line, navigate to the location where you unzipped the tool.
  2. Run this command:

    ssl-updater.bat


  3. From the SSL Certificate Automation tool, select Option 2 to Generate Certificate Requests.

  4. Note: VMware recommends that the certificate request (and consequently the private key) are generated on the system which is being used for the service.

  5. Select the option for the service you are generating the certificate request for.
  6. 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:

Note: Wild card certificates are not supported.
  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.
  • By default, the MS Web Server template does not have Client Authentication enabled.The Certificate Template being used must have both Client Authentication and Server Authentication enabled.

  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 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 Shining Light Productions 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.
 
Note: The preceding link was correct as of March 17, 2015. If you find the link is broken, provide feedback and a VMware employee will update the link.
 

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 vRealize 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 vRealize 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 vRealize 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

Request a Product Feature

To request a new product feature or to provide feedback on a VMware product, please visit the Request a Product Feature page.

Feedback

  • 56 Ratings

Did this article help you?
This article resolved my issue.
This article did not resolve my issue.
This article helped but additional information was required to resolve my issue.

What can we do to improve this information? (4000 or fewer characters)




Please enter the Captcha code before clicking Submit.
  • 56 Ratings
Actions
KB: