Knowledge Base

The VMware Knowledge Base provides support solutions, error messages and troubleshooting guides
 
Search the VMware Knowledge Base (KB)   View by Article ID
 

Creating certificate requests and certificates for vCenter Server 5.1 components (2037432)

Purpose

This article provides information on manually configuring Certificate Authority (CA) signed SSL certificates in a vSphere 5.1 environment.  VMware has released a tool to automate much of the described process below.  Please see Deploying and using the SSL Certificate Automation tool (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. If you are using vSphere 5.0, see Implementing CA signed SSL Certificates with vSphere 5.0 (2015383).

Resolution

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

Note: This article is part of a resolution path. See Implementing CA signed SSL certificates with vSphere 5.1 (2034833) before following 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
  • Getting 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.1 environment.
  • The environment has been pre-installed for all components for which you will be installing certificates.
  • OpenSSL v0.9.8 has been downloaded from http://slproweb.com/products/Win32OpenSSL.html and 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.
  • You are not using wild card certificates.  Each certificate needs to be unique in vSphere 5.1 and as a result wild card certificates are not supported.

Creating the OpenSSL configuration files

There are six 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. 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, dataEncipherment components for Key Usage
To create the OpenSSL configuration files for creating the certificate requests:
  1. 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.
  2. In the C:\certs folder, create six other folders, so that you can organize each of the certificates. These steps use these six folders:

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

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

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

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

    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 Server 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
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 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 need to generate a certificate request for each of the components:
  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 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 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 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 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 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 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. Execute 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 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
After running the above commands, you now have the rui.csr and rui.key files located in each of the respective six directories for the different services.  If you would like to validate that the csr is created correctly you can run:

openssl req -in rui.csr -noout -text

Once run, take a look over the output to verify the output to make sure that all of the parameters entered in the .cfg file are properly set in the request.

Proceed to Getting the certificate.

Getting 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:

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 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.
  11. Repeat Steps 2 to 10 for each additional service. Confirm that the three key usages are present on the .crt file by viewing its properties. 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 before continuing.
  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 select 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.cer and 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 into Base-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 them one by one instead.

    For example, create files named C:\certs\Root64-1.cer, C:\certs\Root64-2.cer, etc. Once complete, concatenate the certificates into a single file named Root64.cer, which will be used in the subsequent commands.

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

    copy root64-1.cer+Root64-2.cer Root64.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 will 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 the Root64.cer root certificate.
 
Note:  There should 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:

Note: The commands here are different than many other PFX creation commands, as they include the CA certificate chain within the PFX file as well.
  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 rui.pfx file for vCenter Server SSO:

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

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

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

Creating the JKS

Once the PFX files are created, you can create the Java Keystore file (JKS) for use with the configuration.

To create the JKS:
  1. Open a command prompt on the vCenter Single Sign-On server.
  2. Navigate to the C:\Program Files\VMware\Infrastructure\jre\bin\ directory.
  3. Run the command:

    keytool -v -importkeystore -srckeystore C:\certs\sso\rui.pfx -srcstoretype pkcs12 -srcstorepass testpassword -srcalias rui -destkeystore C:\certs\sso\root-trust.jks -deststoretype JKS -deststorepass testpassword -destkeypass testpassword

  4. Once created, you must add the root certificate to the JKS file with the alias root-ca. To add the root certificate, run the command:

    keytool -v -importcert -keystore C:\certs\sso\root-trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -file c:\certs\Root64.cer -alias root-ca

  5. When asked if you want to trust this certificate, type yes. A message saying Certificate was added to the keystore is displayed.
  6. If there are intermediate certificates in the certificate chain, they also must be added to the JKS file. Repeat this step for each Intermediate CA Certificate. To add any intermediate certificates, run the command:

    keytool -v -importcert -noprompt -trustcacerts -keystore C:\certs\sso\root-trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -file C:\certs\<intercacert>.cer -alias intermediate-<hash>.0

    Where <intercacert> is the certificate for the intermediate CA (in this example, Root64-1.cer is used), and <hash> is the hash generated by this OpenSSL command:

    openssl x509 -subject_hash -noout -in c:\certs\<intercacert>.cer

    Note: The hash must be created with OpenSSL v0.9.8 as this is the version which vCenter Server uses. If created with another version, the hash may not be correct.

  7. When complete, run this command to check that the certificates have been imported successfully:

    keytool -list -v -keystore c:\certs\sso\root-trust.jks

  8. Copy c:\certs\sso\root-trust.jks to c:\certs\sso\server-identity.jks.


You now have all of the files required to implement custom SSL certificates. Be sure to copy the c:\certs folder to the vCenter Server if all services are running on a single server. Otherwise, copy the respective certificates to the appropriate servers.

Proceed to the next article in this resolution path, Implementing CA signed SSL certificates with vSphere 5.1 (2034833), to replace the vCenter SSO certificates.

Additional Information

For information on using CA certificates in vSphere Auto Deploy, see the Prepare Your System and Install the Auto Deploy Server section of the vSphere Installation and Setup Guide.

For Certificates issued by Enterprise CAs, the validity period is defined in the template used to create the certificate. Windows 2000 and Windows Server 2003 Standard Edition do not support modification of these templates.

For more information, see the Microsoft Knowledge Base article 254632.
 
Note: The preceding link was correct as of June 10, 2013. If you find the link is broken, provide feedback and a VMware employee will update the link.

See Also

Update History

11/15/2012 - Updated step 20 in Getting the certificate 11/29/2012 - Added link to Auto Deploy guide. 01/23/2013 - Added Microsoft KB 254632 into the additional information section. 03/14/2013 - Made minor changes: Changed JKS section to clarify the system you need to be on. Changed the PFX section to provide more details on the -info command. Changed the opsnssl.cfg files to support SRM - (moved the FQDN to the last SAN).

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

  • 28 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)
  • 28 Ratings
Actions
KB: