Loading
SNOW Linux Agent on Secure port

We are trying to get our unix and linux agents working over HTTPS port 443, but using a self signed certificate.  

The unix agent configuration file has a setting as below which seems to work

<IgnoreUnknownCA>true</IgnoreUnknownCA>

Does anyone know the equivalent configuration setting for linux in /etc/snowclient.conf?

Thanks in advance!


  • Community Manager (Flexera Software)

    Hello Matt, For the older 1.6.x - 1.9.x versions of the Linux clients, that functionality is not available as it was only used in the Windows and Unix clients. For the current 5.x clients, the Linux client has the capability to perform that function. The configuration in the snowagent.config would have to have a line added in the <SystemSettings> section. For example; <SystemSettings>           <Setting key="software.scan.rpm" value="true" />           <Setting key="env.data_dir" value="data/" />           <Setting key="env.log_dir" value="data/" />            <Setting key="http.ssl_verify" value="false" />           <Setting key="env.java_home" value="%JAVA_HOME%" />           <Setting key="software.scan.jar" value="true" />           <Setting key="software.scan.running_processes" value="true" />       </SystemSettings>
    Expand Post
    • Thanks Arron. We got it working for Linux, however it turns out the Solaris unix agents were by working on https and are the ones we are now having trouble with!  Any advice on similar settings for Solaris unix?
      • Community Manager (Flexera Software)

        Hello Matt, Sure thing. For Unix clients 1.1.01 - 2.0.03 the setting would be to use the <IgnoreUnknownCA>true</IgnoreUnknownCA> tags. That tag can go anywhere in the upper part of the configuration of the XML. Example; <?xml version="1.0" encoding="UTF-8"?> <SnowConfig xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xsi:noNamespaceSchemaLocation="snowconfig.xsd">     <SiteName>CUSTOMER</SiteName>     <OutputPath>/etc/opt/snow</OutputPath>     <StoragePath>/var/opt/snow</StoragePath>     <HardwareScan>true</HardwareScan>     <SoftwareScan>true</SoftwareScan>     <DebugLogging>true</DebugLogging>     <PostResultsToIDR>true</PostResultsToIDR>     <IDRAddress> http://Customer:80/TransferXmlFile.ashx </IDRAddress>      <IgnoreUnknownCA>true</IgnoreUnknownCA>     <OracleScan>true</OracleScan> For Unix clients 5.0.x and above (AIX, HPUX, Solaris), the setting would be the same as the aforementioned Linux configuration setting. Example; <SystemSettings>         <Setting key="software.scan.rpm" value="true" />         <Setting key="env.data_dir" value="data/" />         <Setting key="env.log_dir" value="data/" />          <Setting key="http.ssl_verify" value="false" />         <Setting key="env.java_home" value="%JAVA_HOME%" />         <Setting key="software.scan.jar" value="true" />         <Setting key="software.scan.running_processes" value="true" />     </SystemSettings>
        Expand Post
  • Arron, The   <IgnoreUnknownCA>true</IgnoreUnknownCA> does not address the issue (and btw the config file you sent above does not use https). According to the logs, the above setting is taken into consideration but the client still expects a valid certificate. Which is weird as the Linux client can connect very well over https with the same IDR. So one would assume that the IDR does sent back to the client an SSL certificate which is accepted by the Linux client but not by  the Solaris agent. There are two explanations to this: - the Solaris client does not accept the SSL certificate sent by the IDR (probably because the IgnoreUnknownCA does not work) - the IDR does not actually sent any certificate at all (so either the Linux client does not in fact use https or it has some hard coded stuff that allows it to simulate some sort of https traffic) A tcpdump will shed some light into this. Bottom line, I can't believe we are the only customer wanting to setup Solaris clients over https.
    Expand Post
    • Community Manager (Flexera Software)

      Hi Cosmin, The <IgnoreUnknownCA> setting, if set to true, should yield a warning in the log if correctly implemented: You are trusting all server certificates. This is not recommended. You can turn on debuglogging to yield more information, using the following setting: <DebugLogging>true</DebugLogging> This will generate a larger log file, which you can submit to Snow Support for analysis and further troubleshooting.
      Expand Post
      • Daniel, See below: 2017-09-05 12:25:19.415 - - You are trusting all server certificates. This is not recommended. 2017-09-05 12:25:19.417 - - - Read client key store. 2017-09-05 12:25:19.418 - - - No client key store file found. 2017-09-05 12:25:19.438 - - - ProxySelector Request for https://snowinventory.lseg.stockex.local:443/TransferXmlFile.ashx 2017-09-05 12:25:19.463 - - - Looking for HttpClient for URL https://snowinventory.lseg.stockex.local:443/TransferXmlFile.ashx and proxy value of DIRECT 2017-09-05 12:25:19.465 - - [sun.net.www.protocol.https.HttpsClient.] - Creating new HttpsClient with url:https://snowinventory.lseg.stockex.local:443/TransferXmlFile.ashx and proxy:DIRECT with connect timeout:-1 2017-09-05 12:25:21.510 - - - Proxy used: DIRECT 2017-09-05 12:25:21.653 - - Couln't generate xml file. Couldn't POST to https://snowinventory.lseg.stockex.local:443/TransferXmlFile.ashx - Probably you need server or client certificate. java.security.cert.CertificateException: No name matching snowinventory.lseg.stockex.local found 2017-09-05 12:25:21.654 - - Stopping Snow Inventory Client for Unix Regards C
        Expand Post
        • Community Manager (Flexera Software)

          Cosmin, It looks like the certificate of the server you are trying to connect to doesn't match its hostname. I would recommend you double-check that the certificate issued to the server is issued for the same CN as the hostname (i.e. issued to snowinventory.lseg.stockex.local). Please read the following answer on Stack Overflow for a better understanding of the underlying problem: java - CertificateException: No name matching ssl.someUrl.de found - Stack Overflow   Hope this helps! Regards, Daniel
          Expand Post
          • Daniel, Good catch. The certificate issued on the IDR was using the wrong name (snowinventorydatareciever.lseg.stockex.local instead of snowinventory.lseg.stockex.local) I have added snowinventorydatareciever.lseg.stockex.local to local /etc/hosts on my Solaris client for a quick test. But got this error: 2017-09-06 11:49:43.243 - - Running as root user. 2017-09-06 11:49:43.249 - - Running on java version: 8 update: 77 (1.8.0_77) 2017-09-06 11:49:45.904 - - Hardware scan done. 2017-09-06 11:56:25.592 - - Package manager scanned for software. 2017-09-06 13:17:28.832 - - Running processes scanned for software. 2017-09-06 13:22:27.592 - - Software scanning complete. 2017-09-06 13:22:27.665 - - Host name discovered. 2017-09-06 13:22:28.160 - - You are trusting all server certificates. This is not recommended. 2017-09-06 13:22:32.896 - - Couln't generate xml file. Couldn't POST to https://snowinventorydatareciever.lseg.stockex.local:443/TransferXmlFile.ashx - Response from server = '404 - Not Found' 2017-09-06 13:22:32.898 - - Stopping Snow Inventory Client for Unix Thanks and regards C
            Expand Post
            • Community Manager (Flexera Software)

              Cosmin, If my suspicions are correct, you need to turn on XML transfers in the IDR configuration tool: You also need to install and configure the Snow Integration Manager (SIM) to pick up and parse the incoming files. Best regards, Daniel
              Expand Post
              • We can have somebody check that but it was my understanding that was already turned on. We were able to send files via http. We hit the issues only when we switched t o https Will get someone and update you shortly Thanks C
                Expand Post

Related  Product Forums


                     → Flexera One



                      → Snow Atlas



                      → FlexNet Manager



                      → Snow License Manager



                       → App Broker


       Need help finding an answer?


        Ask a Question →


Loading
SNOW Linux Agent on Secure port