I've got a serious problem with my newly rolled out Vista machines. It seems that after some period of time, the brokerconfig certificate becomes invalid, or stops working for some reason. We currently use the ISO, but we'll be changing to the appliance within a few weeks (and I'm going to have to figure out how to get the new certs onto machines that are nowhere near my office, much less in my state--grr).
In any case. here's the log when I hit test on one of these machines with brokerconfig:
09:40.362 Attempting Direct HTTP connection to host <core FQDN>:80
09:40.362 Starting HTTP session with host <core FQDN>:80, proxy "", and proxy user ""
09:40.396 Unable to resolve host <core FQDN> address 255.255.255.255
09:40.396 Direct connection failed 6 Name resolution error
09:40.396 Using certificate file C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.crt and keyfile C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.key
09:40.397 Certificate/key loaded. Certificate file "C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.crt". Key file "C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.key"
09:40.397 Attempting managment gateway connection at host and address <LDMG FQDN>
09:40.397 Starting HTTPS session with host <LDMG FQDN>, proxy "", and proxy user ""
09:40.397 Connecting to address <LDMG IP>
09:40.862 Waiting for link connection to core through managment gateway
09:40.862 Begining link request
09:40.862 HTTPS Request: POST /services/link
09:40.862 Waiting for match response
09:40.862 Waiting for HTTPS response
09:40.949 HTTPS response finished status 201 description Created
09:40.949 Creating session from client computer through managment gateway to core computer
09:41.027 Starting long session client
09:41.190 Match request completed 0 Success
09:41.190 Link to core successful
09:41.190 HTTPS Request: POST /landesk/managementsuite/core/RemoteControlLogging/RemoteControlLog.asmx
09:41.190 Waiting for HTTPS response
09:41.213 Error 4 Closed reading response line
Checking the brokerconfig log on one of them, I see:
Tue, 24 Mar 2009 11:32:28 PostCertificate() posting cert to host <core FQDN>, proxy
Tue, 24 Mar 2009 11:32:28 PostCertificate() StartSession returned 6
Tue, 24 Mar 2009 11:32:28 PostSoapRequest() Starting with host <core FQDN>, user <core>\<username>
Tue, 24 Mar 2009 11:32:28 PostSoapRequest() StartSession returned 0
Tue, 24 Mar 2009 11:32:28 PostSoapRequest() Request returned 0
Tue, 24 Mar 2009 11:32:28 PostSoapRequest() Write returned 0
Tue, 24 Mar 2009 11:32:30 ReadSoapResponseToFile() StartSession returned 0, and status 200
Tue, 24 Mar 2009 11:32:30 ReadSoapResponseToFile() Read returned 0, and read 1809 bytes
Tue, 24 Mar 2009 11:32:30 GetCertificate() Found cert file
Fri, 17 Apr 2009 09:33:12 Response problem; ret = 4, status = 0
If I then request a new cert, it works fine. But for how long? I just confirmed this issue this morning, so I'm not sure if the cert lasts until a reboot or what.
Anyone have any ideas?
I'm not sure if I understood correctly or not but when you replace a Gateway you don't need to replace the certs on the clients or core. The Gateway bridges incoming connections from the core and clients so as long as the IP of the Gateway doesn't change (or something doesn't happen to the certificates on the core) there should be no need to replace the certs.
As I look through the test results they look fairly normal. (I assume the core server and other entries were changed) It appears at the bottom that the connection was severed perhaps because it was taking too long. I have seen a previous call like this where deleting all the files from %programfiles%\LANDesk\Shared Files\cbaroot\broker and then submitting for new certificates corrects the problem. Here are a few questions that I have:
Are you deleting the files first?
Are their any Global Policies related to secure websites, encryption, perhaps enforcing other certificates (for wireless for example) into IE, etc?
The broker does read Proxy Server and other settings from IE. I have seen a few cases where certificates from other sources cause some issues when they are placed in IE.
Sorry about the delay. I was out for a couple of weeks somewhat unexpectedly.
I'm not deleting files first; just re-running brokerconfig. I don't think there are any such global policies, but I'll check with my coworker. We're not on a domain, but we're still using local security policies.
If you don't mind doing a few tests I think we might be able to find out what is going on with the BrokerConfig messages you are getting. I don't know why your certs would be getting invalidated, but we can treat one issue at a time.
Can you stop and start the LANDesk Management Gateway service on the core server, wait about 3 minutes (the service doesn't fully load for a little over two minutes) and then run BrokerConfig from a remote client. If that works, try to get certs again and let me know if it times out. If so, restart the broker service, wait two minutes and try one more time (to verify that it really works the first time after a reboot).
Let me know if that makes a difference or not.
Well, we replaced our iso MG last night with a brand new MG appliance, so that involved restarting the service, etc. Afterwards, as a test, I set up a fresh client with a new install of our agent, and got the certificate. This morning, that machine is behaving as the others; invalid cert. Same test results as I posted earlier. I don't want to fix it just yet, in case there's anything that anyone else wants me to check.
On the client machine go to \Program Files\LANDesk\Shared Files\cbaroot\broker and see if you have the files broker.crt, broker.cer, and broker.key. If they are named with a .1 or .2 behind them then it means that the cert is now invalid. Depending on whether we've got what appears to be valid certs (no number, just broker.cer .key and .crt) or if we appear to be somehow invalidating our certs we can go from there.
Either way a copy of the brokerconfig log file would be extremely helpful. It's in the LDClient folder.
OK, here's what I've got. It doesn't look like they're invalid per the file list. Here's the screenshot and the log.
The test output:
26:15.008 Attempting Direct HTTP connection to host hindmost.hhmi.org:80
26:15.008 Starting HTTP session with host hindmost.hhmi.org:80, proxy "", and proxy user ""
26:15.023 Unable to resolve host hindmost.hhmi.org address 255.255.255.255
26:15.023 Direct connection failed 6 Name resolution error
26:15.023 Using certificate file C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.crt and keyfile C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.key
26:15.023 Certificate/key loaded. Certificate file "C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.crt". Key file "C:\Program Files\LANDesk\Shared Files\cbaroot\broker\broker.key"
26:15.023 Attempting managment gateway connection at host and address nessus.hhmi.org
26:15.023 Starting HTTPS session with host nessus.hhmi.org, proxy "", and proxy user ""
26:15.023 Connecting to address 220.127.116.11
26:15.304 Waiting for link connection to core through managment gateway
26:15.304 Begining link request
26:15.304 HTTPS Request: POST /services/link
26:15.304 Waiting for match response
26:15.304 Waiting for HTTPS response
26:15.304 HTTPS response finished status 201 description Created
26:15.320 Creating session from client computer through managment gateway to core computer
26:15.320 Starting long session client
26:15.320 Match request completed 0 Success
26:15.320 Link to core successful
26:15.320 HTTPS Request: POST /landesk/managementsuite/core/RemoteControlLogging/RemoteControlLog.asmx
26:15.320 Waiting for HTTPS response
26:15.335 Error 4 Closed reading response line
OK, we've got 503 errors in the brokerconfig log file. 503 means service unavailable. That could mean that all connections are full to the broker, so no new connections will be accepted, or (more likely) that the Gateway service on the Core is not responding, or not successfully making connections. Could you attach the brokerservice.log file from the managementsuite directory on the core server?
If a reboot of the Gateway temporarily resolves this issue then I would say that connections being used would actually be more likely than not, so let me know about that too.
For anyone who looks at this thread after, I worked with Kevin and we redeployed certificates to all the affected machines, and they are now running as stable as can be.
We weren't able to determine a root cause of them going "bad", but they are all working now.
He had originally deployed using ConfigureBroker, and he has a third party patching utility (that LANDesk will be replacing, I believe). We used a batch file to clear the cbaroot/broker folder and put the brokerconfig.lng file in place and had that sent using the other utility.
Well, we kind of cheated, in a few ways. Firstly, I had configurebroker.exe, and a configured broker for configurebroker for brokerconfig. If you follow. So Mach6 wrote a little batch script to torch the old certs and use the .lng file to reestablish the certificate.
Many of our machines were VPN'd into the core network at the time, so we were able to do a push deployment of the batch script to them. For the others, we used another patch product so that the machines could pull down the batch file.