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

Creating certificate requests and certificates for vCenter Server 5.5 components (2061934)

  • 33 Ratings

Purpose

Note: This article is specifically for vSphere 5.5. If you are using vSphere 5.1, see Creating certificate requests and certificates for vCenter Server 5.1 components (2037432). If you are using vSphere 5.0, see Implementing CA signed SSL Certificates with vSphere 5.0 (2015383).

This article provides information on manually configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.5 environment. VMware has released a tool to automate much of the described process below. For more information, see Deploying and using the SSL Certificate Automation Tool 5.5 (2057340).

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

Resolution

Important: OpenSSL Version 0.9.8 must be used. If you do not use this version, the SSL implementation fails.

Note: This article is part of a resolution path. For more information, see Implementing CA signed SSL certificates with vSphere 5.x (2034833) before proceeding with the steps in this article.

Creating CA assigned certificates for vSphere is a complex task. In many organizations it is required to maintain proper security for regulatory requirements. There are several different work flows required for successful implementation:
  • Creating the OpenSSL configuration files
  • Creating the certificate requests
  • Obtaining the certificates
  • Implementing the certificates
These steps must be followed to ensure successful implementation of a custom certificate for vCenter Server. Remember that each component of the vCenter Server configuration requires its own certificate.

Before attempting these steps, ensure that:
  • You have a vSphere 5.5 environment.
  • The environment is pre-installed for all components for which you will be installing certificates.
  • You have reviewed the Key Usage Extensions for the Web Server template on your Certificate Authority server and made sure it has digitalSignature,  keyEncipherment, and dataEncipherment enabled for certificate generation.
  • OpenSSL v0.9.8 has been downloaded from Shining Light Productions it 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 04, 2015. If you find the link is broken, provide feedback and a VMware employee will update the link.

  • You are not using wild card certificates. Each certificate needs to be unique in vSphere 5.x and as a result wild card certificates are not supported.

Creating the OpenSSL configuration files

There are six separate components in vCenter Server 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. The OpenSSL configuration when generating requests must:
  • Have the subject alternative name field included in them.
  • Have unique OrganizationalUnitNames for the components.
  • Have the case of the DNS entries in the subject alternate name field match the case for the hostname and domain as the host reports when running the hostname or ipconfig /all commands.

    Note: The subject alternative name must be the same as the machine the service is installed on.

  • Include digitalSignature, keyEncipherment, dataEncipherment components for Key Usage.
To create the OpenSSL configuration files for creating the certificate requests:
  1. On the system where you are generating 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.

  2. 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
    • UpdateManager
    • vCenter
    • WebClient
    • LogBrowser
    • AutoDeploy

  3. Create OpenSSL configuration files for each service. Here is an example of a completed configuration file:

    Notes:
    • Each SSL Certificate needs 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.
    • The use of an IP address in the subjectAltName for each SSL certificate is recommended by VMware but not required. When using a commercial CA for certificate signing, the IP address can be left out of the certificate as long as DNS resolves properly for short name, fully qualified domain, and reverse lookup.
    • Due to the way different web browsers handled the subjectAltName field and its values, having a DNS and IP entry for the IP address will resolve any inconsistent connection issues with the vSphere Web Client. Use the model below as an example:

      [ 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: vc55-1, IP:10.0.0.10, DNS:vc55-1.vmware.com

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


      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. At least one subjectAltName should be in place for each server that matches the commonName field.

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


  5. For vCenter 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


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


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


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


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

  10. For vSphere Auto Deploy, create a file in C:\certs\AutoDeploy called AutoDeploy.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, keyCertSign
    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 = vSphereAutoDeploy
    commonName = server.domain.com
The OpenSSL configuration files are configured.

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


Generating certificate requests

Now that OpenSSL has been configured, you must generate a certificate request for each of the components:
  1. Click Start > run, type cmd and press Enter.

  2. Navigate into the OpenSSL directory. By default, this is C:\OpenSSL-Win32\bin.

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

  4. Convert the key to 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

  5. Run this command to create the vCenter Single Sign-On 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

  6. Convert the key to the proper RSA format for vCenter Single Sign-On to use:

    openssl rsa -in c:\certs\sso\rui-orig.key -out c:\certs\sso\rui.key

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

  8. Convert the key to the proper RSA format for vCenter Server to use:

    openssl rsa -in c:\certs\vCenter\rui-orig.key -out c:\certs\vCenter\rui.key

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

  10. Convert the key to 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

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

  12. Convert the key to 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

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

  14. Convert the key to 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

  15. Optional: Run this command to create the vSphere Auto Deploy certificate request and export the private key:

    openssl req -new -sha256 -nodes -out c:\certs\AutoDeploy\rui_autodeploy.csr -keyout c:\certs\AutoDeploy\rui_autodeploy.key -config c:\certs\AutoDeploy\openssl_autodeploy.cfg

  16. Optional: Convert the key to the proper RSA format for vSphere Auto Deploy to use:

    openssl rsa -in c:\certs\AutoDeploy\rui-orig.key -out c:\certs\AutoDeploy\rui.key
After completing the steps above, you now have the rui.csr and rui.key files located in each of the respective six directories for the different services. To validate that the CSR is created correctly, run the command:

openssl req -in rui.csr -noout -text

Check the output to verify that all of the parameters entered in the .cfg file are properly set in the request.


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, if appropriate, 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, follow these steps for 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, follow these steps for each certificate request:
  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 (rui.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 the appropriate Web Server template. This is generally a copy of the Web Server Template with the 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.

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

  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. Select 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 Actions > Export.
  18. Click Next.
  19. Select Base-64 encoded X.509 (.CER), and then click Next.
  20. Save the export to C:\certs\Root64.cerand click Next.

    Note: This assumes there are no intermediate certificates in the Certificate Authority. If there are two or more levels in the Certificate Authorities, before exporting the certificate intoBase-64 encoded X.509 (.CER), 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 each intermediate certificate to a separate file.

    For example, create files named C:\certs\interm64-1.cer, C:\certs\interm64-2.cer, etc. After completion, concatenate the certificates into a single file named chain.cer.

    The chain.cer file is used in place of the Root64.cer file per the Creating the PFX section below.

    To concatenate the two files on Windows, open a Windows command prompt, navigate to the certificates directory, then run this command:

    copy interm64-1.cer+interm64-2.cer+Root64.cer chain.cer

    If this is not correctly done before the PFX and JKS files are created below, logging into the vSphere Web Client and other components and commands fail.

  21. Click Finish.
To verify that all of the settings are correct, double-click on 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.key and rui.crt files for each service and either the Root64.cer root certificate from the Root CA Server or the concatenated chain.cer certificate containing the Root CA server and any subordinate CA servers.

Note: There must be no text before the -----BEGIN CERTIFICATE----- or after the -----END CERTIFICATE----- in the .crt or .cer files.

Proceed to Creating the PFX and follow the steps for each certificate.

Creating the PFX

When you have the certificate created, you can generate the PKCS#12 PFX file for use with each of the services.

To create the PFX file for each service:

Notes:
  • The commands here differ from many other PFX creation commands, as they include the CA certificate chain within the PFX file as well.
  • If you are using different file names for rui.crt or rui.key or if you intend to use different names for these files, ensure that all names remain consistent in the subsequent commands.
  • The -certfile c:\certs\Root64.cer used in these commands are for environments using only a single Root Certificate Authority server. If you are using intermediate Certificate Authority servers, you will use the chain.cer created in Step 20 under Obtaining the certificate section.
  1. Launch a command prompt and navigate into the OpenSSL directory. By default, this is C:\OpenSSL-Win32\bin.

  2. Run this command to create the rui.pfx file for the Inventory service:

    openssl pkcs12 -export -in c:\certs\InventoryService\rui.crt -inkey c:\certs\InventoryService\rui.key -certfile c:\certs\Root64.cer -name "rui" -passout pass:testpassword -out c:\certs\InventoryService\rui.pfx

    Note: The certificate store password must be testpassword. Do not change this parameter.

  3. Run this command to create the ssoserver.p12 file for SSO:

    openssl pkcs12 -export -in c:\certs\sso\rui.crt -inkey c:\certs\sso\rui.key -certfile c:\certs\Root64.cer -name "ssoserver" -passout pass:changeme -out c:\certs\sso\ssoserver.p12

    Note: The certificate store password must be changeme and the key alias must be ssoserver. Do not change these parameters.

  4. Run this command to create the rui.pfx file for the vCenter Server:

    openssl pkcs12 -export -in c:\certs\vcenter\rui.crt -inkey c:\certs\vcenter\rui.key -certfile c:\certs\Root64.cer -name "rui" -passout pass:testpassword -out c:\certs\vcenter\rui.pfx

  5. Run this command to create the rui.pfx file for the vSphere Web Client:

    openssl pkcs12 -export -in c:\certs\webclient\rui.crt -inkey c:\certs\webclient\rui.key -certfile c:\certs\Root64.cer -name "rui" -passout pass:testpassword -out c:\certs\webclient\rui.pfx

  6. Run this command to create the rui.pfx file for the Log Browser:

    openssl pkcs12 -export -in c:\certs\LogBrowser\rui.crt -inkey c:\certs\LogBrowser\rui.key -certfile c:\certs\Root64.cer -name "rui" -passout pass:testpassword -out c:\certs\LogBrowser\rui.pfx

  7. Run this command to create the rui.pfx file for vSphere Update Manager:

    openssl pkcs12 -export -in c:\certs\updatemanager\rui.crt -inkey c:\certs\updatemanager\rui.key -certfile c:\certs\Root64.cer -name "rui" -passout pass:testpassword -out c:\certs\updatemanager\rui.pfx

  8. The PFX files are created. To test the encoding, run this command:

    openssl pkcs12 -in c:\certs\service\rui.pfx -info

    When prompted for a password, use testpassword for both the password and the passphrase. This is purely to decode the information in the PFX file and check the validity. The output should match the Distinguished Name (DN) in the certificates and is shown along with the certificate content in the output of the -info command.
You now have all of the files required to implement custom SSL certificates. Be sure to copy the c:\certs folder to vCenter Server if all services are running on a single server. Otherwise, copy the respective certificates to the appropriate servers.

For more information on replacing the vCenter Server SSO certificates, see  Implementing CA signed SSL certificates with vSphere 5.x (2034833).

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

  • 33 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.
  • 33 Ratings
Actions
KB: