SSLHandshakeE E SSLC0008E: Unable to initialize SSL connection

Hello Everyone,

Hope you all aware of SSL (Secure Socket Listener) . We normally face lot of issues during SSL configuration and after configuration while handshake. We have discussed many of them before also. Here today I was getting another one while handshake between client and server.

Error:

[4/10/15 10:44:20:024 EDT] 00000067 SSLHandshakeE E   SSLC0008E: Unable to initialize SSL connection.  Unauthorized access was denied or security settings have expired.  Exception is javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported
        at com.ibm.jsse2.K.B(K.java:141)
        at com.ibm.jsse2.SSLEngineImpl.b(SSLEngineImpl.java:106)
        at com.ibm.jsse2.SSLEngineImpl.c(SSLEngineImpl.java:184)
        at com.ibm.jsse2.SSLEngineImpl.wrap(SSLEngineImpl.java:582)
        at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:16)
        at com.ibm.ws.ssl.channel.impl.SSLUtils.handleHandshake(SSLUtils.java:746)
        at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.readyInbound(SSLConnectionLink.java:566)
        at com.ibm.ws.ssl.channel.impl.SSLConnectionLink.ready(SSLConnectionLink.java:295)
        at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
        at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:558)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:608)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:985)
        at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1074)
        at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1 not enabled or not supported

Cause :

While Searching for this error I came across very important and helpful information. Here we consider that you all aware of the  SSL Handshake term or we will discuss it in brief later. In SSL hand shake the two communicators i.e. client and server initiate connection with each other to perform the transaction. For handshake we are having a different protocols based upon client and server. There is condition that for handshake need the communication protocols on both side should be compatible. Here in case WebSphere application server is our server and the requesting client may be different. It may be Webserver or your java application or you web browser or any internal service.

Here consider in my case the client which is asking foe handshake is a java application. Almost all HTTPS requesting traffic from application is Java generated. So the protocol requested by my java application is not enabled on server side so it's not supporting the handshake.

Let's check the below table for more clarification.

Here in my case the application is running using the java 6 means it will support the minimum SSLv3** and Maximum TSLv1 Version. Here in case if I disable the SSLv3** support from my server side the my application will use the higher version of SSL to handshake and will establish the connection for transaction. But I disable the higher version i.e. TSLv1 then it is not possible to establish the hand shake. So it will show the error Client requested protocol TLSv1 not enabled or not supported. Same thin will happen vise versa .

Solution:

In such case you can go and check on Websphere application server console which version of SSL handshake protocol your server is supporting. For that go to the
SSL certificate and key management > SSL configurations > NodeDefaultSSLSettings (your Custom setting ) > Quality of protection (QoP) settings and check. Here in my case it was showing TLSv1.2 which is not supported by a client.

So here I go and set the protocol to TLSv1, which one client asking for. And now it's working fine.

For this click on the drop box, select the suitable protocol, Apply the change and don't forget to save it.


Hope this will help you. Kindly comment for your suggestion and quires.  

"Effort only fully releases its reward after a person refuses to quit.”

 Regards,
 Akhilesh B. Humbe

referenced in VMStructs::localHotSpotVMStructs in the remote VM, was not present in the remote VMStructs

Hello Everyone,

Hope you all are doing well. Today here we are discussing about taking the heapdump using a jmap command. Here I have one command which successfully generate the heapdump for your running java process. While executing this command I had faced one error, which is very command and I think need to discuss with you people.

How to generate a heap dump using java process id (pid) :

The jmap is a very good utility to generate a heapdump. Using below command you can generate the heapdump for running java process

Command : jmap -dump:format=b,file=TestFile.hprof PID

Where TestFile.hprof is the dump file name you can change it accordingly.
And PID is process id of running java process for which you want to generate the heapdump

But sometime while executing this command we get the below error:

Error :

Attaching to process ID XXXX, please wait...
Exception in thread "main" java.lang.RuntimeException: Type "nmethodBucket*", referenced in VMStructs::localHotSpotVMStructs in the remote VM, was not present in the remote VMStructs::localHotSpotVMTypes table (should have been caught in the debug build of that VM). Can not continue.
        at sun.jvm.hotspot.HotSpotTypeDataBase.lookupOrFail(HotSpotTypeDataBase.java:345)
        at sun.jvm.hotspot.HotSpotTypeDataBase.readVMStructs(HotSpotTypeDataBase.java:236)
        at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:70)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:544)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:476)
        at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:314)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:146)
        at sun.jvm.hotspot.tools.JMap.main(JMap.java:126)

Cause:

I was getting this error because my path to jmap wasn't the same as the path to the java process i.e. targeting two different versions. In such a case you need to set a proper path before executing the jmap command or execute command with full path of the java you are currently using.

i.e.  /opt/WebSphere85/java_1.7_64/bin/jmap -dump:format=b,file=TestFile.hprof 27693.

where /opt/WebSphere85/java_1.7_64 is my current version of java for webSphere server.

This command will generate you heapdump in your current working directory.

Hope this will help you. Kindly comment for your suggestion and quires.  

"Effort only fully releases its reward after a person refuses to quit.”

 Regards,
 Akhilesh B. Humbe

java.lang.OutOfMemoryError: PermGen space

Hello Everyone,

Today one of WAS 8.0.0.5 Server get crashed and was showing the below error in SystemOut.log

Error:

[04/03/15 10:27:47:004 GMT] 00013e2b servlet       E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0014E: Uncaught service() exception root caus
e spring-ws: org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.OutOfMemoryError: PermGen space

Cause:

As it's a java application running of WebSphere Application server it allocate some memory to run. The size of memory is split into different areas including PermGen Space. The size of all these areas set during the JVM startup. If you do not set the sizes yourself, platform specific defaults will be used. So  the “java.lang.OutOfMemoryError: PermGen space” message indicates that the Permanent Size area in memory is exhausted. And there are lot of reasons for this.

All Java classes are loaded and stored in the Java PermGen.All of these are allocated to PermGen and stay in PermGen.As you can see, the PermGen size requirements depend both upon the number of classes loaded as well as the size of such class declarations. So it is easy to see the main cause for the “java.lang.OutOfMemoryError: PermGen space“: either too many classes or too big classes are being loaded to the permanent generation.

Solution:

The first solution to the OutOfMemoryError due to PermGen should be obvious. If we have exhausted the PermGen area in the memory we need to increase its size. This solution is indeed helpful if you just have not given your JVM enough below room. So alter your application launch configuration and add (or increase if present) the following:
-XX:MaxPermSize=512m (Suitable Size)
This configuration parameter is indicating to the JVM that PermGen is allowed to grow up to 512 MB before complaining in the form of OutOfMemoryError.

Second Solution  is you can take the heap dump at the time of issue and analyze it to find which objects causes the OutOfMemoryError in PermGen space

Third possibility is to allow GC to unload classes from PermGen. The standard JVM is rather conservative in this regard  Classes are born to live forever. So once loaded, classes stay in memory even if no one is really using them anymore. This can become a problem when the application is creating lots of classes dynamically and the generated classes are not needed for longer periods. In such a case, allowing JVM to unload class definitions can be helpful. This is achieved by adding again just one configuration parameter to your startup scripts:
-XX:+CMSClassUnloadingEnabled
By default this is set to false and so to enable this you need to explicitly set the following option in Java options. If you enable CMSClassUnloadingEnabled, GC will sweep PermGen too and remove classes which are no longer used. Keep in mind that this option will work only when UseConcMarkSweepGC is also enabled using the below option. So when running parallel or, God forbid, serial GCs, make sure you have set your GC to CMS by specifying:
-XX:+UseConcMarkSweepGC
But before calling it a night, be warned  more often than not usage of the recommended “quick fixes” means you are just masking the symptoms by hiding “java.lang.OutOfMemoryError: Permgen space” and are not tackling the underlying problem.

I personally recommend you to use the 1st and 2nd solution. And hope it will help you to resolve the issue.

"Effort only fully releases its reward after a person refuses to quit.”

 Regards,
 Akhilesh B. Humbe