How We Worklet: Certificate Configuration Assistant

In this video, join Senior Security Engineer, Randall Pipkin, as he discusses his newly scripted Certificate Configuration Assistant Worklet in today’s episode of How We Worklet.

The Certificate Configuration Assistant Worklet will allow you to distribute and configure proxy certificates for workstations or applications that don’t use your native operating system's trusted root store. Put another way, the Worklet allows you to manage environment variables and certificate bundles on systems across your environment in a consistent way.

Video Transcript:

Hello and welcome to this installment of How We Worklet.

My name is Randall Pipkin. I am a Senior Security Engineer with Automox and today I'm going to take you through the CertificateConfiguration Assistant Worklet. The purpose of the Worklet is to allow you to distribute and configure proxy certificates for workstations or applications that do not use the native operating system's trusted root store.

While it's not a super common problem for mainstream applications. There are a number of development tools and development applications that don't use the native trusted root store. So let's take a few minutes to understand the problem that we're trying to solve before we jump into the Worklet.

Native applications in some environments are able to connect directly to the internet and enforced proxy environments. This isn't the case, traffic has to transit through a proxy or a secure web gateway.

These proxies and secure web gateways uh typically need to impersonate the service that you're talking to on the internet when using encryption. To do this, proxies will typically create certificates in the name of the service that you're communicating with. They do this using an internal certificate authority or a managed certificate authority. If you're paying for a service, these certificate authorities signed certificates for the services.

These certificates are then validated against the operating system. Trusted root store by the application. Usually, your trusted root store will contain the internal CA or the managed CA from these proxies. So these applications can validate certificates from the proxy.

Once it's been validated, then it will allow traffic to flow through the proxy and out to the internet and while developer tools and applications do have a similar connection profile to native applications, there are some differences in how they handle certificates. Similarly to native applications, connections must go through the proxy. They receive back the impersonating certificate, but the certificates are not checked against the operating system's trusted root store.

Instead, these applications come bundled with certificates on disk. They do, however, offer a way to look in custom locations for certificate bundles typically through environment variables.
these environment variables. Tell the application to go pick up a certificate bundle from the disk. The certificate bundle is then used in order to validate the certificate received in the proxy. As long as the C. A. From the proxy is in the certificate bundle, it is a valid certificate and then traffic is allowed to flow through the proxy and out to the internet and this is where this Worklet comes into play.

Developer systems vary widely depending on the language and use of the tools and use for the developer. This Worklet allows you to manage environment variables and certificate bundles on systems across your environment in a consistent way. Now that we've covered the problem that we're solving with the Worklet, let's go ahead and take a closer look today we'll be demoing the Windows Worklet for the certificate configuration assistant. Both the Windows and macOS Worklet work very similarly. the evaluation code points to some variables that are set within the remediation it is our recommendation that you should start with the remediation code.

First, fill out all of the variables there to make sure that they align with the environment configuration that you want, and then come back up to the evaluation code and synchronize. The evaluation code will first check to see whether or not each of the variables is found. If any of the variables are missing. It will run remediation. Also, it checks to see whether or not the certificate bundle exists.

If it's missing from the operating system. It will also run remediation for convenience. We have included an always run option with the ‘always run’ option. It will always run remediation and the remediation code below.

We can see that there are a number of variables that need to be set. The variables array is a list of variables that you would like to be set in the system. Environment variables for your Windows or macOS systems.

Each of these variables will be set to the path of the certificate file down below this is the bundle file that gets created with all of the trusted roots as well as the certificates that you include either in the Worklet or that you already place on disk.

The temporary files option is the paths to the certificates that you provide on the system or they can be the paths that you're referencing for the Worklet. If you're including certificates with the Worklet, we do include a commented-out section to the right with an example of path relative settings for work-included certificates.

An important note is that the java application keystore updates part of the script does not run unless you have temporary files set. If you want to have key stores updated for java applications, then you will need to ensure that certificates are either placed on disk and referenced here or included in the work and referenced here as a part of the Worklet and ensure that the name of the certificate bundle is as you want it as well as the location that it's going to be placed on the disc. Also, include or update any java applications that have certificate stores on disk that you would like to be checked when remediation runs. It checks to make sure that the output path of the certificate bundle exists. If it does not exist, then it goes ahead and creates it. Then it checks to see whether or not the certificate bundle file exists. If that file does exist, then it removes the read-only flag from the file so that we can update it after it's removed the read-only flag, it then goes and dumps all of the public keys out of the trusted root store.

It will then append the temp certificate files included in the work or those specified within the temp files and appends them to the end of the trusted certificate bundle. after that. It locks down the bundle file to ensure that it is not writeable except to administrators of the system.

It then grants read-only permissions to all operators. It then grants read-only permissions to all users on the system to allow unprivileged users to use the file and then sets the read-only flag to ensure that it is not Modifiable. We then do a check to ensure that the certificate bundle file was created in the event that it wasn't created successfully. Then the script will end here assuming it was created successfully.

We then go and check each of the environment variables. If they don't exist, then we create them Then we iterate through each of the defined java applications we look for key store files and if we find keystore files, then we attempt to update them using the key tool.

An important note, Keys store files may have passwords, we do include a static default password that's common amongst development applications. You may need to come up with a more dynamic way of handling that. If your environment requires it

Now let's go ahead and run the Worklet and show some of the symptoms of what happens before it runs as well as what to expect after it's finished Opening up the device control for our testing device. I'll scroll down and choose the Worklet appropriate for your system. In this case, we're running a Windows Worklet so I'll go ahead and run it on this device on the system before the Worklet executes.

One of the easy ways to check whether or not this may be a problem for your environment is to find a workstation that has python and just try a simple git request. So we'll go into python on this environment that doesn't yet have the Worklet run we import requests and then we try to use requests in order to reach out to something on the internet.

If certificate validation is an issue, you will notice a certificate error in validating the certificate chain by now the Worklet should have run so let's go ahead and close the existing terminal. In order to check whether or not the Worklet is run, open up the start menu and search for environment variables. Choose the ‘edit system environment variables’ option under environment variables. You can then see that system environment variables have been set in the system variable section.
In order for these changes to take effect, you may need to log out and log back into the device. Once logged back in, you should be able to check if the environment variables are set within your terminal, Running set you can look back through your environment variables and identify whether or not they are present. As you can see from this capture, you see the AWSC bundle which is one of our configured ones as well as the SSLCA path has been set now.

When we run python again and attempt to reach out to a webpage, it should work as desired. Now that we've demonstrated the Windows Worklet, I will briefly demonstrate the same functionality on the macOS side. I go into the Automox console, find my macOS device, and then run the Worklet.

Now, before the Worklet has a chance to take effect, I'll look at my existing environment. I'll do a quick check to make sure that none of the environment variables that were populating exist right now. If we were to run python we should see a similar error as we saw on the Windows machine. Yep. So python in this configuration will not work.

So similar to Windows, you will have to restart mac applications in order for them to receive the changes. However, unlike Windows, you should not need to log all the way out of your profile and log back in, simply quitting out of the application and restarting it should be sufficient.

So right click the application down in the task. Select quit and then reload it. Once the terminal is reloaded, you could run ENV and then grab for the variables that you have loaded into your environment. Now that the environment variables are there, we should be able to run python without any problem.

Thanks for tagging along for the demo. We hope the demonstration was helpful and that you find the Worklet useful in your environment. See you soon.