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) []:workspace.myvirtualife.net
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:

-----BEGIN CERTIFICATE REQUEST-----
MIICuzCCAaMCAQAwdjELMAkGA1UEBhMCSVQxFzAVBgNVBAgTDkVtaWxpYSBSb21h
Z25hMRYwFAYDVQQHEw1SZWdnaW8gRW1pbGlhMRUwEwYDVQQKEwxNeVZpcnR1YUxp
ZmUxEzARBgNVBAsTCk5ldHdvcmtpbmcxCjAIBgNVBAMUASowggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQC6XP30PjkBqv7f1K9KKDm5gqdJLh8l9E8S28TQ
pEHzWcoIAnMezkFmGZUpIiQch53dABEAzJoNjQT5rGl8+Dfzghn6gK/0KreiqT7H
Yz+YQqiYofQ9u6yUOPo6I/ZsbagWUnTQ1E4n30IizY/UoVpt592dyy2+qay7xAZU
Yu0LG71dsG1TfclflgBh1PjRSGyrSaYTrm0ZlV2V5r74SZlLHtlGISxRG9Khsdmg
Fnkdybxr2CcM/lvwMN63rZXaYx9n9zr8/4qbOVNVo6o5PN9f+rllss1CKddr8Y03
n+IK9c1Y5H2BnK0RJBJELT2fRmulbVpV60Uo4u+bEFe/9oSXAgMBAAGgADANBgkq
hkiG9w0BAQUFAAOCAQEAQIw6kkW3VEY1gRUYqq/m2FxmpKlfJQzDxoe0DjSW7lJz
QcJlc25rPRi9ZsLe9/+1RcpAwJPMBii6ZyBIqtp2dwqpgSjn4bPa1nOE1YDnwlOe
NrX5wSe9JOnGL1FXhfyuALd+dVFRHhX/aAQU//klcfC8QHIVPtD78EffHVciENza
ckVl1L86CWAg2fWnZmvku9DYEbHNS1MhpJLgXBM3Yf7+kFt+PorO2AxF2SL82PBE
DVzdRT8nFeP9heaU0Jia0ByVKS873KoAuQFbm9cf++uNdCbZE02RRDTzYcREqD0Y
zNVsrfGVFJj8xRNJ1qgGu4wz5k9SnHnevMzq8DB9FQ==
-----END CERTIFICATE REQUEST-----

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:
    Data:
        Version: 0 (0x0)
        Subject: C=IT, ST=Lazio, L=Roma, O=MyVirtuaLife.Net, OU=IT Department, CN=workspace.myvirtualife.net

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.