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:
- 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.
- 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
- 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.
- 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
- 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
- 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
- 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
- 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
- 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
- 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:
- Click Start > run, type cmd and press Enter.
- Navigate into the OpenSSL directory. By default, this is
C:\OpenSSL-Win32\bin
.
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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:
- Take the certificate request (
rui.csr
, as generated above) and send it to the authority in question. - The authority sends back the generated certificate.
For Microsoft CAs, follow these steps for each certificate request:
- Log into the Microsoft CA certificate authority Web interface. By default, it is
http://servername/CertSrv/
. - Click the Request a certificate link.
- Click advanced certificate request.
- 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.
- 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-----
- 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.
- Click Submit to submit the request.
- Click Base 64 encoded on the Certificate issued screen.
- Click the Download Certificate link.
- 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).
- Repeat Steps 2 to 10 for each additional service.
- Navigate back to the home page of the certificate server and click Download a CA certificate, certificate chain or CRL.
- Select the Base 64 option.
- Click the Download CA Certificate chain link.
- Save the certificate chain as
cachain.p7b
in the c:\certs
folder. - Double-click the
cachain.p7b
file and navigate to C:\certs\cachain.p7b > Certificates. - Right-click the certificate listed and click All Actions > Export.
- Click Next.
- Select Base-64 encoded X.509 (.CER), and then click Next.
- 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 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.
- 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.
- Launch a command prompt and navigate into the OpenSSL directory. By default, this is
C:\OpenSSL-Win32\bin
.
- 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.
- 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.
- 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
- 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
- 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
- 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
- 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).