Bigfix - Relay does not support secure registration

Usage and Config Platform
1

Hello All,

We have been experiencing some issues with some windows servers clients.

We have deployed Linux Bigfix relay (9.5.8) on Linux RedHat Server on a site where 100 servers are located.

We deployed the bigfix agent on all windows server but we noticed that some of them are reporting and the others are not. As a consequence, we started to check what happened.

We noticed the errors in the besclient log.

“BESRelay does not support secure registration”
“does not allow clear text registration”

We uninstall the agent and installed it again manually but we got the same error. What is more, we enabled the BESRelay diagnostic web page but windows can not open the web page https://relay.local.com:52311/rd (but they can telnet relay by port 52311).

image

2

Did you deploy the relay using the fixlet after the agent was installed and reporting in successfully? The relay uses the local client certificate in order to do secure registration with other clients reporting to it. As long as that certificate is present and accessible to the relay, it should be able to do secure registration.

3

Hello Steve,

Yes, It was deployed by fixlet. It is quite odd because some windows server are reporting and others don’t.

It seems that these windows servers have an issue for “initial key exchange” when they are trying to authenticate by certificate and they are being rejected by the Relay as they try by clean text.

I don’t know if they have a setting to disable ssl 1.0 cipher.

Regards

jO

  • List item
4

Hello All,

We found the fix. It was a static route on those windows server that for some reason were affecting the connections between the endpoint and the relay.

Regards

JO

1 Like
5

Hi jO

I am seeing same errors on one of my new windows server client in AWS trying to connect & register to Bigfix relay (non authenticating relay).

DebugMessage RegisterOnce: Relay does not support secure registration.
DebugMessage RegisterOnce: Current deployment ‘x-bes-minimum-supported-relay-level’ masthead setting does not allow clear text registration.

Other clients are connecting and able to register fine.

What was the static route on your client you had to fix. Can you provide more details? I have PMR open with HCL support but so far they have not been able to figure it out.

Thanks.

6

What did you do after you figured out it was the static route? How did you fix it? I’m in the same situation and I want to rule that out.

Thanks,

7

Saw this post and wanted to provide another probable solution to this.

Many app aware security devices that are set to block http/https on non-standard ports can cause this error to occur. In this case, bigfix client is sending HTTP/HTTPS data over TCP 52311 and a app-aware security device or software in the middle of the communication chain could see that and block as it expects HTTP/HTTPS to only pass over 80/433.

An indication that this is the case is to try these steps:

  1. Run a port check from a client system having issue. For example:
    (In Powershell admin prompt):

Test-NetConnection -ComputerName relayname_or_IP -Port 52311 -InformationLevel Detailed
(or any command line test that tests if port 52311 is open)

In this case, with these errors people are reporting above related to masthead setting, this should work and show port is open (this is because the port test doesn’t actually use HTTP/HTTPS so it succeeds).

Note if you have a normal firewall blocking TCP 52311, you’ll get WINSOCK errors in client…not the errors you see above in the thread relating to masthead.

However if you try a CURL command from client system having issue, you may see it fail

curl -k http://relay.domain:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=Version

This is because the app aware security device detects actual HTTP/HTTPS over 52311 (instead of 80/443) and drops the connection.

Overall, this is a big clue that this is occurring. (Port tests succeed but actual connections using http/https over TCP 52311 fail.)

Solution is is to find the security device in question that is intercepting the client traffic and add/modify rule to allow http or https over 52311.

For example, in something like a Palo Alto, you don’t “enable tcp 52311”, you “enable https on tcp 52311” and “enable http on tcp 52311”.

The layer-4 firewall, when blocking HTTP/HTTPS over non-standard ports tend to allow every TCP SYN / ACK / SYN-ACK handshake to go through and then reset the connection after they detect the protocol that’s running on it.

2 Likes