WEBUI and a REAL SSL cert -and one more question

I just went through the process of setting up SSL for the WebUI and also ran into issues, but eventually got it to work. One thing that was annoying is while I was having issues, the WebUI wouldn’t work at all and didn’t provide any feedback. It would have been nice if while it was misconfigured it fell back to self signed certs. RE: @jgallas

I used a Let’s Encrypt client to create the SSL certificates. Let’s Encrypt provides free Domain Validation certs.

After going through the process, I got 3 files:

  • ca_bundle.crt
  • certificate.crt
  • private.key

I combined ca_bundle.crt and certificate.crt into ssl.crt

I renamed private.key to ssl.pvt

I put both files into the default location on my windows root server: C:\Program Files (x86)\BigFix Enterprise\BES Server\WebUI

If it was a stand alone WebUI server, then the default location should be: C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI

Because I am on platform I then had to restart the BESRootServer service instead of the BESWebUI service.

This did not work. I found errors, Error: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch, in the WebUI log here: C:\Program Files (x86)\BigFix Enterprise\BES Server\WebUI\logs\service-app.log

The error messages were happening like once a minute. I made many changes, but nothing stopped the errors. Eventually I realized that I had to restart the service every time I made changes to the ssl files in order for the WebUI to pick up the changes.

One of the issues turned out to be that I didn’t combine the .crt files properly. The site specific cert needs to be first within ssl.crt followed by the next cert in the signing chain and so on all the way up to the highest in the chain.

My working ssl.crt looks like this:

<<base64 string from certificate.crt>>
<<base64 string from ca_bundle.crt>>

My working ssl.pvt looks like this:

<<base64 string from private.key>>

It seems that BEGIN RSA PRIVATE KEY isn’t required and BEGIN PRIVATE KEY is sufficient, as long as it is a valid key.

This relevance should provide the issue date of the SSL cert:

invalid befores of pem encoded certificates of files "ssl.crt" of folders "C:\Program Files (x86)\BigFix Enterprise\BES Server\WebUI"



Looks like you did a good analysis of the process, James. Odd how IBM has three BigFix web apps (web reports, web console, and BFI) and all are different; the web console being the most difficult.

My web console is on a dedicated VM, not the BES, so that made things a little different with regards to service restart requirements and cert location.

1 Like

The documentation is a bit lacking as to all of the specifics. I’m hoping to get that addressed.

This is an issue that the paths are a bit different depending on standalone vs separate webui and the service you need to restart is dependent upon the platform version in use. Then there is added complexity in the case of using Red Hat instead of Windows, so figuring out the best ways to document all of that is an issue, and then also documenting troubleshooting steps.

This process worked for me. I was provided the certificate in p7b format. so I used the following commands.

First I took my key (originally) used to generate the csr request file to send to the CA for approval and converted it to nopwd. It had a password.

openssl rsa -in bigfix.key -out nowpwdkey.pem

Then I took the p7b formatted file and converted it to a PEM

openssl pkcs7 -print_certs -in bigfix.p7b -out bigfix.pem

Then I copied these two files to the WebUI directory and renamed them

rename nopwdkey.pem ssl.pvk
rename bigfix.pem ssl.crt

I then edited the ssl.crt file and rearranged the certificates so that the server certificate was on top and the CA certificates were in order below them. The p7b file they were in exact opposite order

I then restarted my server and everything worked.



Thank you for documenting your process. It is very hard to document every case since it can be slightly different depending on the CA used and how that CA provides the results.

The process to use a cert for a web page, a fairly common function, should not be this difficult. The BFI web interface was probably the easiest of the three. You just clicked in the WebUI, browse to your cert, and hit OK. It told you immediately if it worked.

1 Like

Hopefully that is something that can be added in the future to the Console Web UI, in addition to something like ACME/Let’sEncrypt support.

Should file an RFE for this and put the link here so it can be voted on.

On the latest version of BigFix (, I had to put the certificates in this directory: C:\Program Files (x86)\BigFix Enterprise\BES WebUI\BES WebUI\WebUI

On the actual files that I put in the directory above, here is what I did.

  1. Took the private key I got from the generating the CSR in OpenSSL and renamed it to ssl.pvk
  2. Downloaded my certificates from my CA in CRT format. I got two files.
    a. Actual SSL certificate
    b. CA Root chain certificate
  3. I opened the certificate in 2a and copied all the certificate information in 2b underneath it. I think saved the 2a certificate as ssl.crt. So basically the ssl.crt is a backwards SSL cert. URL cert (top of the file), then intermediate cert (middle), then root cert at the bottom of the file.
  4. I moved the files to C:\Program Files (x86)\BigFix Enterprise\BES WebUI\BES WebUI\WebUI
  5. Restarted BES Root server and WebUI, SSL works like a charm with my CA verified certificate.

This was all done via trial and error on 9.5.5. It’s no where in IBM’s documentation and I was frustrated so I just started putting the certs in every WebUI folder on the server and doing a process of elimination.

Hopefully this helps others.


This is new to me. I’m not sure why that path would exist like that.

The folder should be WebUI but where it is located depends on the OS and if it is a remote server or a WebUI server on the same system as the root server. I think the folder should always have node in it as well as a folder for service-app

Thank you everyone for the information, I was able to get our certificate working for the WebUI after little troubleshooting.

That being said, there’s still the default self-signed certificates in the “BES WebUI\BES WebUI\cert” directory (auth_cert.crt and ca.crt). I assume these are used for communication back to the root server? Or is there any way we can get rid of these?

Also, here are the high-level steps I used to generate the cert and key. If anyone is using Active Directory Certificate Services, you should be able to use these steps. Note that much of the configuration of the certificate is configured at the template level in this example, so you have to validate that the template you’re using is configured correctly.

  1. create config file for cert request and save it as policy.inf
    a. see example below
  2. open administrative command prompt and cd to the directory containing policy.inf
  3. create request
    a. certreq -new policy.inf request.req
  4. submit request
    a. certreq -submit request.req cert.crt
    b. if you have multiple CAs in your environment and you didn’t specify which to use in your config file, you will be prompted to choose one – choose the one that hosts the template you’re using
  5. import the cert into personal certs via mmc > certificates snap-in
    a. make sure you make the keys exportable (it’s a radio button when importing)
  6. export your cert to a file
    a. make sure you specify that you want your key exported with it (it’s a radio button)
    b. make sure you check the box to “include all certificates in the certification path if possible”
  7. download binaries supporting openssl for windows (I used cygwin)
  8. launch your openssl utility (I used the cygwin terminal)
  9. extract cert and key, then disable password via the following commands:
    a. openssl pkcs12 -in cert.pfx -nocerts -out cert_key_pw.pem -nodes
    b. openssl pkcs12 -in cert.pfx -nokeys -out ssl.crt
    c. openssl rsa -in cert_key_pw.pem -out ssl.pvk
  10. test to ensure key and cert match via the following commands (the generated hashes should match)
    a. openssl x509 -noout -modulus -in ssl.crt | openssl md5
    b. openssl rsa -noout -modulus -in ssl.pvk | openssl md5
  11. copy ssl.crt and ssl.pvk to the directory outlined in the WebUI documentation – currently, the default is:
    a. C:\Program Files (x86)\BigFix Enterprise\BES WebUI\BES WebUI\WebUI
  12. restart the BES Root Server service
  13. restart the BES WebUI service
  14. VOILA



; If your client operating system is Windows Server 2008, Windows Server 2008 R2, Windows Vista, or Windows 7
; SANs can be included in the Extensions section by using the following text format. Note is the OID for a SAN extension. = "{text}"
_continue_ = "dns=WebUIServer.domain.com&"
_continue_ = "dn=DistinguishedName of WebUIServer copy+pasted directly from AD&"
_continue_ = "url=https://WebUIServer.domain.com&"
_continue_ = "ipaddress=WebUIServer_IPAddress&"


You could try moving them somewhere else and see if everything still works. I’d bet they are no longer used, but they could be.

I tried renaming them, but was unable to because they’re in use.

3 posts were split to a new topic: WebUI Broken - DB credentials

Did you use openssl 32 or 64 bit?

In this case, for generating/requesting/manipulating certificates, it won’t matter - 32 or 64-bit will generate the same outputs.

You really only need to worry about 32- vs 64-bit openssl if you are going to call their libraries from your application code.

1 Like