Agent Third-Party Deployment: Enabling the HTTPS Protocol on UNIX Agents

IT Asset Management (Cloud)
The FlexNet Inventory Agent (or more precisely, its component executables) may make use of the HTTPS protocol for communications with inventory beacons. Whereas Windows systems can manage the security certificates for you, on UNIX and OS X some manual configuration is required.
Tip: The options for checking certificates and checking certificate revocation are supported in networks using the IPv4 or IPv6 address families.
Note: The HTTPS protocol is only available to the installed agents, and is not available to the zero-footprint FlexNet Inventory Scanner.
Remember: Each inventory device may choose which inventory beacon it contacts at any given time, so that a decision to secure communications is normally a blanket decision covering your whole computing estate.
There are three security levels which can be enabled for HTTPS, using two preference settings. From the highest level of security to the lowest, these are:
  • Checking certificate(s) and excluding revoked certificates
  • Checking certificate(s)
  • Relying on encryption.

Checking certificate(s) and excluding revoked certificates

Authenticating HTTPS communications between the client (inventory device) and server (inventory beacon) may be achieved in either of two methods:
  • Using unilateral (single-sided, or 'standard') TLS, where the client validates the server certificate(s)
  • Using mutual TLS, where each side validates certificates offered by the other.

In both these cases, the client (inventory device) checks each HTTPS server certificate (from each inventory beacon with which it communicates). Checking the HTTPS server certificate involves having a local copy on the inventory device of all the public certificates (which may come from multiple certificate authorities (CA)) that are used to validate the HTTPS server certificates. These certificates must be available in the /var/opt/managesoft/etc/ssl/cert.pem file on the managed device (or an alternative folder — see Agent Third-Party Deployment: HTTPS CA Certificate File Format (UNIX) for more details). The device must also be able to download the certificate revocation list from an HTTP location, and/or perform an OCSP check for certificate revocation.

Only in the second case of mutual TLS, in addition to the above, when the AddClientCertificateAndKey preference is set, the managed inventory device provides the server (inventory beacon) with a client certificate that the server either accepts or rejects (for example, it may reject the certificate as being invalid, or expired).
Tip: The inventory beacon does not save the client certificate locally, and does not require a chain of public certificates to authenticate the client certificate (and therefore it cannot check whether the client certificate has been revoked). This is a simpler check for both validity and the fact that the certificate has not expired. The server may be configured to:
  • Accept any valid, current client certificate that it is offered (but also allow HTTPS communications without a certificate)
  • Ignore all client certificates (allowing HTTPS communications without any certificates)
  • Require a valid, current client certificate before allowing any HTTPS communication with a client.
For this level of security (using either form of TLS), both the CheckServerCertificate and CheckCertificateRevocation settings on the inventory device should be set to True (these are the default settings). When these are both true, a number of other settings can come into play, a few of which can be configured in the mgsft_rollout_response file that assists with deployment (see Agent Third-Party Deployment: Configuring the Bootstrap File for UNIX), and others must be modified in the /var/opt/managesoft/etc/config.ini file that functions in place of the Windows registry for UNIX-like platforms (see Agent Third-Party Deployment: Updating config.ini on a UNIX Device). The additional preferences are:

Checking certificate(s)

This mid-level security model provides an encrypted channel and validation of either the HTTPS server (with standard TLS) or both the client and the server (with mutual TLS), but does not provide a way to check whether the certificate used to validate the server has been revoked. This may be adequate where you are confident of the longevity of your certificates, perhaps because you are using an internal certificate authority.

Checking the server certificate still requires that the CA certificate is installed on the target inventory device in the /var/opt/managesoft/etc/ssl/cert.pem file (and/or the alternative folder). If you are using mutual TLS, you have the AddClientCertificateAndKey preference set, and the inventory device still presents its certificate to the inventory beacon. As well, the CheckServerCertificate preference on the client must preserve its default value of True. Ignoring the revocation list is configured by disabling (setting to False) the CheckCertificateRevocation settings for all component agents on the managed device.
Tip: It is also possible to generally disable for most agents, but create exceptions where a particular agent still checks for possible certificate revocation. For details, see CheckCertificateRevocation. (If you override the behavior for particular agent components, you may need to review the revocation settings listed above for the same components.)

Relying on encryption

If you are confident of the security of your infrastructure, it is possible to ignore the server certificates entirely. This provides an encrypted channel of communication, but does not provide validation that the device is actually talking to the correct HTTPS server.

Disabling checking of the server certificate can be achieved by disabling (setting to False) both the CheckServerCertificate and CheckCertificateRevocation settings for all component agents on the managed device. In this mode of operation, the CA certificate is not required on the managed device.

IT Asset Management (Cloud)

Current