cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why is it necessary to supply certificate chain for non-windows agents?

The title is self explanatory. For non-windows agent deployment, we are required to export the certificate chain for SSL communication to work. Why can I not install the root certificates and have the agent communicate with the beacon without having to specify or install a certificate file? Why should you need to use your own trust store instead of using the OS trust store?


The trigger for this question is that each time an identity certificate is renewed, this approach will require redistribution of the certificates which is a major administrative overhead.


Please provide a full justification. If there is a way to make the agent use the OS trust store, please describe so that future implementations may remain immune to this problem.

(1) Solution
tferguson
By Level 3 Flexeran
Level 3 Flexeran

To begin with, you should not be required to supply the full certificate chain to the FlexNet inventory agent, just to the web server.  You only need to supply the root CA of the chain (which is generally valid for many years).  The FlexNet inventory agent is able to validate a certificate chain supplied by the web server against a root CA.  In this way, server certificates and intermediate CA certificates can be updated without the need to replace the certificate on the agent.

The FlexNet inventory agent has not used an OS supplied certificate stores for two reasons:

  1. There has been a lack of confidence that such a store can be reliably discovered on all supported types and versions of UNIX and UNIX like operating systems.
  2. It has allowed customers to pin trust to a one or more root CA certificates which the customer has supplied (we have had requests to allow such a pinning behavior for Windows as well).

However, there may be scope to add an option to enable OS supplied certificate stores and to specify paths to those stores where they would not be obviously found (e.g. not in directories such as /etc/ssl/certs, /etc/pki/...).  Please consider raising an enhancement request.

 

View solution in original post

(2) Replies
tferguson
By Level 3 Flexeran
Level 3 Flexeran

To begin with, you should not be required to supply the full certificate chain to the FlexNet inventory agent, just to the web server.  You only need to supply the root CA of the chain (which is generally valid for many years).  The FlexNet inventory agent is able to validate a certificate chain supplied by the web server against a root CA.  In this way, server certificates and intermediate CA certificates can be updated without the need to replace the certificate on the agent.

The FlexNet inventory agent has not used an OS supplied certificate stores for two reasons:

  1. There has been a lack of confidence that such a store can be reliably discovered on all supported types and versions of UNIX and UNIX like operating systems.
  2. It has allowed customers to pin trust to a one or more root CA certificates which the customer has supplied (we have had requests to allow such a pinning behavior for Windows as well).

However, there may be scope to add an option to enable OS supplied certificate stores and to specify paths to those stores where they would not be obviously found (e.g. not in directories such as /etc/ssl/certs, /etc/pki/...).  Please consider raising an enhancement request.

 

Thank you, that makes a lot more sense. Going back to the documentation, I am now reading the information as it might have been intended after reading your notes. 

I suppose the confusion arises from the article - How to setup https SSL TLS to secure and encrypt internal FNMS. 

You need to copy/combine the content of all your SSL Certificates in a Base-64 encoded X.509 format (including the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- header and footer lines for each certificate) from all your https Beacons to the file. If you're using a Certificate issued by a Certificate Authority, you only need to include their certificate chain (which has a longer expire date than the actual certificate) starting from the Root Certificate on top then the Intermediate Certificate of the Certificate Authority after.

An enhancement allowing usage of OS store would certainly be valuable, I will put one in.