1 of 1 people found this helpful
What do you see in the rscd.log? If in the rscd.log, you see something like this:
WARN rscd - 18.104.22.168 25778 -1/-1 (???): ???: TLS setup failed for agent: Protocol mismatch. Check that client and server "secure" files match. Exiting and terminating connection.
WARN rscd - 22.214.171.124 24859 -1/-1 (???): ???: TLS setup failed for agent: Protocol mismatch. Check that client and server "secure" files match. Exiting and terminating connection.
As suggested by the error message, the secure file on both the nsh client or appserver and the target server should be examined to ensure the appropriate entries match.
In rare cases, this seems to be caused by a communication issue between the appserver/nsh client and the target server and the RSCD agent should be restarted and the operation retested.
Generally this is caused when the secure file is different on the two hosts making contact. Ensure that both hosts are communicating using the same protocol and encryption levels. Always use the 'secadmin' utility for making any changes to the secure file.
This error can also be caused when Shavlik is running on the remote host, which is known to use port 4750, the same port that the RSCD agent uses. Try the following: Restart the RSCD agent, stop Shavlik, or reconfigure Shavlik to use a port other than 4750.
Another cause of this issue can be when network configurations on the application server are configured incorrectly. Ensure that your app server's TCP/IP settings are configured correctly, along with your DHCP server settings.
Hope this helps.
we saw a similiar issue before.
Support suggested to turn of "FIPS" encryption, which can be achieved by renaming the openssl.cnf file in the share directory of the RSCD agent to something else (e.g. openssl.cnf_BAK)
Encryption would still be enabled, but not in a FIPS mode any longer.
For now, the workaround, was to add a rule into the Firewall Inbound for port 4750 (TCP). That's how I got it working but my concern is why for other servers with same hardware and software configuration I didn't have to add this rue in Firewall? That's still a mistery, for me at least! I'll investigate further!
I have seen this when a server is part of the domain, the rule for the domain policy does not get entered.
I was getting the same error.
I fixed it by verifying my rsc (secure) file had these lines:
Originally added 4750 to firewall to no avail. Also restarted RSCD and no effect.
Can you telnet to the port from the appserver?
What does ‘agentinfo’ from the appserver return ?
What’s in the rsc files on the target ?
Agent Release : 126.96.36.199
Operating System: WindowsNT 6.1 (x86_64)
User Permissions: (Identity via trust)
Security : Protocol=5, Encryption=TLS1
Host ID :
# of Processors : 2
License Status : Licensed for NSH/CM
Export and secure files match on both source and target servers.
# Substitute Admin with a user with elevated permissions.
I'm having the same issue here, on a Windows 2008 R2 server where the agent was uninstalled, and then later re-installed.
Secure file content:
Agentinfo from App server:
agentinfo <server fqdn>
Can't access host "<server fqdn>": Error in TLS protocol.
I read in KB that one work around is to delete the certificate.pem from C:\windows\rsc directory (which I did), and restart the agent so it can re-create it. Well, it never recreated it.
8.1.02.262 RSCD x64 agent.
the appserver is the same version as the agent? did you have certificates enabled ?
if you put the agent log into debug do you see anything useful ?
Could anyone suggest same issue I am facing, firewall ports are open, other servers in same LAN are able to connect BSA, but only specific server is not connected.
Cross verifies the BSA agent port is using other applications using below command
nestat -ano | grep "4750" (windows machine)
it lists the port listening apps and porcess id using , kill that application, restart the RSCD agent and try connecting to BSA servers it will work.
Srini I recommend you open a new Discussion about your issue. Many people filter the Discussions by "Answered" and might not see your question.
Does this server have multiple IP's configured? If so, check which IP it's binding to and if the gateway/subnet/dns settings are correct for that IP.
I faced same error in my environment, the issue was: there was a thrid party application running on target which was using 4750 port. I made changes in target secure file with 4755 and everything worked for me.......