Using vCSA 6.0 as a Subordinate CA of a Microsoft Root CA

One of the nicest improvements in vSphere 6 is the ability to use the VMware Certificate Authority (VMCA) as a subordinate CA.
In most cases enterprises already have some form of PKI deployed in house and very often it is Microsoft based so I will show you how I did it with a Microsoft Enterprise CA.

I give for granted that the Microsoft PKI is already in place, in my case it is a single VM with an Enterprise Microsoft CA installed.

The vCSA should also be already be in place.

As first step I edit the certool config file but first I make a backup of the default configuration:

mkdir /root/backup
cp /usr/lib/vmware-vmca/share/config/certool.cfg /root/backup
vi /usr/lib/vmware-vmca/share/config/certool.cfg

Compile the config file with the parameters that are good for your setup then save the file and exit.

Now we have to generate a certificate request for the VMCA to pass to the Microsoft CA and there are many ways to do that, I am going to use the vSphere Certificate Manager Utility that will automatically take most steps for me:


Screen Shot 2015-03-29 at 23.20.25
At this point I have the .csr file (/root/root_signing_cert.csr) and the private key (/root/root_signing_cert.key) so let’s feed it to the Microsoft CA as you normally would for any certificate request using the “Subordinate Certification Authority” template:

Screen Shot 2015-03-29 at 23.25.43Now you have to take the crt file in base64 format on the vCSA and also the Microsoft CA root certificate in base64 format as well; copying files with SCP will be a challenge because the root user on the vCSA by default doesn’t use the bash shell so if you want to use this method you need to edit the “/etc/passwd” and set the root user to use bash as a shell and then you can put it back as it was once you are done transferring the files.

It could be just simpler to open the certs on your computer and the connect to the vCSA via SSH and copy the content inside new files; one way or another you need to take the certificates on the vCSA, in my case they are “root_signing_cert.pem” and “cam.pem”.

Now we need to combine the two files in a chain file:

cp root_signing_cert.pem caroot.pem
cat ca.pem >> caroot.pem

If you open the “caroot.pem” file you should see a single cert file with both ca and certificate one after another.

Now we can go back to the vSphere Certificate Manager Utility to apply this certificate:

Screen Shot 2015-03-29 at 23.36.16

Since we have already edited the certool.cfg file we just have to confirm the values that the wizard proposes, just remember to enter the FQDN of the vCenter server:

Screen Shot 2015-03-29 at 23.37.18
If you have a successful outcome you can connect via browser to your vSphere Web Client and check the certificate:

Screen Shot 2015-03-29 at 23.39.59

Screen Shot 2015-03-29 at 23.40.08


As you can see now this is a trusted connection and the VMCA has released certificates for the Solution Users on behalf of the Microsoft Root CA.

You can check the active certificate in the vSphere Web Client in the Administration section:

Screen Shot 2015-03-29 at 23.42.30

In case you decide to remove the original root certificate then you will have to refresh the Security Token Service (STS) Root Certificate, and replace the VMware Directory Service Certificate following the vSphere 6 documentation.

Now the VMCA is capable of signing certificates that are valid in you PKI chain and are trusted by default in you Windows domain by all clients.


How to replace Horizon Workspace 1.0 self-signed certificates with Microsoft CA certificates

UPDATE: If you are deploying Horizon Workspace 1.5 you should look at this post.

In the last post we generated new certificates from an internal Microsoft CA to use them as replacement of the Horizon Workspace self-signed certificates that are created during the setup process.

For certificates to work correctly, all parties in the process need to trust the Certification Authority; this include all servers and clients involved in the Horizon Workspace deployment.

Because of this, before applying the new certificates to Workspace virtual appliances we need to add our internal Microsoft CA to the list of trusted Certification Authorities; this step is not needed if you are buying certificates from a public CA that is already trusted, Verisign can be an example.

In this phase you will need to connect via ssh to all 5 virtual appliances with the user ‘sshuser’ (password is the same as ‘root’) and raise to ‘root’ with “su -“; you will then copy the CA certificate (ca.pem if you followed my previous post) via SCP in the home directory of user ‘sshuser’ then do the following:

cp /home/sshuser/ca.pem /etc/ssl/certs

Then do the following on the service-va and connector-va virtual machines:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /usr/java/jre-vmware/lib/security/cacerts

In my case:

/usr/java/jre1.6.0_37/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /usr/java/jre-vmware/lib/security/cacerts

And run the following on the data-va:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/horizon_private_root_ca.pem -alias horizon_private_root_ca -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts

In my case:

/opt/zimbra/jdk1.7.0_05/jre/bin/keytool -import -trustcacerts -file /etc/ssl/certs/ca.pem -alias vsphere-va -keystore /opt/zimbra/jdk1.7.0_05/jre/lib/security/cacerts

Note: The password to import the CA in the store is “changeit”.

Note: If you have an intermediate CA certificate you will have to run the same commands for that certificate too.

At this point your internal CA should be trusted but at times I’ve seen this happening only after a reboot of all virtual machines, so let’s just stop the vApp and restart it.

Changing the certificates is a less tedious process and it can be performed entirely using the web interface. Open your browser and connect to the Workspace admin page, in my case and go to “Settings” -> “View Virtual Appliances System Configuration”:


Then click on “SSL Certificate” and paste certificate (horizon.pem) and private key (key.pem) from the files we created earlier, then press “Save”:


You will get a green box as a confirmation.
Now go to “Module Configuration” -> “Go To Connector”:


Now go to “SSL Certificate” and do the same as you did before pasting certificate and private key:


Now you should be able to connect back to the Workspace admin page and notice that you are running with the new certificates, and in my case i have no certificate warning because my workstation is domain joined and by default it trusts the Microsoft CA:


Well that’s great, isn’t it?

There’s still a lot of work to do to complete our environment but are well on our way.

More in the posts to come, see you there!

Using a Microsoft CA to generate certificates for Horizon Workspace

During installation of Horizon Workspace in the last post we used self-signed certificates for simplicity but when you will put Workspace in production you will definitely want to replace those certificates.

In this post we will use an internal Microsoft CA to request certificates for our Horizon Workspace implementation.

Note: The installation of a Microsoft CA is outside the scope of this article.

If you connect to your Horizon Workspace FQDN you will see the classic browser warning when you connect to an SSL website which certificate has been released by a Certificate Authority you don’t trust.

In fact if you take a close look at the certificate you will easily notice the following:


You can see how we don’t trust the CA as it is stated in red and as you can see from the certificate tree at the top.

We need to create a certificate request to pass to our Microsoft CA so that it can process it and spit out a certificate for us. There are several tools to create certificate requests but i like to use OpenSSL because it is available on almost every operating system so if you learn how to do it from that you will be able to do it in most situations.

The steps i am going to take will work on every platform, regardless the fact that i will do this on a Mac you will be able to take the same steps on a Windows box. You can find OpenSSL binaries for Windows here.

On a Mac, open a Terminal window, move to the “/bin” directory of your OpenSSL installation and run the following commands:

sudo openssl genrsa -out key.pem 2048
sudo openssl req -out horizon.csr -key key.pem -new

After running the second command we will be presented with a few questions to compile in order to create a certificate request:

Country Name (2 letter code) [AU]:IT
State or Province Name (full name) [Some-State]:Lazio
Locality Name (eg, city) []:Roma
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MyVirtuaLife.Net
Organizational Unit Name (eg, section) []:IT Department
Common Name (e.g. server FQDN or YOUR name) []
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

The first command will generate a private key (key.pem) that we will use for our request, the second command will actually create a request file signed it with the private key we just created.

The request file (horizon.csr) can be opened as a text file and it should look like this:


This will be correctly interpreted by the CA as a valid request but we won’t be able to read it. If you want to check if everything is ok you can do it like this:

openssl req -text -noout -in horizon.csr

You will see plenty of info and among that you will find those you inserted in the request:

Certificate Request:
        Version: 0 (0x0)
        Subject: C=IT, ST=Lazio, L=Roma, O=MyVirtuaLife.Net, OU=IT Department,

Note: The common name value is what your browser checks to be the same of the website you are trying to access, if different it will throw an error.

To pass the request to a Microsoft CA just access the web portal of your CA and click “Request a certificate” -> “advanced certificate request” and then paste your request as follows:


Select “Web Server” then click “Submit” and download the Base 64 encoded certificate:


You should get a file called “certnew.cer” that i normally rename in “horizon.pem”.

You should also get the CA certificate file, to download it go back to the homepage of your CA and click on “Download a CA certificate, certificate chain, or CRL”, the you should be here:


Select “Base 64” and then “Download CA certificate”.
Whenever you download a certificate from a Microsoft CA it will be called “certnew.cer” so you can see why it’s a best practice to rename them, i usually call this “ca.pem”.

At this point we should have the following:

  • key.pem (private key)
  • horizon.pem (the horizon workspace certificate)
  • ca.pem (the certification authority certificate)

Clarifying the certificate formats chaos
Every guide you will find out there that instructs you how to generate certificates will most of the time do a bad job explaining the various kind of formats, the difference between them and when to use one kind or another. Since i don’t want to take credit for something i didn’t do i want you to know that the following is taken from this webpage where you will also be able to convert different types of certificates if you need.

When you are dealing with certificates you will find different formats such as pem, der, p7b, and pfx. A Windows server for example exports and imports .pfx files while an Apache server uses individual PEM (.crt, .cer) files. The following is a definition of the various formats i mentioned.

PEM Format:
The PEM format is the most common format that Certificate Authorities issue certificates in. PEM certificates usually have extensions such as .pem, .crt, .cer, and .key. They are Base64 encoded ASCII files and contain “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–” statements. Server certificates, intermediate certificates, and private keys can all be put into the PEM format.

Apache and other similar servers use PEM format certificates. Several PEM certificates, and even the private key, can be included in one file, one below the other, but most platforms, such as Apache, expect the certificates and private key to be in separate files.

DER Format:
The DER format is simply a binary form of a certificate instead of the ASCII PEM format. It sometimes has a file extension of .der but it often has a file extension of .cer so the only way to tell the difference between a DER .cer file and a PEM .cer file is to open it in a text editor and look for the BEGIN/END statements. All types of certificates and private keys can be encoded in DER format. DER is typically used with Java platforms.

PKCS#7/P7B Format:
The PKCS#7 or P7B format is usually stored in Base64 ASCII format and has a file extension of .p7b or .p7c. P7B certificates contain “—–BEGIN PKCS7—–” and “—–END PKCS7—–” statements. A P7B file only contains certificates and chain certificates, not the private key. Several platforms support P7B files including Microsoft Windows and Java Tomcat.

PKCS#12/PFX Format:
The PKCS#12 or PFX format is a binary format for storing the server certificate, any intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.

%d bloggers like this: