Home > SSL > Setting up your own CA using openssl

Setting up your own CA using openssl

SSL certificates and the processes to actually create and implement them in a vSphere 5.1 environment are a fairly complex topic. In some environments the very specific requirements VMware puts on these certificates are not accepted by the in house CA. This post is going to review these requirements and will show how to create a CA for self signing certificate requests when using a corporate or public CA is not feasible using only the SSL automation tool without the need to setup an additional Microsoft CA.

This post is going to concentrate on the certificates used by the Windows version of vCenter 5.1 and all required components. The number of certificates to replace and services differ slightly on a vCenter Server appliance but the same process can be used to actually create these certificates.

Tools needed:

First of all let’s recap the requirements for the certificates (taken from http://kb.vmware.com/kb/2044696):

  • Have the subject alternative name field included in them
  • Have unique Subject Distinguished Name (DN) for the certificate. The SSL Certificate Automation tool uses OrganizationalUnitNames for the components to achieve this uniqueness.
  • Include digitalSignaturekeyEncipherment, and dataEncipherment components for Key Usage
  • Not mentioned in the kb but a logical consequence of the used fields the SSL certificates need to be x509.3

Extract the downloaded ZIP file to a folder which you will be using through this tutorial, I decided for C:\SSLAutomationTool1.0.1, open an elevated shell and navigate to the tools\openssl subfolder.

step1

 Run the following command:

openssl req -newkey rsa:<keylength> -days <validity period> -x509 -nodes -out Root64.cer

For example:

openssl req -newkey rsa:4096 -days 3650 -x509 -nodes -out Root64.cer

step2

Our root certificate to sign our requests is in place. Time to get the final configuration for the CA set up. Create the following in C:\SSLAutomationTool1.0.1\tools\openssl:

  • myca.conf
  • certindex
  • serialfile
  • a folder “tmp”

casetup1

Next edit serialfile to contain “000a” (without the quotation marks). The file named certindex can remain empty and myca.conf will contain the openssl configuration for our CA:

[ ca ]
default_ca = myca

[ crl_ext ]
# issuerAltName=issuer:copy #this would copy the issuer name to altname authorityKeyIdentifier=keyid:always

[ myca ]
new_certs_dir = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\tmp
unique_subject = no
certificate = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\Root64.cer
database = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\certindex
private_key = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\privkey.pem
serial = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\serialfile
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = supplied

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage = serverAuth,clientAuth

Now our CA is completely set up and ready to sign. The next step is creating the certificate signing requests. To make life a little bit easier we can actually pre-populate some common information in the ssl-environment.bat located in C:\SSLAutomationTool1.0.1.

step4The creation of the signing requests is rather simple as can be seen in the following screenshot.

step5Before we actually sign the certificates we should double check that the requests actually do contain all the fields which are required. This can be achieved by running the following command.

openssl req -in <path to csr> -noout -text

For example:

 openssl req -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.csr -noout -text

step6

The signing is another simple command line.

openssl ca -batch -config myca.conf -notext -in <path to csr file> -out <destination path of crt file> -extensions v3_req -extfile <path to csr_openssl.cfg created by the automation tool>

For exmpale:

openssl ca -batch -config myca.conf -notext -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.csr -out C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.crt -extensions v3_req -extfile C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\csr_openssl.cfg

step7This should result in a certificate that fulfills all the requirements which can easily be verified by issuing the following command.

openssl x509 -in <path to crt> -noout -text

For example:

openssl x509 -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.crt -noout -text

step8

If your certificates do meet the requirements you are ready to follow the last part of KB 2044696 to actually get them into a format the tool can work with and replace them.

Generating certificates for use with the VMware SSL Certificate Automation Tool
http://kb.vmware.com/kb/2044696

A couple of things that you should double check before starting to replace the certificates for vCenter Server and all other components are:

  • Check C:\Programdata\VMware\VMware VirtualCenter\SSL, if you find sso.crt, sso.key and sso.pfx in that folder work through KB 2048202 (http://kb.vmware.com/kb/2048202)
  • Check C:\Programdata\VMware\VMware VirtualCenter\vpxd.cfg to contain a service ID and NOT(!) the string vCenterServer
  • Check http://kb.vmware.com/kb/2041600 for other known issues
  • Be sure to have a complete system backup including a backup of the vCenter database and SSO database
Categories: SSL Tags:
  1. No comments yet.
  1. No trackbacks yet.