I was working with a client to get a new 9.5.13 BigFix server going for the purposes of installing the IBM License Metric Tool.
After the BigFix installation finished, we noticed that the BigFix Management (BES Support site) tasks & fixlets were not loading. The BigFix server uses a proxy to get out on the Internet, and that was configured properly and tested (besadmin.exe /setproxy). We checked besrelay.log and saw timeouts to https://gatherer.bigfix.com. We tried going to that site in a browser and was able to reach it - however, the browser gave us a security warning. We took a guess that the gather process was stopped because it couldn’t answer the security warning.
The resolution in this case was to get the cert for gatherer.bigfix.com using openssl’s s_client, convert it to x509, install it locally on the BigFix server and then the fully populated list of fixlets was generated – so it was clearly the untrusted cert causing the problem.
We are a bit confused why our BigFix server didn’t recognize the cert as coming from a valid CA - which is
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
Perhaps the server didn’t like the wildcard bit of the CN?
CN = *.subscribenet.com
Or maybe it’s because a proxy is in use here?
Can anyone explain this to me? Thanks!
That certainly is strange - my best guess is that when they installed the operating system, they customized or removed the default list of trusted CAs. That would account for the browser warnings at least.
The thing is, I wasn’t aware BigFix would even use the OS’s trust list for gathering. When dealing with SSL-inspecting proxies (where the customer rewrites the TLS connection using their own proxy certificate), I’ve had to add the custom CA certificate to the BigFix server’s trust store as described at https://www.ibm.com/support/knowledgecenter/en/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Config/c_https_gathering.html - trusting the custom CA from the OS was not sufficient. I had to add to BigFix’s trust store at C:\Program Files (x86)\BigFix Enterprise\BES Server\Reference\ca-bundle.crt
Can go into many details for security reasons, however the problem is certainly related to the proxy. To avoid “man in the middle attacks”, the https gather includes also a peer verification, and your proxy could not be configured to work with the above peer verification.
Thanks guys … here’s the thing though … if I go to https://gatherer.bigfix.com on my own workstation, which doesn’t have BigFix, I also get a browser warning. I have direct access to the Internet without a proxy.
I’m likely getting the browser warning because the certificate’s common name *.subscribenet.com (from Flexera?) doesn’t match the URL gatherer.bigfix.com. Is the certificate “right”?
This does appear to be an error, the team is looking into it and should have it resolved shortly. In the meantime, if you have an immediate problem gathering you could use the AirgapTool as a workaround (but I don’t expect this workaround to be necessary much longer.)
The browser can’t complete the peer authentication that the BES server does automatically. Your scenario is somehow similar to the the airgapped environment, where the server is not connect to internet. See the section “Validating HTTPS certificates” at