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

Note: This article is specifically for vSphere 5.1. If you are using vSphere 5.5, see Creating certificate requests and certificates for vCenter Server 5.5 components (2061934). 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.1 environment. VMware has released a tool to automate much of the described process below. See Deploying and using the SSL Certificate Automation Tool 1.0.x (2041600) before following the steps in this 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.

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.x (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
  • 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.1 environment.
  • The environment has been 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 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.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.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
  • 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
  • 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 seven other folders so that you can organize each of the certificates. These steps use these six 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. When using a commercial CA for certificate signing, the IP address can be left out of the certificate if the DNS resolves properly for the short name, the fully-qualified domain, and reverse lookup.

    [ 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 = vCenterUniqueServer
    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 must 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

  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.

Proceed to Generating certificate requests.

Generating certificate requests

Now that OpenSSL has been configured, you must generate a certificate request for each of the components:

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

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

  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. 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 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. Optional: Run this command to create the vSphere Auto Deploy certificate request and export the private key:

    openssl req -new -nodes -out c:\certs\AutoDeploy\rui.csr -keyout c:\certs\AutoDeploy\rui-orig.key -config c:\certs\AutoDeploy\autodeploy.cfg

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

Proceed to Obtaining 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, 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.

    Note: Before proceeding, confirm that the three key usages are present on the .crt file by viewing its properties. To determine this, open the rui.crt file, click the Details tab, and locate the Key Usage row under Field. The default installation of Windows Server 2008 with the CA role does 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. 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 Actions > 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. 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 each intermediate certificate to a separate file.

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

    The chain.cer file is used in place of the Root64.cer file, as outlined in 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 will fail.

  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.key and rui.crt files for each service and the Root64.cer root certificate.

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

After creating the certificate, 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. 
  • The -certfile c:\certs\Root64.cer used in the commands below 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 to 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 SSO:

    openssl pkcs12 -export -in c:\certs\sso\rui.crt -inkey c:\certs\sso\rui.key -certfile c:\certs\chain.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\chain.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\chain.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\chain.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\chain.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

After creating the PFX files, 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 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.x (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

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