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.
-
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?
-
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.
-
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 atinstall_dir\wlp\usr\servers\server1
and add the entrySERVER_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.
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.
This topic was automatically closed after 30 days. New replies are no longer allowed.