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.
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.
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
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:
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 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!