AIX Nolio Agent Install - Handshake Issue

[Parthiban SG]

Hi All,

I installed AIX agent in my machine (nolio_agent_aix_6_6_0_b9640.sh) and after installation, agent doesn't get connected with NES server because of handshake issue

javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at com.ibm.jsse2.ib.A(ib.java:350)
at com.ibm.jsse2.SSLEngineImpl.b(SSLEngineImpl.java:28)
at com.ibm.jsse2.SSLEngineImpl.a(SSLEngineImpl.java:479)
at com.ibm.jsse2.SSLEngineImpl.unwrap(SSLEngineImpl.java:529)
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:24)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:868)
at org.jboss.netty.handler.ssl.SslHandler.decode(SslHandler.java:605)
at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:282)
at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:214)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349)
at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
at org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:949)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:973)
at java.lang.Thread.run(Thread.java:767)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at com.ibm.jsse2.p.a(p.java:10)
at com.ibm.jsse2.SSLEngineImpl.a(SSLEngineImpl.java:122)
at com.ibm.jsse2.ib.a(ib.java:319)
at com.ibm.jsse2.ib.a(ib.java:437)
at com.ibm.jsse2.jb.a(jb.java:565)
at com.ibm.jsse2.jb.a(jb.java:25)
at com.ibm.jsse2.ib.s(ib.java:582)
at com.ibm.jsse2.ib$1.run(ib$1.java:2)
at java.security.AccessController.doPrivileged(AccessController.java:448)
at com.ibm.jsse2.ib$c_.run(ib$c_.java:5)
at org.jboss.netty.handler.ssl.SslHandler$2.run(SslHandler.java:989)
at org.jboss.netty.handler.ssl.ImmediateExecutor.execute(ImmediateExecutor.java:37)
at org.jboss.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:986)
at org.jboss.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:886)
... 12 more
Caused by: com.ibm.jsse2.util.h: No trusted certificate found
at com.ibm.jsse2.util.g.a(g.java:35)
at com.ibm.jsse2.util.g.b(g.java:74)
at com.ibm.jsse2.util.e.a(e.java:22)
at com.ibm.jsse2.pc.a(pc.java:51)
at com.ibm.jsse2.pc.a(pc.java:18)
at com.ibm.jsse2.pc.b(pc.java:99)
at com.ibm.jsse2.jb.a(jb.java:70)

After we migrated our NES to Self-Signed certificate, we are unable to make the connections. Similarly, we identified the issue with Linux/Windows agents but after importing self-signed certificate into Agent JRE (<Agent_DIR>/jre/lib/security/cacerts), agents (Linux/Windows) got connected to NES

However, I am unable to perform the same for AIX agent since AIX agent doesn't Agent JRE (<Agent_DIR>/jre/lib/security/cacerts). AIX agent has a symbolic link to Java location for <Agent_DIR>/jre/lib/ext and there is no link for <Agent_DIR>/jre/lib/security. Self-Signed certificate is already imported to default java location but no luck with AIX agent connection to NES

Can you please let me know where to import the self-signed certificate so that I don't receive handshake error in AIX agent?

Thanks

[Gregg Stewart]

Hello Parthiban, 

I believe the issue you're describing is explained here: https://knowledge.broadcom.com/external/article?articleId=204279

Kind regards,
Gregg

[Parthiban SG]

@Gregg Stewart Thanks for the suggestion but it seems solution is with Self-Signed certificate and interim solution can be to disable NES -> Agent secure connection

My question next would be to go for the disabling secure communication from NES to Agent since I tested it already for AIX and it works. However, my other agents (Linux and Windows) are connected to NES in secure way already. Do I need to restart all my agents? Will it cause any impact if I disable secure communication from NES to Agent for already connected and working agents?

[Gregg Stewart]

Hello, 

Regarding the need to restart other agents, I think it depends on:

1. If the option you implemented was to disable secure connections at the NES level then I don't think you should have to restart your other agents. The one exception to this is if the agents lose connection with the NES after configuring the NES to not communicate securely. Maybe because the agents are also configured to communicate securely. I was under the impression that in order for it to communicate securely, the NES had to have the communicate secure option set on its end. Otherwise, they'll communicate without SSL. I have personally seen where several hundred agents successfully reconnected to a NES after the NES was changed from communicating securely to not communicating securely. Though I'm not sure how all of those agents were configured. That's why I'm noting this item as a possible exception. 
2. If the option you implemented was to use your own custom certificates then this will impact all agents (Linux, Windows, AIX, etc..) reporting to that NES. In this scenario the custom certificates should be implemented on all agents that are configured to use a NES that has had its nimi certificate keystore/trustStore changed to address this issue. 

Kind regard,

Gregg