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

Summary

Flexera Software Vulnerability Manager components have built-in security mechanisms for the validation of the target server they connect and submit scan data to.  This 'CRL check' as it's called, has the sole purpose to confirm that the data the Agent has collected (or Daemon) is sent back securely. For more information and details on what online CRL validation websites must be white-listed, see this KB.

Symptoms

SVM Agents are installed successfully on the domain clients and the Agent service is running fine.
Few or many of them, however, fail to report back check-ins and scan results to their master server.

Or

SVM Daemon fails to submit data back to its target server to which it connects and reports back to.
It could also happen that the Software Vulnerability Manager IE Plugin or SCCM Plugin fails to load too. 

Agent's (or Daemon's) log file displays the following WinHttp error which prevents any of the aforementioned to communicate successfully to Flexera Cloud servers. No scans are received timely. 

[Date and Time] Error when sending WinHttp request (12175) 
[Date and Time] Connection error....
[Date and TIme] Error in HttpRequest: status=499, StatusText="A security error occurred' ,winCode=12175

Cause

In 99% of the cases, the root cause is blocking somewhere on the network. It could be the local area network, the domain network, or security controls on the boundaries of the network perimeter. This issue can be reproduced by blocking all URLs on the local Windows Firewall and triggering an Agent scan in the command-line interface, as easy as it could happen without expectation when some security networks have explicit deny procedures in place to disallow everything that is not explicitly allowed on the corporate firewall, the corporate proxy, or another security device with blocking/filtering functions. 

User-added image

Flexera Support sees the following problems more often than not at the customer sites:

a) The required online CRL URLs for certificate revocation are not all white-listed at the Proxy/Firewall.
b) There is a Proxy on the network, but the client(s) facing WinHttp 12175 have netsh proxy set = Direct. 
c) Content-inspection Proxy is stripping the original certificate and the security validation breaks.
d) The Agent/Daemon/Plugins are run with user credentials insufficient to bypass the Proxy/Firewall.

Solutions

The first and most appropriate solution which Flexera suggests to customers is to avoid workarounds and to whitelist the required by the Software Vulnerability Manager online CRL URLs at the Firewall/Proxy of your network. Other workarounds may not work as best as white-listing the product. 

Agents / Daemon can be routed to submit their scan data through a Proxy. You can route the Daemon via its setup wizard interface. You can route the Agent out with the command-line option '-x proxy:port'.
You should use the SVM Agent proxy logic workflow that shows how exactly to install it against a Proxy. 

Daemon: 

This routing is custom and it's done by setting proxy forwarders (f.e. in the registry) that directs all Agents or Daemon outbound traffic to the correct Proxy server that makes sure the path to CRL servers is cleared, at least to the best of your controls. Your job is to get it bypassed through your network. 

User-added image

The following figure shows a Wireshark trace example of a CRL verification request sent by SVM Daemon.

User-added image

SVM Agent: 

The Agent can be routed in many ways as you have seen in the other KB which we referenced above. 
The simple way of forwarding the Agent for testing purposes and recommended the first use case is:

csia.exe -c -x <192.168.10.102>:<8888> [-x proxy:port]

User-added image
As part of each request for data submission to its master server where it submits all data, the Agent or the Daemon will execute a parallel security validation of the target server's SSL certificate.

CRL checks are a security mechanism used for non-repudiation purposes that is used by Windows and the Software Vulnerability Manager functionality as a whole to always make sure that the target server receiving the data is not a bogus one, that is the intended server where scan data is correlated, and that customer data is protected at maximum. Everyone should consider CRL highly in terms of security

In some circumstances, the Agent will call Windows CryptoAPI that will then send the CRL traffic through WInHttp, while the Agent is at the same time using WinInet (if that is what you configured as default). Then, your connection settings will all look good, but in essence, the Agent will be routing CRL to a wall. 

User-added image

When the netsh configuration is set to Direct, but there's a proxy you have configured for the Agent with the -x command-line parameter, the Agent is acting as a router and sending the different requests to their predefined path. Since the netsh configuration is the default proxy configuration on Windows, one of the two required network routes is closed since "Direct" will send the Agent packets to no avail. 

To see the Windows default Network Shell proxy configuration:

netsh winhttp show proxy

To configure the system default winhttp proxy to a different server:

netsh winhttp set proxy = <proxy: port>

When the Agent, Daemon, or LocalSystem proxy netsh configuration is set wrong, you will see:

WinHttp request (12175); status = 499 - "A security error occurred".

Steps To Reproduce

Replicate with SVM Daemon:

Perform these steps on a test host!

1. Install the Daemon on a client and configure the correct proxy forwarding in the installation wizard.
2. Stop the SVM Daemon service.
3. Go to Windows Registry and enable maximum verbose logging for the SVM Daemon.
4. Block the IP address at the local Firewall for the below sites (use ping to get their regional IPs):

ts-ocsp.ws.symantec.com
ts-crl.ws.symantec.com
crl3.digicert.com
crl4.digicert.com

5. In the elevated command-line interface, execute this command to clean the LocalSystem URL cache:

certutil -URLcache * delete

6. Configure LocalSystem to forward WinHttp requests through 'Direct' instead of using the right Proxy:

netsh winhttp reset proxy 

7. Restart the Daemon service and wait for some time until it performs few requests that will fail. 

User-added image

Replicate with the SVM Agent:

Perform these steps on a test host!

1. Block the IP address at the local Firewall for the below sites (use ping to get their regional IPs):

  • s2.symcb.com
  • s1.symcb.com
  • sv.symcd.com
  • sv.symcb.com
  • s.symcd.com
  • s.symcb.com
  • ts-crl.ws.symantec.com
  • ts-ocsp.ws.symantec.com

2. Clean the local machine cache:

certutil -URLcache * delete

3. Configure your system to forward WinHttp requests through 'Direct ' instead of your actual Proxy:

netsh winhttp reset proxy

4. Run a scan with the SVM Agent in an elevated command line:

csia.exe -c -x <YourProxy>:< YourPort>

At this point, the Agent will fail almost instantly with the WinHttp 12175 "A security error occurred" msg. 

Resolution

In environments where Proxy is actively used you shall re-direct your Agents / Daemon traffic through the correct proxy server using the installation interface of the Daemon, or command-line for the Agent. You can also deploy a crafted Agent package with Proxy configuration directly through WSUS/SCCM.

Your organization should ensure that URL addresses required for CRL verification of all Agent hosts, the SVM front-end interface plugins, the SCCM Plugin, and the SVM Daemon are whitelisted at the corporate Proxy and Firewall, and you should certainly avoid using content-inspection SSL filtering.

You can configure the Time-To-Live packet settings at your proxy to define how long should one CRL record be kept alive at the proxy server. Flexera recommends increasing this setting for the CRL sites to 7 days because this will ensure that your hosts can verify CRL directly against your proxy and may not even send the requests outside. The URL data will be re-cached once per 7 days by the Proxy server.

Workarounds

Disable Certificate Revocation altogether

Daemon:

Go at the registry and navigate to HKLM at:

SYSTEM\CurrentControlSet\Services\Flexera Corporate Software Inspector Daemon\

Double-click on "Image Path" entry and append at the end of the line after the "--service-launch" entry:

--ignore-crl --ignore-ca --ignore-an 

Restart the SVM Daemon service under services.msc for the changes to take immediate effect.

Agent:

You can install (run) the Agent with additional ignore settings, but Flexera discourages you from doing so. That will disable CRL check altogether for the Agent, but it could be used for getting a quick fix. 

--ignore-crl --ignore-ca --ignore-cn

Additional Information

On rare occasions, the problem would simply be that the Service Account under which Agents / Daemon is being run on Clients is not permitted to send traffic externally. Confirm that the Service Account (or LocalSystem) is granted the ability to bypass the Proxy and send traffic to Flexera Cloud (https://*.secunia.com).

Related KB Articles

https://docs.microsoft.com/en-us/windows/desktop/wininet/wininet-vs-winhttp 

https://docs.microsoft.com/en-us/windows/desktop/wininet/http-sessions

https://docs.microsoft.com/en-us/windows/desktop/WinHttp/winhttp-sessions-overview

https://blogs.msdn.microsoft.com/jpsanders/2011/02/21/certificate-revocation-list-crl-check-and-winhttp-proxy-settings/

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee619754(v=ws.10)

https://docs.microsoft.com/en-us/windows-server/networking/technologies/netsh/netsh

Was this article helpful? Yes No
0% helpful (0/1)
Comments
BobBuilder
By
Level 3

link at the top the the while lists doesn't work

 For more information and details on what online CRL validation websites must be white-listed, see this KB.

RDanailov
By Level 7 Flexeran
Level 7 Flexeran

Thanks for the catch, this has now been updated accordingly with the correct URL:

https://community.flexera.com/t5/Software-Vulnerability-Manager/SVM-Cloud-CRL-online-requirements/ta-p/4990

Kind Regards, Rosen 

Version history
Last update:
‎Dec 10, 2019 06:04 AM
Updated by: