Common: Supporting Mutual TLS

IT Asset Management (Cloud)

Communication using the HTTPS protocol between a client (such as a target inventory device) and a server (such as an inventory beacon) is secured by Transport Layer Security (TLS). Traditionally this has been standard (or single-sided) TLS, where the server has a certificate that the client must verify before communicating. In more security-conscious environments, it may be necessary not only to validate that we are communicating with the correct server, as proven by its valid certificate, but also to be certain that only an authorized client device can join the communication. Enter mutual TLS, where both the client and the server must be authorized by separate valid certificates before the communication may proceed.

Setting up the inventory beacon for the server side of mutual TLS is documented in the online help (see IT Asset Management Help > Inventory Beacons > Local Web Server Page > Configuring Mutual TLS.) In contrast, this topic provides a few introductory notes for setting up the client side of mutual TLS on your target inventory device. In fact, there are many possible methods for obtaining and managing client-side certificates, and your enterprise may already have its preferred process. In that case, use your preferred process. IT Asset Management does not mandate any particular process, nor does it provide tools for managing, distributing, or installing client-side certificates.

Remember: Once an inventory beacon has been configured for mutual TLS (specifically, configured to require a client-side certificate before communicating), it is impossible for an inventory device that does not have a client-side certificate to communicate with that inventory beacon for any reason:

• It cannot download device policy, schedule changes, or software updates
• It cannot upload any status changes, nor any collected discovery results or inventory files.

Also keeping in mind that the locally-installed FlexNet Inventory Agent is not tied to a particular inventory beacon, but assesses for each download/upload which inventory beacon is the most appropriate (for example, has the fastest response times), the decision to implement mutual TLS is typically a system-wide one (or at least, one that covers all devices within distinct boundaries, such as clearly defined subnets).

You only need one client-side certificate, as the same certificate (after export to the appropriate format) can be distributed to multiple inventory devices. Unlike the case with server-side certificates, you do not need a separate root certificate that attests to the Certificate Authority itself for this client-side certificate.

Setting up client-side certificates for mutual TLS (overview):

1. Obtain your client-side certificate from an appropriate Certificate Authority.

   One way to do this is to prepare a certificate signing request (CSR) in the same way (perhaps even at the same time) as you prepare one for a server-side certificate for one of your inventory beacons, using IIS on that server (for details, see Configuring Mutual TLS in the online help, step 7).

   An alternative method is to use the MMC snap-in for Certificates, which has the advantage of running on any Windows computer where you have administrator rights. Instructions can be found online (for example, https://www.msb365.blog/?p=3886).

2. When the certificate is received back from the Certificate Authority, import it into the Certificates (Local Computer) > Personal store on the same working computer (perhaps your inventory beacon) where you created the CSR.

   In this case, this certificate is not for attaching to the IIS bindings on the inventory beacon, and we import it into a personal store just to facilitate exporting in the appropriate formats for your Windows and UNIX-like inventory devices.

3. From the working store, export the client-side certificate (including the private key) into .pfx format. For example:
   1. Right-click the certificate file in the list for your chosen store, and select All Tasks > Export... to start the Certificate Export Wizard.
   2. On the welcome page, click Next.
   3. On the Export Private Key page, select Yes, export the private key, and click Next.
   4. On the Export File Format page, select Personal Information Exchange – PKCS #12 (.PFX) and then check Include all certificates in the certification path if possible. Click Next.
   5. On the Security page, select Password, and create and confirm the password (keep a note of this password in your enterprise-approved system, as it is required when you import the certificate with private key to other Windows devices).
   6. Click Next, and in the File to Export page, browse to a path and add a file name to save your exported certificate. Click Next.
   7. On the final page of the wizard, confirm your settings, and click Finish.
4. Deploy the exported client-side .pfx file to target inventory devices running a Windows operating system, using your preferred method (and having the password you created to protect the private key available for the installation process).
   Tip: For the server-side certificate, recall that the root certificate for your CA must be in the Trusted Root Certification Authorities store on both the inventory beacon and all the client inventory devices that are communicating with the inventory beacon. This may mean that you have an opportunity to deploy both certificates (the root CA certificate, and your client-side certificate) to your Windows-based inventory devices within the same process.
5. For target inventory devices running UNIX-like operating systems, a different format is required that provides the certificate and the private key in separate .pem files. One method of conversion is to use the openssl toolkit, available through https://www.openssl.org/source/, on a convenient Windows device where you have openssl and a copy of the .pfx file you are deploying for Windows devices.
   1. To extract the private key from the .pfx file to a .pem file (this file still includes the password protection):

      openssl pkcs12 -in filename.pfx -nocerts -out key_with_pass.pem

   2. To remove the password from the private key file just created:

      openssl rsa -in key_with_pass.pem -out client_key.pem

   3. To export the certificate without the private key (but still including the necessary public key) in a .pemfile:

      openssl pkcs12 -in filename.pfx -clcerts -nokeys -out client_cert.pem

   4. Open the resulting certificate file in your preferred flat text editor (such as Notepad), delete all preliminary lines of text before -----BEGIN CERTIFICATE-----, and save the amended file.
6. Use your preferred deployment method to install both files on target inventory devices running UNIX-like operating systems:
   • Deploy the certificate file to /var/opt/managesoft/etc/ssl/client/client_cert.pem
   • Deploy the key file to /var/opt/managesoft/etc/ssl/client/private/client_key.pem.

   Tip: If you are deploying new devices where you are installing FlexNet Inventory Agent for the first time, you can include both the certificate file and the key file in the deployment package, as described in Agent Third-Party Deployment: Installing FlexNet inventory agent on UNIX.
7. For target inventory devices running UNIX-like operating systems, you must also set three preferences to their new values in the config.ini file that serves as a pseudo-registry on these devices. For more details, see:
   • AddClientCertificateAndKey (which must be set to True)
   • SSLClientCertificateFile (which must give the file path for the .pem certificate file)
   • SSLClientPrivateKeyFile (which must give the file path for the private key).

When the client-side certificates are deployed to your target inventory devices (along with the CA root certificates needed for validation of the server-side certificates), and the additional preferences have been set for UNIX-like platforms, you are ready to run this environment with mutual TLS verification of secure communications using the HTTPS protocol.