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.


2 Responses to Using a Microsoft CA to generate certificates for Horizon Workspace

  1. Pingback: How to replace Horizon Workspace self-signed certificates with Microsoft CA certificates | MyVirtuaLife.Net

  2. Pingback: Page not found | MyVirtuaLife.Net

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: