Custom CACerts with 10.0.9

[mikelbeck]

You should be able to set it back to 0, but may still need to add your internal PKI to the BigFix certificate trust stores. BigFix does not use the operating systems’ trust store, you’ll need to follow the instructions at https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/c_customizing_HTTPS_downloads.html5 to add your PKI to .crt or .pem files to /TrustedDownloadCerts or setting _BESRelay_Download_CaCertDirectory and/or _BESClient_Download_CaCertDirectory to custom paths and adding your .crt / .pem files there.

I’ve just completed the upgrade to 10.0.9 and am unclear about the certificates and the TrustedDownloadCerts folder.

I need to add our PKI’s CA and Subordinate certificates to the TrustedDownloadCerts folder on the root server, correct? Will they be automatically distributed to relays and clients or do I need to create a task to do that (such as the one shown on this page)?

[JasonWalker]

I need to add our PKI’s CA and Subordinate certificates to the TrustedDownloadCerts folder on the root server, correct? Will they be automatically distributed to relays and clients or do I need to create a task to do that (such as the one shown on this page)?

Yes, in standard usage you will need to add your Root and Intermediate CA certificates to the TrustedDownloadCerts directory on the server.

This is not automatically distributed to Relays or Clients. You only need to configure this on Relays and Clients if they are performing direct Internet downloads ( using the settings for _BESClient_Download_Direct or one of the domain list variants on clients, or _BESGather_Download_CheckInternetFlag on Relays, or the “download now” ActionScript command). Otherwise, by default only the Root Server is actually doing the Internet downloads and needs the certificate trust list updated.

[mikelbeck]

If my root server is downloading from the Internet, why would it need certificates from our INTERNAL PKI?

Also prior to this version I found that I had to set _BESRelay_Download_UntrustedSites to 1 on the root server in order for clients to download the BFI catalog properly. Will I be able to set this back to 0 and have the clients work properly once I place the CA’s certs on the root server?

[JasonWalker]

Ah, ok.
To be clear, you only need to customize the CACerts at all when downloading from sites that use (or appear to use) certificates issued by your CA.

In normal usage, that means internal websites hosting content for your custom Fixlets, or the Inventory catalog downloads coming from your BFI server (assuming you have replaced BFI’s default self-signed certificate with a certificate issued by your CA).

In many deployments, a proxy server will be configured to decrypt your Internet downloads, replacing the HTTPS session with your Proxy’s certificate. In that case you need to add trust for your internal CA so those proxied connections are trusted.

If you aren’t hosting custom downloads, and aren’t using a decrypting proxy, and haven’t replaced Inventory’s certificate, then all you need is to either trust the Inventory server’s self-signed certificate, or replace Inventory’s certificate with one you do trust (from your CA, and configure the root server to trust your CA); or keep the _BESRelay_Download_UntrustedSites setting so your root server ignores the “untrusted certificate” error.

[mikelbeck]

or the Inventory catalog downloads coming from your BFI server (assuming you have replaced BFI’s default self-signed certificate with a certificate issued by your CA).

We don’t have a proxy server and we don’t have any internal web sites hosting BigFix content. But we have replaced BFI’s self-signed certificate with one issued by our internal CA.

Do we now need to distribute the CA’s root & sub certificates to all clients using a task like this so they can download the BFI catalog?

[JasonWalker]

No, you should only have to update the trusted certs list on the root server. That’s the only server that actually downloads the signatures from Inventory. Once the Root Server downloads from Inventory, the Relays download from the Root Server, and the Clients download from their Relays (i.e. the Relays and Clients never actually see BFI’s certificate)

[mikelbeck]

No, you should only have to update the trusted certs list on the root server. That’s the only server that actually downloads the signatures from Inventory. Once the Root Server downloads from Inventory, the Relays download from the Root Server, and the Clients download from their Relays (i.e. the Relays and Clients never actually see BFI’s certificate)

OK. I’ve set _BESRelay_Download_UntrustedSites back to 0 and have added the root & sub certificates on our BigFIx root server.

We’ll see what happens when there’s a new catalog available, hopefully there will not be any issues. Either way I’ll report back here on this thread.

Thanks for the help!

[JasonWalker]

Happy to help!
You can always force a catalog update by creating a new custom signature in the Inventory web interface; the server will generate a new catalog during the next import.

[mikelbeck]

You can always force a catalog update by creating a new custom signature in the Inventory web interface; the server will generate a new catalog during the next import.

I just want to throw this out there in case anybody else runs into this issue.

A new catalog update was published the other day and my clients are all trying to download it but were failing.
The error shown in the console wass “HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL: no alternative certificate subject name matches target host name '10.x.y.z” (obviously x.y.z are a real address).

What I did to fix it was to add the IP address as a SAN on the certificate used by BFI. BUT - as per this page’s guidance it had to be added as an iPAddress SAN and not a dNSName SAN.

We use Windows PKI as our internal CA, when submitting the request I had to add this to the request:

san:ipaddress=10.x.y.z&dns=bfinventory.tld.com&dns=bfinventory

After installing the new certificate and restarting the BFI service the clients were immediately able to download the catalog update.

[fermt]

Is it expected to clients that try to download the update installers directly from Microsoft fail due to the certs validations that were introduced with 10.0.9?

We are seeing this behavior and according the the BigFix documentation for external sites with a valid cert we don’t need to do anything to let the pass.

We had to remove the direct download settings to get it back to work using our BigFix relays infra.

[JasonWalker]

No, that would not be expected behavior. If the clients are using the default CACerts, that should include the public PKI that Microsoft is using, and the clients should trust it.

Are the clients going through a decrypting proxy server? If so, you’d need to add your proxy’s cert to the clients’ trust store.

Have you otherwise customized the clients’ CACerts? If so, it may matter whether you have replaced the clients’ CACerts (10.0.8 behavior) or merged/added certs to the existing trust stores (10.0.9 behavior)

[fermt]

No proxy is in place and we haven’t customized the clients’ CACerts.
We are opening a support case to figure out what is happening.

[orbiton]

Have you tried solution A on the following KB - https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0102706 ?

[DerrickD]

Good discussion here talks about how it works and solutions for various environments

BIGFIX 10.0.8 - Linux master - prefetch download error when link states https:// - works with http:// - " HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to get local issuer certificate"

BIGFIX 10.0.8 - Linux master - prefetch download error when link states https:// - but works with http:// - " HTTP Error 60: SSL peer certificate or SSH remote key was not OK: SSL certificate problem: unable to get local issuer certificate" on a case by case basis …so if i copy off the fixlet , edit the prefetch line to use http: instead of https: then the files are downloaded. BIGFIX master is linux … we also have a BIGFIX master that is Windows and the same " https prefetch fixlets " that f…

[fermt]

It turned out this a known bug since v 10.0.8!
I can’t believe BigFix released 10.0.9 without fixing this issue.

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