Tag: HTTPS

Use the IGEL UMS as a CA Root server? I’m not saying that you should, I’m just saying that you could. For your LAB etc..

By Fredrik Brattstig @virtualbrat

2022 November 09
Did you know that the IGEL UMS has a built-in Certificate Authority? A Certificate Authority (CA) is a service to create a certificate chain, allowing you to sign communications of servers and clients (and a few other things) in an infrastructure environment.
While setting up your CA Root Server, it creates CA Root Certificate. The CA Root certificate is used to issue (sign) certificates for your infrastructure services, like a web server for instance. Certificates are required to successfully use SSL communications between Clients and Servers. If a CA Root has signed a certificate for a Web Server to allow the webserver to communicate with SSL aka. HTTPS traffic and you distribute the CA Root certificate to your endpoints, the endpoints will automatically trust the WebServer, allowing for Secure HTTPS traffic without security warnings for the user.

As said, you can have the UMS act as a CA Root, and can create signed certificates for your services. Actually, all UMS server installs have this feature enabled by default, as IGEL is using certificate-based communications for secure communications between the IGEL UMS and the IGEL OS endpoints.

Within the UMS Console, You can find the section Certificate Management->Web and this is where I would go to issue my own certificates and export the root certificate. Then there are baked-in tools, to convert exported certificates to the formats you’ll need. Let’s look at an example, but first, how does a certificate hierarchy allow for a smooth and secure User Experience?

The above picture describes the fundamentals of a CA root – Server – Endpoint relationship. The CA Root has signed the certificate that is used by the Server to prove its identity. As the Endpoint trust the CA Root certificate, it will then accept the certificate that the Server provides to establish a secure connection.

IGEL has made it very easy to create signed certificates, now let’s dig into how, and Why?!

Here is the UMS Console and we have opened up UMS Administrations->Global Configuration->Certificate Management->Web. We have selected the CA Root certificate, and highlighted “Export Certificate”.

And this is the export dialogue for the root certificate. This will now export the CA Root certificate to a .crt file, which can then be imported to the Trusted Root certificate Authorities to your endpoints, allowing them to trust any Server that is signed by the CA Root.

Now, I will create a certificate, and I want to have this certificate be valid for multiple DNS hostnames (Certificates can be created to validate hostnames, IP-addresses, etc.). In the example I want to create a certificate for webserver.virtualbrat.local (which will be assigned to my webserver, plus I will also add the DNS name webserver.virtualbrat.com (which will be the external, internet-facing name of the same webserver).
BTW, you can even generate a new Root certificate, with your own naming at your own wish, for simplicity, I will use the Root certificate that was created automatically when my UMS was installed.

To start creating your certificate, rightclick the CA Root and select “Create signed certificate”
A small wizard opens, but I will select “I don’t need your help” as I’m going to customize my certificate
We then fill out the required information, one nice thing is that you can specify the validity of the certificate to whatever you want. I decided to make my cert valid for the next 100 years. (Keep in mind, this is just for LAB purposes). Then click “Manage hostnames”
Here we can then write the DNS names that will be added as Subject Alternate Names (SAN) to the certificate, eg specifying which hostnames the certificate should be valid for. I’ll add “webserver.virtualbrat.local” and “webserver.virtualbrat.com”
Done, let’s click “Close”
And now, click “Ok” to create the certificate!
Now, the UMS has created our certificate
As a test, we can right-click the certificate and export it quickly
I’ll choose to export it as a .crt and will place it on the desktop.
Looking at the certificate we see that it has two SAN’s webserver.virtualbrat.com and webserver.virtualbrat.local

Now, we cannot really use the exported certificate for our web server, there are some more requirements. We will need a .pfx file to be able to import the certificate in a Windows Webserver (IIS) in my example. So we will need to export the certificate in a different format.

Rightclick and select “Export certificate chain to keystore”
You will need to password protect the exported certificate
Name the output file and click “Save”

I have now extracted the certificate chain, but it was extracted as a .jks format, which is not what I need to import the certificate to my Windows Webserver. I will need to convert that file to a .p12/pfx to allow for import to my IIS, as IIS doesn’t understand .jks formats. The UMS comes with a command line tool for that. According to the below code-snip, keytool.exe can be used to convert the .jks file to .p12


"c:\Program Files\IGEL\RemoteManager_jvm\bin\keytool.exe" -importkeystore -srckeystore webserver.jks -destkeystore webserver.p12 -deststoretype pkcs12
Keytool.exe usage to convert .jks to .p12

The .p12 file can then be imported to the server that is hosting the web-server, and the webserver.virtualbrat.local / webserver.virtualbrat.com website.

So, when this all has been done (it looks like a long process, but when you try it it isn’t, especially when comparing it to other ways to create certificates) we are now ready to test if the certificate works and will provide a secure HTTPS connection for my Endpoints that are trusting the CA Root certificate. First of all, we need to assign the CA Root certificate to our IGEL OS endpoints, and we do that according to the IGEL KB article: https://kb.igel.com/endpointmgmt-6.10/en/files-registering-files-on-the-igel-ums-server-and-transferring-them-to-devices-57321597.html

And it should look like this when the certificate has been added as a file object to the UMS and been assigned to your IGEL OS endpoints:

UMS console showing the certificate file-object and the assigned IGEL OS endpoint

Now, that this has been done, it is time to test access to my web-server from an IGEL OS endpoint. I do that simply from a Firefox Browser session.

The goal was to have a certificate on my web-server, without setting up a complete PKI infrastructure. This page shows that the task is successfully completed! (“Verified by: IGEL Technology GmbH” note is due to that I used the Root certificate that was created while installing the UMS, if you want a different name, you can create your own Root certificate)

The conclusion to this article is that you can use the IGEL UMS as a Certificate Authority, and issue certificates to your LAB environment instead of going the very long way of setting up your own Certificate Authority on for instance a Windows domain, which is a way heavier task!

And yes, you can use the certificates described in this article to provide HTTPS/SSL certificates for your infrastructure, like Citrix Storefront’s, etc.. But that’s out of the scope of this blog!

Hope you liked this exercise!

/Fred