Linux devices not able to upload to beacon (OpenSSL unable to get local issuer certificate)

[gilesogram]

We are using zero touch to collect inventory form a few Linux devices. The inventory is running correctly (i.e. username etc all correct).

However the upload fails (as see in the tracker.log) with the following error:

Error 0xE1BBFC14: OpenSSL error 0xFC14: unable to get local issuer certificate

and they are unable to create and upload inventories.

We have tried to add the IP and also the FQDN in the BeaconEngine.conf file, but this has made no difference.

The beacon and FNMS are running HTTPS and their certificates are valid.

Do we need to get a local copy of those certificates installed on the Linux devices, or a copy of the RootCA added to the Linux?

[ChrisG · Accepted solution]

Unfortunately file upload using HTTPS protocol is not directly supported for UNIX-like platforms when using zero-touch inventory.

See some commentary about this on the following page in the Gathering FlexNet Inventory guide (search in the page for the string "ssl"): Zero-Footprint: System Requirements

[ChrisG · Accepted solution]

Yes, deploying the agents (with an appropriate certificate configured) would allow data to be uploaded using HTTPS. Beyond just the HTTPS considerations, having agents deployed is typically a more robust and reliable approach for gathering inventory than using the zero-touch approach. The zero-touch approach is very sensitive to factors such as network connectivity, having credentials for remote access configured, target devices being online, etc.

[ChrisG · Accepted solution]

Unfortunately file upload using HTTPS protocol is not directly supported for UNIX-like platforms when using zero-touch inventory.

See some commentary about this on the following page in the Gathering FlexNet Inventory guide (search in the page for the string "ssl"): Zero-Footprint: System Requirements

[gilesogram]

Thanks for the update.

Would it then be better to get the agents deployed on those Linux devices instead?

[ChrisG · Accepted solution]

Yes, deploying the agents (with an appropriate certificate configured) would allow data to be uploaded using HTTPS. Beyond just the HTTPS considerations, having agents deployed is typically a more robust and reliable approach for gathering inventory than using the zero-touch approach. The zero-touch approach is very sensitive to factors such as network connectivity, having credentials for remote access configured, target devices being online, etc.

[gilesogram]

So latest update is that we can get the ndlaunch command to run direct from a Linux machine to the beacon HTTPS URL.

However, when we try the task from a discovery/inventory rule on our beacon, it seems to discover correctly, and create an inventory, but we get the following error when trying to upload:

2024-03-05 16:34:12,098 [.BasicInventoryVisitor| rules-9] [INFO ] Queued zero touch inventory on device 'linux02'
2024-03-05 16:34:36,147 [.BasicInventoryVisitor| rules-9] [INFO ] ---------------------------------------------------------------------------------------------------------------------
2024-03-05 16:34:36,147 [.BasicInventoryVisitor| rules-9] [INFO ] Finished processing task of type 'TaskType_Inventory' on target 'x.x.x.112' with result '-3'
2024-03-05 16:34:36,147 [.BasicInventoryVisitor| rules-9] [INFO ] Result of type 'TaskType_Inventory' on target 'x.x.x.112':
<TaskStatus Result="Failed" StartDateTime="2024-03-05T16:34:12" Type="Inventory" Status="RemoteExecutionFailedReturnedNonZero" Duration="24.01">
<Step Result="Success" Type="SSHCopyAgent" Status="SSHExecutionSucceeded" Credential="Linux" Duration="2.44">
<CommandLine>C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\pscp.exe -batch -q -ln &quot;Linux&quot; \\beacon\mgsRET$\Inventory\ndtrack.sh \\beacon\mgsRET$\Inventory\ndtrack.ini \\beacon\mgsRET$\Inventory\InventorySettings.xml x.x.x.112:.</CommandLine>
</Step>
<Step Result="Failed" Type="SSHCommandRunAgent" Status="SSHExecutionOnRemoteHostReturnedNonZero" Credential="Linux" Duration="21.19">
<CommandLine>C:\Program Files (x86)\Flexera Software\Inventory Beacon\RemoteExecution\plink.exe -t -batch -ln &quot;Linux&quot; x.x.x.112 &quot;sudo /bin/sh ./ndtrack.sh -t Machine -o UploadLocation=&quot;&quot;https://beacon.dcss.dev/ManageSoftRL&quot;&quot; -o LogModules=&quot;&quot;default&quot;&quot; -o IgnoreConnectionWindows=&quot;&quot;true&quot;&quot; -o ShowIcon=&quot;&quot;false&quot;&quot; -o PolicyRevisionNumber=&quot;&quot;165&quot;&quot; -o RuleID=&quot;&quot;9&quot;&quot; -o SessionUID=&quot;&quot;2ea9222d-6bb5-480c-8130-5aae4052b942&quot;&quot; -o IncludeDirectory=&quot;&quot;&quot;&quot; -o CALInventory=&quot;&quot;False&quot;&quot;&quot;</CommandLine>
<ProcessStdOut>[sudo] password for user:
ManageSoft Inventory agent 21.0 -&gt; Build 678
Copyright 2023 Flexera Software LLC
----- Gathering inventory
&gt; Initialising
&gt; Searching for hardware
&gt; Searching for Oracle database instances
&gt; Searching for Oracle listener
&gt; Searching for software
&gt; Searching the native package database
&gt; Symantec Storage Foundation Tracking Started
&gt; IBM MQ Queue Manager Tracking Started
&gt; IBM Db2 tracking started.
&gt; Started Jboss tracking
&gt; Generating inventory &apos;/var/tmp/flexera/tracker/inventories/system on linux02.ndi&apos;
&gt; Compressing inventory &apos;system on devmgtter02.ndi&apos; to &apos;mgs82255128.ndi.gz.tmp&apos;
&gt; Uploading inventory
*** Error: Error (s189m263)
*** FlexNet Manager Platform could not upload the inventory.
</ProcessStdOut>
<Parameter Index="0">7</Parameter>
</Step>
</TaskStatus> 

[jpreuss · Accepted solution]

Hi gilesogram,

as a preface: I have no experiences of zero touch inventory.

According to your log snippets the first part of the task is the establishing of a ssh channel from the beacon to the customer system. The beacon itself is providing the PuTTY ssh clients. These are wellknown, but the behaviour is different to the "real" ssh clients. In meantime Microsoft is providing ssh client applications as part of their OS.

In ssh is provided a different key pairing mechanism for authentication without passwords.  Then there will be no password question.

But what happens then? They are firing the ndtrack command with options to collect the data and transmit them back  with another transport technology (the standard https transport). So they have to provide not only the access with ssh, they also have to provide the full https backchannel connection suite with name resolution, PKI certificates, network socket connection to the beacon system etc. 

If someone is doing this zero touch things, then it is consequent to also collect the harvest with ssh and deploy it to the incoming directories of the beacon, normally populated from the agent-beacon-technology.

If you are going this path along your snippet, then you have to prepare the user environment of the  ssh servicing system with full support for the choosen backtransport. Like in case of the complete flexera agent.

With kind regards, Jürgen

[gilesogram]

So we think that the linux agent has a set of scheduled tasks that will collect the inventory and upload to the beacon. That has been checked by running 'ndschedag -e' and the log files show the uploads are working to the HTTPS address of the beacon.

[jpreuss]

Hi gilesogram,

for my purposes the tool "curl" is very helpful in testing connections with beacons. It is available on all agent platforms and has a myriad of options. You can select special DNS servers and different certificate keystores.

By default Flexera has choosen a private keystore (like java stacks), where the certificate chain of your beacon(s) has to be placed. But possibly your main platform keystore in Linux has already the right certificates in place.

You can test it with "curl https://<flexbeacon>". On every platform curl is compiled with platform standards, so it will use windows keystore on windows and on Linux according your distro.  It is well suited to debug all your problems with networks, name resolution and TLS content on protocol level.

If you detect, that the CA Certificate chain of the beacon is already available, than you can easily replace the generated "cert.pem" to the location of your system keystore.  In case of our RedHat systems it is

/var/opt/managesoft/etc/ssl:
drwxr-xr-x. 4 root root 46 Aug 29 08:30 .
drwx------. 3 root root 35 Aug 30 08:09 ..
lrwxrwxrwx. 1 root root 49 Aug 29 08:30 cert.pem -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
drwxr-xr-x. 2 root root 25 Aug 30 08:09 crls
drwxr-xr-x. 2 root root 6 Aug 29 08:30 ocsp

But you have to follow the allowed naming conventions of the beacon certificate (extended by Alternate Names option). 

And if you are going down with curl to the network stack, you for shure want to debug the CRL access too. Again curl is your friend. But please recognise, that every CRL connection is done without TLS-encryption; it is port tcp/80 connection with http ("curl http://<pkicrl>" or seldom LDAP without TLS). This might have some discussions with your security guys, but this are widely unknown basics of TLS technology.

Inside organisations there is often a usage of different proxy technologies. The proxies are not transparent in there doing. Often there is implemented a interception of TLS encrypted traffic, connected with forging of TLS certificates. Avoiding proxies will simplify your jobs.

With kind regards, Jürgen