I am trying to find out the reason for below errors in smps.log. This error is continuously logged in smps logs. I did check CA support articles and it says this error could occur if shared secret of agent is out of sync.
Here is the brief of environment I have:
a. Two policy servers to which agent connects to.
b. Key generation enabled only in one policy server
c. Dynamic agent key rollover once per day enabled in policy server which has key generation enabled.
d. Shared Secret rollover not enabled on any of the policy server.
Errors in smps logs:
5908/4632][Mon May 04 2015 10:48:02][CServer.cpp:1965][ERROR][sm-Tunnel-00010] Bad security handshake attempt. Handshake error: 3152
[5908/4632][Mon May 04 2015 10:48:02][CServer.cpp:1972][ERROR][sm-Tunnel-00030] Handshake error: Failed to receive client hello. Socket error 0
Solution that is given on CA article:
The solutions are
1). To delete the trusted host in policy server.
2). To delete SmHost.conf from web server.
3). Run the agent configuration wizard again to create new trusted host with new SharedSecret.
1. Is there any problem in the key generation setup that I am using in my environment?
2. If I have not enabled shared secret rollover, then how can shared secret go out of sync with the policy server? Does it have anything to do with encryption key?
3. I have tried re-registering the agent multiple times but this error is persistent. Any suggestions?
R: I didn't see any problem with the key generation setup.
R: Shared secret is what web agent use to establish trust with policy server. You didn't enable shared secret rollover means the Shared secret used in SmHost.conf will not get updated. However, the web agent can still use the Shared Secret in SmHost.conf to establish trust/connection with policy server.
R: To get a correct direction, first we need to know if the handshake error cause any outage to your applications. If those errors just printed in the smps.log continuously while your applications are working fine, then I suspect some unused component trigger the error.
The solution suggested in the KB is mainly address if the agent has problem to communicate with the policy server.
Hi Kar Meng,
Handshake error is not causing any outage. Application is working fine when used in browser. Actually performance testing is going on in this environment so wanted to confirm if this could cause any problem in performance.
There is one unusual call that load balancer makes to web servers. It's just a ping to web server without any resource, so smwa.log writes NO valid HTTP RESOURCE in the request.
Could this be the reason for smps.log writting this error?
Other than that I don't see any other component accessing this request.
I wanted to understand on this line as well?
"the web agent can still use the Shared Secret in SmHost.conf to establish trust/connection with policy server."
Why would there be any problems if web agent is using shared secret present in SmHost.conf? if it has not been rolled over, it should always be identified by policy server as it will have record of that shared secret.
The hand shake is the result of the LoadBalancer - it would be the same message if you tried to telnet to one of the SM ports "telnet xx.xx.xx.xx 44443" no hostheader sent it the request - this will cause no problems, however it will fill the log file.
To accommodate testing tools/monitors that do not send HOST headers
Defines a value for the HOST header. Add this parameter to your Agent Configuration Object or LocalConfig.conf file to use a testing or performance tool that sends HTTP version 0.9 or version 1.0 requests (without HOST headers). If this parameter is not set, the Web Agent only accepts HTTP 1.1 requests.
Hope this helps
For your question:
Why would there be any problems if web agent is using shared secret present in SmHost.conf? if it has not been rolled over, it should always be identified by policy server as it will have record of that shared secret
R: Shared secret is web agent use to initial communication with policy server. In your case, shared secret is not rollover so the shared secret in SmHost.conf is valid and the communication with policy server can established. To answer your question, there is no problem.
In case of you configure rollover the shared secret, then the shared secret in SmHost.conf need to be updated. The old shared secret become invalid for security purpose. You can check following KB on how the shared secret rollover works.
Hope this helps.
Very well explained. It certainly answers my question. Many thank for the help Karmeng