We have all of our relays configured for authentication with only one of our relays reachable from the Internet. Our main server is also not accessible from the Internet. I’ve read the documentation on Manual key exchange, opting for the BESClient -register method, but it’s not working, failing with “Error collecting client certificate with server message: There’s already a public key associated with that id”.
This is a computer that was previously registered with the server but had the software and directory removed for testing. What do I have to do to get this to work? Is there a file I need to remove from the server/relays?
I would open a support ticket, this might be a bug and we might be able to do something to improve reregistration in that scenario. Waiting for a new bugfix version wouldn’t be helpful right now though.
As a workaround I’d try removing HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BigFix\EnterpriseClient , or at the very least the ComputerID value from HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\BigFix\EnterpriseClient\GlobalOptions
That’s the record of the computer’s previous Computer ID, which the client is trying to re-register but the client no longer has the certificate matching that computer ID. I believe that in the case of a non-authenticating Relay, the Relay would send the client a command to reset itself and generate a new ComputerID value, but that may not be happening correctly with the Authenticating Relay.
Y’all got the gist of it…thank you @fermt and @JasonWalker. I had uninstalled the software and deleted the files (including the left-behind certificate store) but forgotten about the registry keys. Tried again after deleting all three and the process continued beyond that error point, but then ran into another issue:
At 10:53:35 -0500 -
Beginning Relay Select
At 10:53:38 -0500 -
RegisterOnce: Attempting secure registration with 'https://<internal server address>:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=10.0.2.52&Body=130639584&SequenceNumber=13&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&MaxHops=49&Root=http://bf01.aas.duke.edu%3a52311&AdapterInfo=9c-b6-d0-fc-73-f3_192.168.10.0%2f24_192.168.10.37_0&AdapterIpv6=9c-b6-d0-fc-73-f3%5efe80%3a%3a9993%3afc4d%3a9b04%3a4cc3%2f64_0'
At 10:53:59 -0500 -
RegisterOnce: GetURL failed - General transport failure. - BAD SERVERNAME (winsock error 4294967290 - registration url - http://<internal server address>:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe&ClientVersion=10.0.2.52&Body=130639584&SequenceNumber=13&MinRelayVersion=7.1.1.0&CanHandleMVPings=1&MaxHops=49&Root=http://bf01.aas.duke.edu%3a52311&AdapterInfo=9c-b6-d0-fc-73-f3_192.168.10.0%2f24_192.168.10.37_0&AdapterIpv6=9c-b6-d0-fc-73-f3%5efe80%3a%3a9993%3afc4d%3a9b04%3a4cc3%2f64_0
The address that the computer is trying do connect to is only available while on our campus network or VPN. The BESClient.exe -register command successfully got the certificates from our external relay, but is now trying to register with an internal address. That won’t work.
Apply a _BESClient_RelaySelect_FailoverRelayList setting that includes a reachable relay. Either using a clientsettings.cfg during the installation, or by manually adding it to the Registry.
Okay… I edited the HOSTS file to point the internal server name to our external relay and the computer successfully registered. NOW the questions are:
Why is the computer trying to register against the internal address (which, granted, is in the masthead file) instead of the server specifically included in the BESClient.exe -register command? It successfully retireved the certs from that server, but then tried to -register against a different server.
What do we need to do to make this work without monkeying around with the HOSTS file? Is this something that should be in our masthead file?
So, did some more testing, found that the combination of (a) having a wildly out-of-date masthead file (that included our proper server address but not our failover relay address) and (b) having a __RelayServer1 in the clientsettings.cfg file both worked against the process. After both updating the masthead and removing the __RelayServer1 line from the cfg file, the process worked just fine.
The problem NOW is that the BESClient.exe -register process doesn’t seem to want to stop.
The logs show that the client has gone through a few Encrypted Report posted successfully cycles since I started the process a few hours ago but the command hasn’t stopped…
I don’t know what command processor you are using but notice that this line has the command prompt already. This is suggesting that the processor is just waiting for input.
The text you are seeing is output with _tprintf and thus is just a STDOUT output and command processors do have trouble with that sometimes. Have you tried just hitting return and getting the prompt again?
Additionally the Aborting message is either saying you have the KeyStorage local directory with keys/certs in it, or the server has the computerid that is stored in the registry with a certificate already, and as a security measure does NOT allow a new certificate to be created where the server already has one
Sorry… that was a really bad screen grab with all sorts of overtyping. That attempt was actually re-running it on a computer that had performed the key exchange but then failed the registration due to addressing issues. All of my attempts, however, ended with that BESClient started then blink, blink, blink…
I’ll clear off this test machine and do it again to get a cleaner output.
Hi all. My issue seems to be very similar. I am working on migrating clients from a 9.5.9 instance to a 10.0.6 instance. During the migration/masthead switch action we run, it looks like it registers once with the relay we asked it to register with, then after that attempts to register with our master server. This is when we get the same resisteronce: geturl failed - general transport failure - Bad SERVERNAME…ect like the above from straffin. Any suggestions? We have verified that a brand new install into 10.0.6 instance works from the same physical (not vm) computer that we are having trouble with migration from the 9.5.9 instance. Please see below our masthead switch fixlet. Let me know if I should add any other information.
//**Begin Preparation Marker
// Download all specified files
begin prefetch block
add prefetch item name=9e0ad2ec8a59088a5bae99d67ba904e7d70eedd1 sha1=9e0ad2ec8a59088a5bae99d67ba904e7d70eedd1 size=369721 url=SWDProtocol://127.0.0.1:52311/Uploads/9e0ad2ec8a59088a5bae99d67ba904e7d70eedd1/actionsite.afxm.bfswd sha256=5e9e366a7e85d9456062f389cfdf56140dcfbc1ecac6a56408a9a5eee889754d
end prefetch block
// All SWD files will go into a folder in the clients __BESData folder. This folder gets cleared on every restart. parameter “baseFolder” = “__Download/” // Move files into subfolders and unescape file names move “__Download/9e0ad2ec8a59088a5bae99d67ba904e7d70eedd1” “{parameter “baseFolder”}actionsite.afxm”
continue if {exists file “actionsite.afxm” of folder “__Download” of client folder of current site} if {unix of operating system} delete /etc/opt/BESClient/actionsite.afxm move “{pathname of file “actionsite.afxm” of folder “__Download” of client folder of current site}” /etc/opt/BESClient/actionsite.afxm else parameter “MastheadLocation”="{pathname of file “actionsite.afxm” of storage folder of client}" delete “{parameter “MastheadLocation”}” move “{pathname of file “actionsite.afxm” of folder “__Download” of client folder of current site}” “{parameter “MastheadLocation”}” endif
//Turn off automatic relay select setting “_BESClient_RelaySelect_Automatic”=“0” on “{parameter “action issue date” of action}” for client //the old content of certificates for the authenticating relay were gone by adding this line delete “{pathname of parent folder of parent folder of client folder of current site}/KeyStorage/__*”
// Set the base CUSTOMER relay affiliation for all non-infrastructure clients setting “__RelaySelect_Automatic”=“1” on “{now}” for client setting “_BESClient_Register_Affiliation_SeekList”=“FSM;*” on “{now}” for client setting “_BESClient_RelaySelect_FailoverRelayList”=“rel03;rel04;rel01;rel02;bespri01” on “{now}” for client
The “BAD SERVERNAME” is the easy part. Whatever server name is being looked for (it’s written in your logs along with the error) is not valid according to the target computer’s DNS server.
Usually we’d suggest using fully-qualified DNS names for the Relays in the _BESClient_RelaySelect_FailoverRelayList value. Otherwise, you depend on the clients’ “DNS Suffix Search Order” to resolve those short hostnames.
