WEBUI and a REAL SSL cert -and one more question

The directory structures are mirrored between local and remote installations, so C:\Program Files (x86)\BigFix Enterprise\BES Server\WebUI becomes C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI

The instructions are as I mentioned earlier in this post:

If you have done this, and it isn’t working, then your files are not properly formatted or do not contain the proper data. Based on the file list you posted, you will need to open your .crt files in notepad or some other text editor, and copy the intermediate certs and root cert below the server cert, so they are all in one file. Make sure you include all the --------BEGIN CERTIFICATE----------- and -----------END CERTIFICATE----------- headers/footers just as they are in each cert.

The one thing I don’t see is your .key or .pvk file. It is probably included in your .p7b file, and will have to be extracted using OpenSSL or something similar.

So the correct directory for the certs is: C:\Program Files (x86)\BigFix Enterprise\BES WebUI\WebUI

I did use OpenSSL and I have those files. The ssl.key has -----BEGIN RSA PRIVATE KEY----- / -----END RSA PRIVATE KEY----- so I can change those to -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- if that makes a difference.

Being WebUI is on a separate server, does the Gather Service still have to be restarted for the certs to take affect? If not, which service is best to try new certs? Finally, is there any logging I can use to see what cert may be having an issue or if they are even being seen?

2 Likes

The solution is:

For ssl.pvk follow the process [> here] (http://www.ibm.com/support/knowledgecenter/SS6MCG_9.5.0/com.ibm.bigfix.doc/Platform/Web_Reports/c_creating_a_certificate_signing_request.html), taking the nopwdkey.pem and renaming to ssl.pvk.

For ssl.crt using the 3rd party cert files screenshot earlier in this thread, paste in plain text the three files below in order to make ssl.crt.

ServerCertificate.cert
Intermediate1.cert
Intermediate2.cert

Please both in \WebUI\ directory and restart the WebUI service.

2 Likes

Hi @AlexaVonTess,

I know I’m late to the party but I wanted to thank you for your post specifying the correct location for the WebUI Signed Certificates. The guide I was using was for 9.5.2.56 and was pointing me toC:\Program Files (x86)\BigFix Enterprise\BES Server\WebUI instead of the location you mentioned. After spending almost a week going in circles, moving the files to your location did the trick :). After many hours of googling I only found this and another forum post regarding using a 3rd Party certificate.

1 Like

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 9.5.2.56 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:

-----BEGIN CERTIFICATE-----
<<base64 string from certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<base64 string from ca_bundle.crt>>
-----END CERTIFICATE-----

My working ssl.pvt looks like this:

-----BEGIN PRIVATE KEY-----
<<base64 string from private.key>>
-----END 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"

Related:

5 Likes

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.

Thanks
Lou

3 Likes

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 (9.5.5.193), 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.

4 Likes

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

policy.inf:

[NewRequest]
Subject="CN=WebUIServerName,OU=DIT,O=company,L=city,S=state,C=US"
Exportable=TRUE
ExportableEncrypted=TRUE
RequestType=PKCS10

[Extensions]
; 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 2.5.29.17 is the OID for a SAN extension.
2.5.29.17 = "{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&"

[RequestAttributes]
CertificateTemplate=TEMPLATE_NAME
3 Likes

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