BigFix Console - HTTP Error 35 SSL

1

I have a Windows 10 VM that creates an error “Failed to connect to server: HTTP Error 35: SSL connect error: 140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unkown protocol”

This seems to only be happening right now on a single Win10 VM, and another configured similarly doesn’t have this issue. I used the BigFix removal tool, removed everything, and then looked for any files left… found none.

We’re on v10.0.2 and it’s happening across our 3 BigFix environments, so this has to be a client side issue.

Things tried:

  1. Removed all BigFix stuff
  2. Rebooted
  3. Looked for any certs certmgr.msc but didn’t find anything…

Any ideas?
image

2

Very basic question are you able to telnet your bigfix server on your configured port no for BigFix infra?

Are you using any dns alias against your bigfix server name and if yes the right dns alians and correct certificate supplied?

3

It’s an alias
I can telnet to 80, 443, and 52311. I can also open/login to the WebUI through a browser.

4

Try using a browser to login to the REST API via
https://root-server-fqdn:52311/api/login

That may give a more descriptive message - like perhaps a proxy is redirecting you off of the server?

If you are at Win10 build 1909 or higher (which includes curl), or have downloaded a separate copy of curl, you could also test that - since curl does not use the system proxy config - and try to download a copy of your masthead to test connectivity via
curl -k https://root-server-fqdn:52311/masthead/masthead.afxm

1 Like
5

Login works fine from browser, etc, including REST API. Browser also shows the accurate self signed cert and not a proxy cert.

We do have proxies here but within the internal network, there “should not” be one… but it’s still something I can’t fully rule out. I have another Win10 VDI that doesn’t have this issue, but while it’s configured nearly identically, it’s also in a different datacenter. My work laptop is also fine, and it seems to just be this one VDI, which conveniently, is the primary VDI I use and was setting up again… and it is leaving me perplexed.

Donwnloading the masthead works fine
Invoke-WebRequest https://bigfix.domain.com:52311/masthead/masthead.afxm -SkipCertificateCheck

6

Ok, at least we’ve ruled out a connectivity, proxy redirect, or name resolution issue (I think).

I’d recommend turning on console debug options (described at https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0023275&sys_kb_id=9006a7041b617f4077761fc58d4bcb5b ). That should show a little more about what the Console is trying to do.

1 Like
7

Perfect… That was what I hadn’t looked for yet, logging for console.

Sadly, not seeing a clear red flag yet… Has some potential for winhttp proxy, but I have the same log on a working machine…

From a working computer (using Windows session creds) :

Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – (critical log messages enabled)
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – (debug log messages enabled)
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – startup version 10.0.2.52
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – FXF character set is windows-1252
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – Using cURL library - 7.73.0-DEV
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – OpenSSL Initialized (Non-FIPS Mode)
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – Using OpenSSL crypto library libBEScrypto64 - OpenSSL 1.0.2u 20 Dec 2019
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – TLS Cipher List: HIGH:!ADH:!AECDH:!kDH:!kECDH:!PSK:!SRP
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – BigFix Enterprise Console - 10.0.2.52
Fri, 30 Apr 2021 15:03:56 -0400 – Main Thread (8148) – Initial SAML support check server.domain.com - Server does not support SAML authentication
Fri, 30 Apr 2021 15:03:57 -0400 – Main Thread (8148) – Attempting authentication with Windows session credentials
Fri, 30 Apr 2021 15:03:57 -0400 – Main Thread (8148) – Failed to get winhttp proxy: Windows Error 0x2ee6: The URL does not use a recognized protocol
Fri, 30 Apr 2021 15:03:57 -0400 – Main Thread (8148) – TryLogon did not succeed
HTTP 401: Unauthorized : Could not authenticate with your Windows session credentials
Fri, 30 Apr 2021 15:03:57 -0400 – Main Thread (8148) – Entering GET data/database-version

From same working computer (using manual user/pass):

Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – (critical log messages enabled)
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – (debug log messages enabled)
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – startup version 10.0.2.52
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – FXF character set is windows-1252
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – Using cURL library - 7.73.0-DEV
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – OpenSSL Initialized (Non-FIPS Mode)
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – Using OpenSSL crypto library libBEScrypto64 - OpenSSL 1.0.2u 20 Dec 2019
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – TLS Cipher List: HIGH:!ADH:!AECDH:!kDH:!kECDH:!PSK:!SRP
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – BigFix Enterprise Console - 10.0.2.52
Fri, 30 Apr 2021 15:09:58 -0400 – Main Thread (10228) – Initial SAML support check bigfix.domain.com - Server does not support SAML authentication
Fri, 30 Apr 2021 15:10:04 -0400 – Main Thread (10228) – Attempting standard authentication
Fri, 30 Apr 2021 15:10:04 -0400 – Main Thread (10228) – Entering GET data/database-version

From the broken computer:

Fri, 30 Apr 2021 15:00:20 -0400 – Main Thread (19276) – (critical log messages enabled)
Fri, 30 Apr 2021 15:00:20 -0400 – Main Thread (19276) – (debug log messages enabled)
Fri, 30 Apr 2021 15:00:20 -0400 – Main Thread (19276) – startup version 10.0.2.52
Fri, 30 Apr 2021 15:00:20 -0400 – Main Thread (19276) – FXF character set is windows-1252
Fri, 30 Apr 2021 15:00:21 -0400 – Main Thread (19276) – Using cURL library - 7.73.0-DEV
Fri, 30 Apr 2021 15:00:21 -0400 – Main Thread (19276) – OpenSSL Initialized (Non-FIPS Mode)
Fri, 30 Apr 2021 15:00:21 -0400 – Main Thread (19276) – Using OpenSSL crypto library libBEScrypto64 - OpenSSL 1.0.2u 20 Dec 2019
Fri, 30 Apr 2021 15:00:21 -0400 – Main Thread (19276) – TLS Cipher List: HIGH:!ADH:!AECDH:!kDH:!kECDH:!PSK:!SRP
Fri, 30 Apr 2021 15:00:21 -0400 – Main Thread (19276) – BigFix Enterprise Console - 10.0.2.52
Fri, 30 Apr 2021 15:00:38 -0400 – Main Thread (19276) – Attempting standard authentication
Fri, 30 Apr 2021 15:00:38 -0400 – Main Thread (19276) – Failed to get winhttp proxy: Windows Error 0x2ee6: The URL does not use a recognized protocol
Fri, 30 Apr 2021 15:00:38 -0400 – Main Thread (19276) – TryLogon did not succeed
Failed to connect to server: HTTP Error 35: SSL connect error: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

8

Hm.

Do you have separate BigFix deployments? I had an SSL error a few versions back when

  • BESClient pointing to one deployment
  • BESConsole to manage another deployment
  • BESClient’s deployment was set to “Require Enhanced Security” in BESAdmin
  • BESConsole’s deployment did not have “Enhanced Security” configured in BESAdmin

At the time (9.5.15 or maybe 10.0.0), the Console logon would abort with no error message at all, I wonder whether this could be the same thing but an (obscure) error message is now being shown?

The workaround I used was to enable Enhanced Security on both deployments.

9

Interesting…
We have 3 deployments of BigFix, on 10.0.2, and all have enhanced security on. Also happens with our DSA servers. So 5 total bigfix servers.

The login issues I can replicate through all deployments, so it reinforces my thinking of a client issue. I tried running the console as another user, same issue… but maybe I’ll try to login here with my admin account instead of user account and see what happens.

10

Is the output from both the working system and the non working system identical when you run the following command?

netsh winhttp show proxy

11

Proxy is the same.

Back on Windows userprofile stuff… I logged in as my administrator account to Windows, and the BES console opens fine. I did have to accept a certificate for the first connection and then it opened fine.

Anyone know where certs may be stored? I don’t get prompted on my main Windows account, so wondering if that may be related? Keep in mind I have used the BESremoval tool, removed everything, checked for regkeys, and files in AppData…

image

12

Could open a browser to https://bigfix.domain.com:52311/rd then click on the lock in the address bar, click on “Certificate”. You’ll get a popup window with 3 tabs. Select “Details” tab then click on “Copy to File…”. Export the file (I think as a Base-64 encoded x.509 with a cer extension) then make that file available to your main windows account. Log in as your windows account and double click on the exported cert file. You’ll be prompted to install the cert for the current user.

13

The Console does not use the Windows Certificate Manager to establish trusted certificates.

The first time you connect to the Console, if you choose to trust the certificate, the root server’s masthead.afxm is copied to %USERPROFILE%\AppData\Local\BigFix\Enterprise Console\<server name>\masthead.afxm. The console bases the trust on that masthead file.

Based on a procmon capture, I believe if the root server’s HTTPS certificate differs from the masthead file (i.e. you’ve performed the “Customize HTTPS on REST” procedure to load a custom certificate), the Console would copy that to %USERPROFILE%\AppData\Local\BigFix\Enterprise Console\<server name>\CustomSSLCertificate.crt and use that to establish trust.

I wonder whether there are some kind of custom permissions present on %USERPROFILE%\AppData\Local\BigFix\Enterprise Console that prevents your operators from adding/modifiying files and directories unless the run the Console as an elevated user? Default permissions would allow access from a non-elevated user account but if those file permissions have been modified that could be problematic.

1 Like
14

Perms look fine, I also just tried deleting %USERPROFILE%\AppData\Local\BigFix and let it recreate… perms are still full, and I am a local admin. Also ran BESconsole as admin, same issue.
Also brought over \serverfqdn\masthead.afxm from my other local profile just to see what would happen. Again, same issue present.

Real strange one here… Probably a simple answer at the end of the day, just haven’t hit on it yet…

15

Do you have a support incident open yet? I think you’ll need one, I’m running out of ideas.

I’ve seen the message before, but it always had to do with the console attempting to connect via a Proxy. I’d expect we have ruled that out with our browser connections to the REST API though.

One last thing you might check is to be extra sure that your console really is connecting to the root server; either use Windows Resource Monitor, or a WireShark packet capture, to be sure it’s not going through a proxy.

16

It does “feel” like a local perms or proxy issue. The browser uses the OS proxy but maybe, somehow, the BESconsole is not… and the finding of my admin vs. user account is also interesting.

Thanks for the help! I’ll continue testing a few more things and will open an incident “soon”.