Implementing CA signed SSL certificates with vSphere 5.x – Part 2
This is the second post in a series about implementing CA signed SSL certificates. The previous post provided some background and a few important questions to consider before taking off.
Until now, KB “Implementing CA signed SSL certificates with vSphere 5.x (2034833)” is our compass.
Creating a new default template
If you are using certificates from an organizational CA, like I am, the first step is to create a correct SSL certificate template for the Certificate Authority. Follow the directions in KB “Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 5.x (2062108)”.
The steps in this KB are straightforward. After creating a new default template, the new template needs to be added to the Root CA or Subordinate CA server. This new template should be used in place of the Web Server template.
There are a few important steps:
- Create a duplicate of the Web Server
- On the Extensions tab, Key Usage, make sure you select the Signature is proof of origin (nonrepudiation) option and the Allow encryption of user data
- On the Extensions tab, Application Policies, make sure you Add Client Authentication.
After importing the new template in the Certificate Server console, it should look something like this.
To create CA assigned certificates, you must follow several workflows for successful implementation:
- Creating the OpenSSL configuration files
- Creating the certificate requests
- Obtaining the certificates
- Implementing the certificates
Depending on the vSphere version, choose the correct KB, in our case KB “Creating certificate requests and certificates for vCenter Server 5.5 components (2061934)”.
Creating the OpenSSL configuration files
Create the c:\Certs folder and the seven folders for the components.
Then, very carefully read step 3. Take a good note of the following:
- The OrganizationalUnitName (OU) field contains the name of the vSphere component to achieve a unique DN.
- In the subjectAltName field, provide the short name, the FQDN and the IP address.
Provide the correct IP addresses and hostnames in case components are installed on different servers!
To prepare the OpenSSL configuration files, I did a copy and paste of the files presented in step 4. to 10. and carefully edited the examples for my own use.
After you have finished editing, check the files for a second time.
Creating Certificate Requests
To create the Certificate Requests, you need to run two commands with lots of parameters. Also here, copy and paste the commands in step 2 to 15 into a new file e.g. create_csr.cmd in the C:\OpenSSL-Win32\bin folder.
Open a prompt, cd to the bin folder and run the newly created .cmd file.
Carefully watch the output. If everything works well, each folder should now contain the following files:
- The OpenSSL configuration file, like inventoryservice.cfg.
- The certificate request, like rui.csr.
- The original private key, like rui-orig.key.
- The converted private key, like rui.key.
The folowing command lets you check that the certificate is created correctly:
> openssl req -in rui.csr -noout -text
Obtaining the certificates
The next step is to hand over the certificate request to process the actual certificates. In return you will return a certificate 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.
For a Commercial CA, just send in the certificate request, the rui.csr file.
The KB details the steps for a Microsoft CA.
During the process, make sure, you select the newly created Certificate Template.
Repeat steps 2 to 10 for each component.
Do not forget to download the CA Certificate chain, steps 12 to 20.
If there are intermediate certificates, carefully read the section how to concatenate the certificates to a single file.
You should end up with the following files; in the C:\Certs folder:
- root64.cer or chain.cer (in case of intermediate certificates).
Each subfolder contains – in addition to the files mentioned earlier – a rui.crt file.
You can check the newly created certificates by double clicking the rui.crt file. Check for names and the correct 3 Key Usages.
Create the PFX files
When you have the certificates created, you need to generate the PKCS#12 PFX file for use the services.
Also here, create a new .cmd file containing all commands in steps 2 to 7 and place it in the C:\OpenSSL-Win32\bin folder. Open a command window, cd to the folder and run the .cmd file.
Note that the command for the SSO service (step 3) is slightly different from the others.
You can also test the encoding with the following command:
> openssl pkcs12 -in c:\certs\service\rui.pfx -info
When prompted for a password, use testpassword for both the password and the passphrase (also used during the creation).
In the next post we will continue with the implementation of the certificates.
As always, I thank you for reading.
This is the second post in a series about implementing CA signed SSL certificates in a vSphere 5.x environment.
Part 1 – Introduction.