The following is a guest post from Murray Peters (@MurrayPeters), Senior Consultant and founding team member at Crayon Australia. Murray shares his depth of knowledge in Flexera products built up from working with organizations around the world over many years to put innovative solutions in place to meet some of the toughest challenges and requirements.

Many thanks to Murray for contributing his insights and expertise on this topic.

Connect with Murray on LinkedIn.

Introduction

It is now common for technology teams to be managing devices that are predominately disconnected from the corporate network environment. This post discusses how client certificates can be configured to ensure mutual TLS (mTLS) authentication occurs between beacons and FlexNet inventory agents operating in a Flexera One ITAM/FlexNet Manager Suite system.

With mutual authentication:

• FlexNet inventory agents installed on client computers ensure that a trusted certificate is installed on beacons that it communicates with; and
• Each beacon only allows devices that have a trusted certificate to connect.

This post assumes a reasonable level of prior knowledge about generating, using and configuring certificates to secure HTTPS communications.

Use case / requirements

The techniques described in this post may help in situations where the following requirements are relevant:

1. You have a significant number of devices that are predominantly disconnected from the corporate network. These may be:
   • Work-from-home users that (almost) never physically join your network
   • Work-from-home users that use VPN connections to sometimes join your network
   • Work-from-home users that on any given day could be working from home, or visiting an office
   • Other managed devices that are not connected directly to your network, but do have internet connectivity (for example, devices that are connecting to InTune).
     
     
2. FlexNet inventory agents are to deployed to these devices and must continue to operate while disconnected from the corporate network, including uploading inventory and usage data.
   
   
3. To ensure a beacon is available to agents both within and external to the corporate network, inventory beacons will be configured that are accessible to these agents. This kind of beacon is considered an “Internet-facing beacon”.
   
   
4. Since an Internet-facing beacon is exposed to the entire Internet, it must be secured as tightly as possible to avoid deliberate or inadvertent abuse.
   
   
5. Historically, authentication of communications initiated by the FlexNet inventory agent has commonly been achieved by using encrypted credentials stored on the agent device, and using authentication over https.
   
   
6. A more robust solution is now supported by FlexNet inventory agents called Mutual TLS which utilizes both server and client certificates to ensure the integrity of all communication between beacons and verified devices.

This post covers the necessary configuration and discusses relevant assumptions/limitations to handle this type of scenario.

Configuration overview

The following diagram gives an overview of the configuration that is described in the following sections:

Beacon / IIS configuration

A key aspect of this entire use case is controlling what certificates are chosen/presented by the client and server machines:

• The IIS binding configured on the beacon server is explicitly linked to a single chosen certificate, so you are in full control over that definition.
  
  
• However, client machines are left to choose one of a set of available certificates when using “Client Authentication”. In an interactive (web UI) based scenario, a browser would typically prompt the user with a list of candidate certificates and allow the user to choose a certificate to use for authentication. However the FlexNet inventory agent runs without any user interaction, so the underlying system will select a certificate automatically. If careful attention is not given to getting the configuration right, the agent may choose an inappropriate certificate.

This section describes how a Client Hint sent from the beacon is used to ensure the client chooses an appropriate certificate. This is based on specifying a “Trusted Issuer” list of acceptable certificate authorities (CAs) that the client certificates must be issued by.

To configure Internet Information Services (IIS) and other settings on the beacon:

1. Enable sending of a trusted issuer list (which is off by default in Windows), and set client authentication mode with the following registry entries:
   

   [HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
   "ClientAuthTrustMode"=dword:00000001
   "SendTrustedIssuerList"=dword:00000001

2. Set HTTPS bindings and update to specify the certificate store location that contains the list of acceptable client certification authority (CA) that are to be trusted. It is recommended to use “Client Certificate Issuers”, which can be done using the netsh command as follows:

   netsh http show sslcert
   netsh http delete sslcert ipport=0.0.0.0:443
   netsh http add sslcert ipport=0.0.0.0:443 certhash=<CERTHASH> appid={APPID} sslctlstorename=ClientAuthIssuer

   Note: you may need to add the binding through the IIS administration UI, then use the above command to view/note the certhash and appid of the certificate you registered.

3. Ensure that the appropriate CA certificate(s) are present in the “Client Certificate Issuers” certificate store location (and that a full chain of trust can be established through to the root CA certs etc).
   
   
4. Enable the “Require SSL” and “Require Client Certificates” options on the following virtual directories in IIS that the agent communicates through:
   • ManageSoftDL (Download location used for downloading policy and settings)
   • ManageSoftRL (Reporting location used for uploading of inventory, usage, logs, etc)

Agent configuration

Generate a single certificate to be deployed to all client devices. This certificate would typically be signed by your organization’s internal CA.

On Windows devices:

• Import the certificate into the store location Machine Certificate/Personal Certificates, ensuring the private key is available.

On devices running Unix-like operating systems (Mac OS X, Linux, Unix etc):

• There is no systemwide store for certificates. Instead, FlexNet inventory agents will look for certificate PEM files at the following locations (by default - these locations may be changed through agent preference settings):
  

  Path	Purpose
  /var/opt/managesoft/etc/ssl/cacerts.pem	Public keys to be trusted, including your organization’s internal CA public key
  /var/opt/managesoft/etc/ssl/client/client_cert.pem	Public key of the client certificate, which is typically signed by your organization’s internal CA
  /var/opt/managesoft/etc/ssl/client/private/client_key.pem	Private key of client certificate

Runtime process

The following steps are performed when a FlexNet inventory agent (client) process makes a connection to a beacon (server):

1. The client establishes a connection to the beacon
   
   
2. The server presents its certificate to the client, and the client validates/acknowledges the trust
   
   
3. The server is configured to require a client certificate, so it provides a hint to the client which includes the list of trusted issuers it will accept. This list of issuers is comprised of the CA’s found in the “Client Certificate Issuers” certificate store location on the server.
   
   The client must present a certificate issued by one of these CA’s.
   
   
4. The client selects a certificate where the Issuer matches one of those in the hint provided by the server.
   • For the FlexNet inventory agent running on Unix-like operating systems, the choice of certificate is dictated by the agent configuration which points to the certificate to be used.
   • For the FlexNet inventory agent running on Windows operating systems, the certificate is chosen from those available in the Machine Certificate/Personal Certificates store location.
     
     
5. Once the client certificate is validated by the beacon, IIS will then enforce the remaining authentication options configured for the web application/virtual directory. Since the client certificate check is always enforced and must be satisfied, it is reasonable to leave “Anonymous” authentication enabled to complete the access and the process will continue to execute as the user configured against anonymous authentication (by default IUSR).

Tip: It goes without saying that testing of the configuration is critical as there are likely to be 100s or 1000s of client devices. Without leveraging the client hint discussed here you may see in testing that it appears to work fine because the client can authenticate to the beacon, but unless you can confirm/validate which certificate was chosen by the client you may have just been ‘lucky’ that the certificate presented by the client happened to be a valid one.

One useful way to conduct testing is to set up a simple web page in IIS with the same configuration and use a browser to visit it. You should be prompted by the browser with the list of certificates the client can choose from and that way you can confirm that the client hint is being sent and having the desired effect. You can then confirm success/failure for the authentication by choosing valid/invalid certificates.

Assumptions and limitations

1. It is assumed that any load-balancers, reverse proxies, firewalls etc between the agent and beacon can successfully and transparently participate in the exchange of certificates and trust validation.
   
   
2. Certificate Revocation Checks
   
   It may be reasonable to set the agent’s CheckCertficateRevocation preference to False to disable certificate revocation checks as certificates involved are limited to only those issued by your organization.
   
   This is optional, but if revocation checks are enabled the agent will need to be able to reach the CRL distribution lists which may add an unnecessary connectivity dependency.
   
   (Note: the setting is specific to the FlexNet inventory agent and does not affect any other process on the agent machine).

3. Certificate Deployment/maintenance.
   1. It is common to deploy the certificate at the time the FlexNet inventory agent is installed, however consideration should be given to the best way to deploy/renew certificates for if/when that may be required in the future.
   2. For devices running Unix-like operating systems: It makes sense to include the certificate as part of the agent install kit as the PEM files must reside on the file system and the agent is configured with those locations.
   3. For devices running Windows operating systems: The system level Certificate Store is used, but deploying the certificate could either be done as a management practice, or via agent upgrades.
      
      
4. Use of the “ClientAuthTrustMode“ setting in the registry on beacons is optional and influences what certificates must be located in the “Client Certificate Issuers” store location on client devices
   

   [HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
   "ClientAuthTrustMode"=dword:00000001

   Refer to the following Microsoft Docs article for a detailed explanation of the values ClientAuthTrustMode can have: Overview of TLS - SSL (Schannel SSP)

Final notes

There are various ways to configure and use mutual TLS – this post describes one of them that I have found useful.

Here are a range of links and other references that contain a range of related information, including discussing some other approaches:

• Flexera documentation:
  • IT Asset Management Online Help > Configuring Mutual TLS
  • Gathering FlexNet Inventory > Common: Supporting Mutual TLS
  • What's new in Flexera One > Support for Mutual TLS on UNIX-Like Devices