When attempting to publish any type of package through SPS in SVM, the publishing attempt fails with the same error message stating that SPS cannot download the file from https://dl.csi7.secunia.com This error is caused by the inability of your host machine (the SVM host) to verify the 'Server certificate' of the URL at https://dl.csi7.secunia.com. Most often this is due to domain blocking, Proxy/Firewall blocking, Policy-based blocking, etc.
The failure to publish packages occurs for all packages (excluding SVM Agent) being published from that same host machine.
You see the following error appearing on your screen when publishing operation fails:
After typing the address https://dl.csi7.secunia.com the browser bar turns red showing that there's a problem.
You click on the 'lock icon' on the right side of the browser bar and you review the certificate
Under the 'Certification Path' tab, you see 2 or fewer certificate steps (while the certificate chain is composed of 3 steps.
When you look at the 'csi_pluginlog.txt' file (located in "My Documents" directory), it shows the following additional information:
Error in HttpRequest: status=499, statusText='The certificate authority is invalid or incorrect',winCode=12045
Failed to download file https://dl.csi7.secunia.com/?action=download&package=VLC_3.0.3_64-bit_SPS.exe&toke
This error is a CRL-related (certificate revocation list) issue that occurs due to the inability of the local machine (the one you host SVM onto) to access online certificate revocation servers hosted by DigiCert. The active Certificate Revocation List check is performed by the IE browser against an online web server hosted on the DigiCert domain. If access to DigiCert is forbidden for server systems or all domain-joined systems, then CRL validation will fail. The check could also fail due to "Request time out" especially where a proxy is involved. When CRL validation fails, the browser immediately prevents the requestor (in this case SVM) to proceed as it is not deemed 'Trusted'.
You can verify this by typing 'https://dl.csi7.secunia.com' in the address bar which should turn red indicated 'problems with the certificate'.
Steps To Reproduce
Remove the DigiCert Root CA certificate from Third-Party Root Certification Authorities and Trusted Root Certification Authorities certificate stores on the system.
Block access to 'DigiCert.com' domain (disallow it).
Attempt to download the package through the Software Vulnerability Manager.
There are a few ways to resolve this issue. In this section we list the fastest of them all, find the other ways under the 'Workaround' section below. Depending on your organization policies and security policies, choose the one that fits best for you: Method 1: Import the certificates directly from the browser to the local certificates stores manually
Open IE as Administrator
Enter https://dl.csi7.secunia.com in the address bar
Click on the 'icon lock' on the right-hand side of the address bar
Click on 'View Certificate'
Click on 'Install Certificate' when the certificate window appears
Install the certificate under the 'Local Machine' account and leave the wizard to place it Automatically.
When finished with installing the first certificate, go back to the certificate window.
Click 'Certification Path'
Click on the middle-level certificate (DigiCert SHA2 Secure Server CA)
Install this intermediate certificate just like you did for the first one.
When finished installing the second certificate, you will have to download the third certificate - the DigiCert Root Level CA.
If you encounter this problem, you are likely missing this certificate displayed in the certificate path
Find the certificate attached to this article and download it.
Install it as you did for the previous two.
When you are done and you reload the address https://dl.csi7.secunia.com, it should no longer turn red and it should now show you that all 3 levels of the certificate chain are listed nicely.
Publish Package without errors.
Workarounds to solve this issue include: Perform publishing from another machine that is less restricted:
Find a machine where, when entering the URL https://dl.csi7.secunia.com in the IE address bar, it displays all 3 certificate levels as Trusted (no red color in the URL)
Install the Patching plugin on Windows 8/10 workstation and connect to WSUS/SCCM on that machine
Create packages from that machine publishing them effectively to your remote server. Use this machine as 'Remote Administration Host'
This may or may not always work. If CRL blocking is done on the Firewall/Proxy, this workaround may fail as Proxy/Firewall blocks all machines equally and so the problem is widely distributed across the network.
White-list domain-wide CRL online locations on the Proxy/Firewall to resolve the problem for all affected domain hosts:
More about DigiCert Certificate Revocation Listing and validation here
Related KB Articles
WinHttp request (12175); status = 499, "A Security error occurred" SVMPatching Plugin Not Loading Correctly SCCM Inventory Import and Daemon Certificate Revocation Check Failures by Proxy SVM Cloud CRL Requirements Change of Digital Certificates after the move to AWS
"CreateDirectory Failed" error is a generic error that may be caused by multiple scenarios. Such a scenario can be moving the default for WSUS \UpdateServicesPackages\ directory physically to another drive or server without using WsusUtil.exe to register the change.
The above error occurs while publishing package due to WSUS certificate missing Private key.
Failed to publish package Code -2146233079 Failed to sign in package, error was 2148081670
This error occurs when Private key is missing from the certificate in WSUS store on WSUS server.
1. Login to Software Vulnerability Manager 2018. 2. Navigate to Patching -> WSUS / System Center -> Configure Upstream Server. 3. Go to Step 2 -> Click "Automatically create and install certificate" 4. This will install certificate as shown in the figure. .
You would need to remove / delete the previous certificate from Certificate Store before creating a new one via SVM console.
An Update Package in Software Vulnerability Manager is a security and/or critical update patch that is built based upon a scan result for a product that was identified as vulnerable by the software. In this KB Article, we provide more concrete information on the architectural design of Flexera packages.
SHA1 Error prevents you to publish packages for Google Chrome or other commercially available software.
When attempting to publish a package, SVM returns an error stating that it could not verify the SHA1 checksum of the package. As part of the error, you can see a download link pointing to the file location as being hosted by Flexera. Here is how the error looks like:
The problem is caching of old invalidated URLs which leads to incorrect download links presented in the SVMinterface.
The error message contains a download URL, which is actually the newest download link hosted at Flexera. To solve the issue, copy the URL from the error message, then do the following:
Begin creating a new SPS package
At step 1 of SPS, enable 'Edit Package Content' checkbox
At step 2, right-click on the existing link and select 'Edit'
Replace the default download link with the one you've copied from the error message.
Configure the rest of the package and publish it
Another way of doing this is to use the copied download link to download the physical file locally to your system. Then, edit the new package that you would be creating similarly to the above example, but instead of Editing the download link - remove it entirely. Finally, use the 'Add Local File' button to browse to the file you downloaded and then import it to the SVM's SPS interface. Publish your package after you configure all other desired package settings.
SVM Patching Plugin is installed with an elevated admin account but it fails to load when a web page is refreshed. It displays a '"An error occurred while loading the SVM Plugin" related to signature checksum.
This article describes the general steps that can be taken to troubleshoot a package that was published by the Software Vulnerability Manager and its Flexera Package System where the package was provided as silently installable out-of-the-box through the default installation configuration enabled by Flexera.
SPS packages as they are known are advanced installers which  contain the vendor installer that the vendor intended and delivered to the public  while also containing improvements in the package installation handling procedures that create a bridge between the WUA functionality and all the supported for silent installation third-party software vendors together with their disadvantages.
Customers using SVM or SVR solutions are welcome to contact support if they want to achieve specific scenarios with their Flexera products and that extends to patching where Support can be helpful.
A Secunia package (sps.exe) contains a minimum of two files.
One file is the script that executes the installer that comes at index 1 (2) as the second file in the package execution flow. The script sets package execution logging to occur at C:\Windows\SecuniaPackage.log. This file contains all relevant installation information regarding the SPS package and it is heavily used for detecting problems and error codes that need solving.
You should always try your luck looking at C:\Windows\WindowsUpdate.log too. Windows Update Agent handles the execution of packages for both WSUS and SCCM, and it represents the parent executory process of the SPS.exe installer threads that start underneath WUA's PID. That's where data comes first.
Troubleshooting package deployment:
Open C:\Windows\SecuniaPackage.log on the system where the package was deployed.
At this point:
If the package has started installing, it would have written anything, error or success. If the package did not write anything, then the package never started running.
Next steps: If Error
If you have an error for that same package, try finding more about it in the current KB article. If the error is not listed here, try finding another KB article in the community as there are few others. No success should leave you with a good choice to send it to Support and we'll help with our best.
Next steps: If no Error
When the package is executed it will have the type of reference as shown next: [08/18 10:59:38.257 00000fa8] Running package Deployment package for Secunia CSI Agent, version 184.108.40.206, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time)[08/18 10:59:38.267 00000fa8] GUID : 7f72ff70-1530-420a-8280-983588115663
When the Windows Update Agent runs the downloaded patch successfully, you will see return code 0.
[08/18 11:00:00.873 000003b0] Finished running package Deployment package for Secunia CSI Agent, version 220.127.116.11, created Tue Aug 18 2015 10:58:56 GMT+0200 (Romance Daylight Time) [08/18 11:00:00.885 000003b0] Returning 0
If you don't see a reference to the package, this could be caused by the deployment script not being run. You should look in WindowsUpdate.log to get an insight on what did WUA report back as a result too.
Often this log file will contain the root cause of the failure. Does it say anything about the package you are expecting? Are you able to find the package when you use Ctrl+F and the name of the package? If the answer is no, this means that your package is not applicable to that system.
Briefly explained, each package contains applicability stamped on it just like a post letter has stamps. It can and will be delivered only when the recipient of the patch, that is every client in the domain, indeed matches all required rules. Briefly, these are patch applicability, version applicability, and approval.
Finally, some particular reasons for a package failure can be:
- Internal Installer Error
- WUA executes through LocalSystem and this account doesn't have access there, where the system requires authentication with password requirements.
For instance, the LocalSystem account cannot anything that has a requirement for password exchange and authentication packages trying to install in C:\Users will fail via WUA installation because that requires a UAC permission bypass and LocalSystem can't handle the password part.
Error Codes and Useful References:
These are Windows system error codes that can be compared against: https://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx Common System error codes are :
0 (0x0) Description: The operation completed successfully.
Description: The process cannot access the file because it is being used by another process. (This could be the case while updating Adobe Flash or Oracle Java, where Java/flash is at that moment actively running in the browser or as a process and the uninstaller can not access the locked file.
Description: Fatal error during installation. Find more about this error in the hyperlinked KB article.
Description: Installation suspended, incomplete.
Description: This action is only valid for products that are currently installed.
Description: Find more about this error in the hyperlinked KB Article.
Another version of this product is already installed. The installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs in the Control Panel. This could be the case while updating Adobe Reader, where Adobe Reader installer fetches some old registry setting that point to a previous Adobe Reader update location/path/MSI file.
Detecting and removing this path from the registry resolves the issue. To do so, download the Adobe reader update installer from adobe and run it via the GUI, the installation should stop requesting an MSI file at a specific location/path. If this event occurs, you will have reversed the problem and allocated it.
Packages in which failure is associated with an MSI installer may be failing to obtain the source MSI file to proceed with software removal before update or an upgrade. Sometimes the MSI installer will be missing on the system. Then, in the middle of a BITS-orchestrated operation, the installation is blocked and no message can be returned to the user. The installer waits for a little and it times out, errors out.
Sometimes when deploying an Update Package aiming to patch your active Insecure/EOL programs, your WSUS/SCCM takes it further and applies your update as a brand new installation on machines that were not intended to install it. This article explains why this happens and how to avoid it.
You scanned few/all machines with SVM2018 and the scan engine detected Insecure/End-Of-Life programs on your systems. You go ahead and 'Create Update Package', then you publish it with the default configuration. You approve the package for your machines trusting that the update will only patch your 'regular' installations only. Your update package installs well on the machines you intended to update. However, it also goes further and it installs on machines that have not had this program before (e.g Adobe Reader). All of a sudden, you end up with an unwanted new Adobe Reader program installed on a File Server at the path 'C:\ Program Files' even though this server never had it installed before. You wonder how did that happen?
When SVM2018 update packages are deployed, they have certain 'Applicability' configuration appended to them that is been actively used for evaluation of the package applicability by WSUS/SCCM servers. One of those Applicability rules is the 'Path' rule which makes Windows Update (or SCCM) to look at the machine and compare its path/file availability against the 'Path' rules enabled in a given package. If the client(s) being evaluated have the same path location on their systems, and version of the program lower than the version of your update package, the package is then offered for installation as 'Applicable'. That's just basic deployment controls used by Microsoft deployment servers. Why does your Update Package installed on a system where it wasn't installed before? Based on its detection, the SVM will configure new packages with the Path applicability it had appended based on its scan findings:
Somewhere in the system there is a standalone program file, plugin ActiveX control file, or self-contained self-executable file which contains metadata of an active installation
This could be a file that was not removed correctly from the previous uninstall.
Such files are known to be 'zombie files'.
This could be a temporary file that was dropped upon download and never taken care of.
They may exist at locations like %AppData\...%, %Temp%, at forgotten directories at C:\Program Files\, or at alternative locations where the user had placed these.
Maybe somewhere on the system, you've got backup directory where you store legacy executable files for backward compatibility support or for other purposes?
Steps To Reproduce
Steps to reproduce the issue.
Drop any insecure executable file on any drive (internal) on your system and then run a scan.
Find your scan result in the interface and review it.
Note the vulnerable version you dropped, and see the detected path.
Go to SPS (after you have compiled your Smart Groups) and find the product package entry there.
Double-click on the entry to create a patch and move with Next to step 3 where you will see rules.
Notice that your custom path is listed there. Leave it enabled (tick the checkbox).
Publish the package and approve it for your test system
The package will appear in Windows Update / or will be installed by the SCCM if that's your server.
These behaviors are expected when the package is offered to the system after evaluation of its path applicability matches this system conditions:
If this package aimed to update existing installation on the system, the update package should update the existing components of the active installation without changing their location.
If the package was deployed by mistake (because it had path applicability of backup directory), it will run as 'Full New Install' and then it will install at its default installation directory.
To perform successful deployments you should leave enabled paths that match your company's deployment policies and match your expectations for a legitimate approved program instance installation path. It is important to pay careful attention to the enlisted paths in your SVM2018 Update Packages and recognize those paths that are not intended candidates for the type of update you create.
You may want to avoid locations such as:
Other paths that may look odd and not intended
You can look at the files and ask yourself: "Are those files portable standalone executable files?" Are these actual applications, aren't the paths odd compared to standard locations?
Determine what's OK and what's not OK to enable as Applicability for your package.
Deselect all checkboxes next to those paths and only leave enabled the ones which you approve
Add additional applicability rules if you wish to strengthen the control even more before.
Publish the package and deploy it based on the correct applicability criteria preventing unwanted deployments.
See more about "Blacklisting" and understand how you can prevent such files to be scanned and reported therefore keeping your application database clean and focused on actively used applications. You must always have a process to clean old executable leftovers, or zombie-files, that can be used as they are vulnerable nevertheless. This is a best-security practice and recommended by Flexera.
When deploying an update package for Adobe Reader the package fails to install with error code 1638.
When an Adobe Reader update package is deployed the installation fails.
Adobe Reader is not updated to the latest secure version
The update package loops in Windows Update
Error 1638 in windowsupdate.log and in secuniapackage.log
Adobe Reader comes in two versions. In this solution, we will refer to them as the consumer version and the enterprise version. The consumer version will refer to the .exe installer. The enterprise version will refer to the .msi installer. The differences are described below.
Adobe Reader EXE Installer
The .exe installed version, which is intended for consumers: - is meant to be updated through the Adobe Update Service known as ARM. It is possible to update the consumer version through incremental updates (.msp packages) but errors might occur. - does not allow for configuration prior to installation.
Adobe Reader MSI Installer [used by Flexera]
The .msi installed version, which is intended for enterprises: - is meant to be updated through incremental updates (.msp packages) deployed through whichever tool the enterprise uses for deploying updates (WSUS/SCCM/etc.). It is possible to update the enterprise version through the ARM service, but some enterprises report errors installing it. - The enterprise version allows for multiple configurations prior to deployment, and also supports the Adobe Customization Wizard tool.
In order to make our package as resilient, error-free, easy-to-use and configurable as possible, as well as complying with Adobe's best-practice, we have included the enterprise (.msi) installer. The consumer version installer of Adobe Reader is not compatible with the enterprise version installer, and the two were unable to interact with each other without resulting in an error code of 1638.
We, therefore, implemented the clean install workaround, which allows the package to uninstall previous versions of Adobe Reader, and then install the enterprise version, which is what Adobe recommends: http://www.adobe.com/devnet-docs/acrobatetk/tools/AdminGuide/basics.html#installation-best-practices The drawback of this workaround is the loss of settings, but a clean install has always been completely dependent on the uninstaller of the product, so this was inevitable. Since the workaround ensured that the enterprise version would be installed instead, the workaround only had to be applied once, after which the bug would no longer appear. This means that the bug would be a one-time-inconvenience with our workaround, rather than continuously causing issues.
The 'Download' column which is visible under any product smart group in the SVM software might result in HTTP 404 error when users click on it.
The links the customer is talking about can also be seen in PDF reports which have been scheduled to include product-related data. The links in the reports might lead to the same problems.
The download links provided in SVM in the Product Smart Groups are the same ones used in the SVM Package System for creating automatic update packages.
Direct download links are provided mostly for the software packages that exist as 'Automatic Updates' (entries in blue color in the SPS view) and partially for some partially configured packages. In any case, the direct download link is only provided for third-party software packages. Flexera does not provide direct download links to Microsoft KBs which are listed as solutions in Secunia Advisories, because Flexera does not support the creation of Automatic Updates for Microsoft software and it does not recommend it via the Software Vulnerability Manager.
Most of the provided download links are displayed as direct download links hosted at http://dl.secunia.com. When the user clicks on these links, this will result in HTTP 404 - Not Found error.
This is expected behavior and known to Flexera. The download URLs presented to you are masked partial links that are being redirected to the correct full download links when SVM downloads a package. Links provided for some Windows programs are generic links leading you to the Windows Update website from where you can download each of the KBs you require. URLs to other third-party vendors that exist in partially configured (grey) packages in SPS will land you on the generic download page used by the vendor to provide downloads. Such example is http://www.wireshark.org/download.html
When you need to download one of the files from Flexera, you should use the 'Create SPS File' inside the SPS package wizard to download the installer and then move it away from the local temp directory to one of your choices for further use.
If you strongly require direct download links for Microsoft products to be enabled, please create an Idea in the community. Product Management will highly consider your Idea if this is something Engineering can provide within the product.
Use this article to move the contents of WSUS if you need to validate the changes needed for SVM. Flexera will not support problems with this, this article is to assist you with your SVM product only.
When the ..\UpdatesPackages folder of WSUS is moved without using the WsusUtil.exe tool e.g. when enabling SSL on WSUS, then you will experience issues in publishing 3rd party patches from Software Vulnerability Manager because the change of location for the update repository is not documented.
Steps To Reproduce
1) Use File Explorer to move the content of C:\Updates or the entire folder C:\Updates.
2) Publish a package from the Software Vulnerability Manager and you will get the error message:
Code: -2147467259 CreateDirectory failed.
The original location is C:\Updates and the folder contains 2 other folders 'C:\Updates\UpdateService Packages' and 'C:\Updates\WsusContent'.
The WsusUtil.exe will move the content of the Updates folder which includes the 2 subfolders, so if only one of the subfolders has been moved to a different location it is important to move it back to the original location before using the WsusUtil.exe to move both subfolders to the desired location.
To move the content of C:\Updates to D:\Updates, use the following command:
wsusutil movecontent D:\Updates D:\Updates\movelog.txt
In case the intention was to move the 2 subfolders from C:\Updates to D:\Updates and all the data has already been moved/copied to the new location on D:\Updates or if you wish not to move the content, the procedure would then be to use the following command:
wsusutil movecontent D:\Updates D:\Updates\movelog.txt skip copy
This command will register the new location in the WSUS configuration, but it will not try to copy the data from the original location.
If the content of C:\Updates was moved with File Explore, then use File Explorer to move it back to the original location.
Reference: https://technet.microsoft.com/en-us/library/cc720466(v=ws.10).aspx Please also note that wsusutil take some time to the content and configure all the permission correctly. You may have to wait for couple of hours before you can use the WSUS and publish packages.
This article explains how you should evaluate technical problems with the installation of SPS packages. It also includes valid points and considerations to help you working with packages in a more simple and straightforward fashion.
You create an SPS package and deploy it via WSUS or SCCM server. The package ends up installing on many machines, but some/many failed to install the package. You looked at the C:\Windows\SecuniaPackage.log on the failing systems and you determined error code 1603 to be returned after installation of the SPS package initiated. You might have also noticed similar error 0x80070643 displayed in System Center Configuration Manager, or within the WindowsUpdate.log file (if publishing via WSUS).
How the failure looks like through SCCM deployments
The package that fails might be different kind - Adobe Flash, Adobe Reader, Adobe Acrobat, Java, Google Chrome, etc. You might have several different packages failing at the same time on some machines.
For example, on machine A you might have Flash and Chrome failing, while on machine B you only get Chrome failing and only Flash failing on machine C. The symptoms may vary on a per-case basis, but as long as you have these error codes you shall focus on finding which of the following causes is the source:
Missing old MSI Installer
The old-version you are trying to patch had been installed with MSI installer and this installer is no longer present on the system which makes it impossible to uninstall it.
Error code shows on the screen when you try to remove the old version manually. It says that the original MSI installer is missing and it leaves the error window pending.
This can fail the SPS packages to install correctly because the MSI installer requires input, but the input is hidden behind BITS, and the application has no way of getting to continue.
The package you deployed cannot take the 'user action' because it installs silently, which leads to the SPS package being blocked to proceed with the removal.
Eventually, Windows Update will reach timeout deadline and produce error code 0x80070643
You need to remove the previous versions by either purposely placing another Uninstall.exe in the same folder where the old MSI is looking for it, or you should remove all versions manually prior to installing anything new.
EXE vs MSI incompatibility [Most Frequently Seen]
Several major third-party vendors provide both EXE and MSI format installers which actually do not work well with each other i.e. Adobe, Oracle, Google is all in that count. When the old version that needs to be patched was installed with an EXE installer (that is the version installed on the Clients), Flexera packages may throw this error because SVM uses MSI-based installers from Adobe to patch your hosts.
To install SPS packages successfully in such cases, the previously installed software must originate from an MSI-based installer. You should use the "Clean Install" option at step 1 of SPS to cleanup the EXE from any system before your SPS update patch triggers for installation, thereby avoiding the collision since the system will be cleaned in advance through the registry Uninstall string of the old EXE installer.
3. Another SID/UID is using the process
The old version that requires patching may be used by a user at the time of applying our patch. Thus, Windows ties the process to the UID and the new package installation fails because it cannot take over the process, stop it, remove it, and update it to a newer version thereafter.
Flexera SPS packages are build to detect if a possible problem will occur and will normally produce additional exit/error code 32. When you see code 32, know that the package was canceled as it was destined to fail otherwise. It will install in the next restart at the very latest on its own.
Error 1603 and particularly 0x80070643 might sometimes be an indication that the version that is to be patched was locked to the user Security Identified (SID).
Reboot the system gracefully and the package that failed with 20/32 error will then perform gracefull installation since the user UID will have already been logged-off by the system and Windows Update has no issues to encounter in replacing the program files.
All patches fail to publish except SVM's very own Agent. The error message has no identification text or error, it simply stating that it failed to publish. In the C:\Users\<User>\Documents\csi_pluginlog.txt you find the following error: "An Error Occurred While Downloading The File:"." - HttpRequest: Status=499
You've changed nothing at the SVM host and publishing might have been working fine so far.
SVM starts throwing the same undefined error each time you attempted to publish a package. When you face this issue, the following conditions are usually met:
None of the packages listed under SPS publish successfully.
Publishing an Agent Deployment Package works, however.
The 'csi_pluginlog.txt' file in your local Documents folder displays the below error:
"Error in HttpRequest: status=499, statusText='It was not possible to connect to the revocation server or a definitive response could not be obtained.',winCode=12057"
The error is caused by CRL blocking on the local SVM host when Internet Explorer attempts to connect to http://crl3.digicert.com and http://crl4.digicert.com. Internet Explorer performs such CRL validation of each program utilizing its WinHTTP classes to forward connection requests online (also the case with SVM package downloading). See more about certificate validation security in SVM and Windows here.
The current error is being caused by GPO implicit deny restrictions applied to any site not explicitly listed as Trusted in the 'Trusted Sites' configuration of Internet Explorer. To confirm that this is indeed the problem you are trying to resolve, you need to validate the 3 bullet points listed under 'Symptoms' above. All three must be present, particularly the error message in the log file as pointed out.
Steps To Reproduce
Purposely restrict (deny) access to http://crl3.digicert.com and http://crl4.digicert.com on the machine where SVM is newly set up before publishing any patches before the blocking.
This should inevitably cause the error to occur.
Resolution to this problem is to include the following URLs to the Trusted Sites zone of the Internet Explorer on the SVM host:
http://crl3.digicert.com (package system CRLs)
http://crl4.digicert.com (package system CRLs)
http://*.secunia.com (Flexera domain trust)
http://crl.thawte.com (trust of Flexera server SSL-certificate that signs the packages sub-domain)
You may want to test the fix before making changes to the network. Use the instructions in the Workaround section for that.
To make 100% sure you can resolve this by GPO edit, you have to enforce the appropriate websites on the machine while overriding the GPO applicability.
You have only one option to do this - quickly modify the registry configuration of your browser and perform publishing before GPO is being reapplied. By default, GPO refreshes once per 90 min unless it's being configured otherwise. You have to config this quickly and check it promptly too.
Steps to override GPO locally and test package publishing;
browse to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
Right-click on 'ZoneMap' key
New > Key
Name it exactly crl3.digicert.com
Right-click on the main central window and add new Dword value and name it http
Correct the DWORD value to 2
Right-click on ZoneMap and add second New Key
Name it exactly crl4.digicert.com?
In the new window, add new DWORD again, name it http and change its value to 2
Add third value under ZoneMap and name it *.secunia.com
Yet again create a new DWORD value for this key, name it http and change its value to 2
Right-click on 'ZoneMap' key and export the settings so that you can save yourself time editing again if GPO refreshes in the meanwhile.
Restart IE using the setting 'Run As Administrator' and login to your SVM account.
Go to Patching quickly and publish any package under the 'SPS' menu (Adobe, Flash, Java, or any of the like).
Publishing succeeds. You have now confirmed that the problem is indeed GPO restriction over the CRL websites.
Edit your GPO accordingly to accommodate the required URLs for DigiCert CRL website in the Trusted Sites zone for a permanent fix.
The SVM Support team had been able to successfully resolve this problem by performing the above steps. However, Trusted Sites' applicability extends to a lot of possible custom configurations and you may end up needing to perform deeper troubleshooting or customization at the registry.
Refer to this full guide by Microsoft on how to adapt the required registry changes to your custom configuration to succeed in resolving this issue.
Related KB Articles
Cannot Publish Any Packages due to "An Error Occurred While Downloading File from https://dl.csi7.secunia.com" [error 12045]
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.
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.
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
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.
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.
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.
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.
The following figure shows a Wireshark trace example of a CRL verification request sent by SVM Daemon.
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]
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.
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):
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.
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):
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.
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.
Disable Certificate Revocation altogether
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.
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
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