Broken Fixlets - HTTP Error 60

All of these fixlets give the following error. Anyone else seeing this in their environment?

image

Download error: “HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to get local issuer certificate”

kb2589320
kb2553371
KB2716513
KB2760574
kb2553501
KB2807986
kb2760406
kb2837597
kb2850016
kb2810073
kb2880971
KB2992611
KB3019978
KB3020388
KB3046269
KB3059317
KB3067903
KB2862330
KB2984976

Do you use a proxy with your HTTPS connections?
If your proxy is rewriting HTTPS connections you may need to update your root server’s certificate trust list to include your internal root certificate authority. See
https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Config/c_https_gathering.html

No, we don’t use a proxy. I’m using the “File Pre-Cache Wizard” - the other 100+ fixlets in the baseline were downloaded/cached successfully. It’s just the list of KB’s I provided that are giving the error. I just tried one of those KB’s from another instance of BigFix i manage… same error:

Yes, we also saw this for some of the patches & couldn’t find any problem with in our infra hence raised case # CS0278715 where got below response, however as per recent update it has been fixed.

but for a workaround we manually cache those patches.

The prefetch actionscript command doesn’t support URL redirection from HTTP to HTTPS, so if the URL in the prefetch statement is http:// URL and the serving site redirects the request to https://, then the prefetch command will fail as follows:

Download error: “HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to get local issuer certificate”
The typical affected scenario here is that of a fixlet that can successfully download a file using a http:// URL until the serving site implements HTTPS redirection, at which time the fixlet will suddenly start failing to download the file with HTTP Error 60.
Replacing http:// with https:// in the URL of the prefetch statement will sort things out, and that’s the way this type of issue is currently handled

You may want to make a custom copy of the problematic fixlet “MS11-025: Vulnerability in Microsoft Foundation Class (MFC) Library Could Allow Remote Code Execution - Microsoft Visual C++ 2005 SP1 Redistributable Package (x64) (v2, re-released 6-14-2011” , ID = 1102531 in “Patches for Windows” site and replace http:// with https:// in prefetch statement ( I’ve performed these steps in my environment and the payload has been successfully downloaded )

Hi We are facing similar kind of issue, did you get the resolution for the same. There are few MS patches where we are able to see this issue, those patches are too old
(2017 -20018). We are able to see those patches in the Microsoft catalogue, thus as a work around we are manually caching the patch.

Thanks in advance.

KK

@karthik04 you should raise case against those patches with HCL, they are fixing per patch basis.

below is the defect article which they supplied.

https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0095247

Hi @vk.khurava Thanks will raise the ticket.

Regards,
KK

I have a ticket open for these. I opened the ticket 1 week ago. They still have not yet been addressed.

kb2589320
kb2553371
KB2716513
KB2760574
kb2553501
KB2807986
kb2760406
kb2837597
kb2850016
kb2810073
kb2880971
KB2992611
KB3019978
KB3020388
KB3046269
KB3059317
KB3067903
KB2862330
KB2984976

HCL why don’t you run the “File Pre-Cache Wizard” against all fixlets to find broken fixes on daily/weekly schedule? I seem to have to have broken fixlets every month (always older patches). Typically broken download urls (download path no longer exists). It is very frustrating to use a patching tool that can’t patch.

Can you share the ticket number so I can check & follow-up?

I understand the frustration, but it’s not quite as simple as “run the precache wizard”.
If the file already exists in our cache, the root server won’t download it a second time and the wizard would be successful, having pulled the file from the server cache instead of downloading over Internet.

There are a number of fixlets where we know the downloads will fail today, but the fixlets are still kept for historical purposes, and a customer who previously cached the older download file can still successfully deploy the fixlet. For example see Google Chrome, where there is a single download URL that points to only the latest version of Chrome, the download file changes almost daily, and we keep the older versions of the fixlets so those who cached the download a few days ago can still deploy that older version.

That’s not to excuse having the broken download links in the content, just pointing out that a solution is not as simple as it might seem.

This would explain the delay in getting the KB’s i raised resolved. HCL support said that they could successfully deploy the patches. They likely had them cached already. I guess they weren’t able to reproduce the problem and assumed it was an issue specific to my environment. I updated the ticket this morning and am sure it will be addressed in the coming days. However, with that being said this is really difficult to explain to our customers (not being able to install patches during a scheduled maintenance window because of our patching tool failed). Jason, i appreciate your help (you’ve solved the majority of the issues i’ve encountered over the past few years) but i think more effort needs to be made to address this issue. At the end of the day the tool is only as good as its content and lately i’ve see a lot of broken content. Our patching team is frustrated for sure.

Today’s update should correct those fixlets

3 Likes