BigFix 10.0 Patch 9 is now available!

A post was split to a new topic: 10.0.9 upgrade problem with database connection

I’m facing the same situation but I don’t want to totally disable the certs verification on my root server. I have exported the crt file for the bfi inventory server and placed under the TrustedDownloadCerts folder, still the server is not able to download content from the BFI server.
Is is enough with exporting the cert from a browser and place it under that directory or do we need to do something else in order for the server to trust the site?

It Depends ™
There are at several potential issues that come to mind.

  1. If Inventory is using the default self-signed certificate, I don’t think there’s any good option for trusting that certificate from the Root Server. The Inventory self-signed certificate is issued to the subject “HCL” which the Root server is not going to trust due to the certificate’s Subject not matching the expected hostname / IP address of the server. @ArturZ any way to have BFI regenerate the self-signed cert and assign a real hostname as the Subject or Subject Alternative Name?

  2. If Inventory is using a real certificate issued by your internal Certificate Authority, or a self-signed certificate you generate yourself, you’ll need to add the Issuer’s certificate (either your internal CA Root Certificate & intermediates, or the self-signed certificate itself) to the root server’s TrustedDownloadCerts folder.

  3. You’ll also need to ensure that the “Catalog Download” task/action that is issued by the Inventory server, configures the Download URL to use the server’s hostname. By default it issues the action referencing the catalogs as ‘http://IP_ADDRESS:PORT’ of the Inventory server. Using the instructions at Configuring servers in separate networks you’ll need to create or update the server.env file at install_dir\wlp\usr\servers\server1 and add the entry

    SERVER_URL_CATALOG=https://hostname.domainname:port

…where the hostname.domainname matches the fully-qualified hostname of your Inventory server, the name must be resolvable from the Root Server, and needs to match the Subject or Subject Alternative Name entries for the certificate you issued to the Inventory server.

(If this is the problem, the “Catalog Download” actions will have prefetch statements referencing the IP address of your Inventory server rather than its hostname)

I’m trying to keep up to date KB0102706: https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0102706

In BFI and SCA you can regenerate the self-signed certificate with set Common Name - using the real hostname. This is addressing the need to make the certificate to be successfully validated when client will have it added to the client side trust store.

In case of regeneration of the certificate it is worth to remember that BFI/SCA UI are only are providing subset of capabilities and at the end it is WebSphere Liberty configuration (and updating key store pointed by id=‘defaultKeyStore’ in server.xml).

If there is needed to create certificate with multiple DNS Name - it has to be made fully manually using e.g. https://www.ibm.com/docs/en/was-liberty/core?topic=applications-securityutility-command with --extInfo flag
or openssl.

1 Like

Thank Jason,

Our case is that we are using the self-signed certificate generated by the BFI installation.
Due to a mismatch in the certificate’s subject, it can’t be trusted by the tool.
I’m going to review the KB provided by @ArturZ and report back my results.

I have re-created the self-signed certificate to use the fqdn as the common name of it. After restarting the BFI service and placing the new cert under the TrustedDownloadCerts folder of the BigFix Server the downloads completed without any errors.
Since this is our Lab environment we don’t intend to create a CA signed certificate but in our production environment that is already done and it shouldn’t be a problem once we upgrade our environment there.

1 Like

3 posts were split to a new topic: Custom CACerts with 10.0.9

This topic was automatically closed after 30 days. New replies are no longer allowed.