I have a Java application, from which I am trying to connect to a https url but having issues with SSL ending up with the error:
Received fatal alert: bad_record_mac
(javax.net.ssl.SSLException)
Using SSLPoke there is no issue connection to the URL.
For my Java Application some custom values are set for the keystore
cat sysprop.properties
#Mon, 09 Jan 2017 13:43:54 +0000
#bootstrapModulesResource=moduledefinitions.xml
property.folder=../config
ssl.port=8443
jetty.ssl.keystore=../config/keystore
jetty.ssl.keystore.password=xxxx
jetty.ssl.key.password=xxxx
#jetty.ssl.truststore=../config/truststore
#jetty.ssl.truststore.password=xxxx
application.ip.address=127.0.0.1
bootstrapModulesResource=moduledefinitions.xml
As SSLPoke is working fine I assume that its not a Java environment issue but more directly an issue with my set up for the application. Could a custom keystore be the cause for the bad record mac error?
This application is running on a production sever and the issue can't be replicated locally (its working fine locally).
How can I go about further debugging this issue?
Related
Im trying to run jmeter test in distributed mode, following to official documentation:
https://jmeter.apache.org/usermanual/remote-test.html
client - windows 7
server - ubuntu 20
But I have next error:
Creating summariser <summary>
Created the tree successfully using D:\r.jmx
Configuring remote engine: xxx.xxx.xxx.xxx
Starting distributed test with remote engines: [xxx.xxx.xxx.xxx] # Tue Apr 27 23
:29:27 EEST 2021 (1619555367546)
Error in rconfigure() method java.rmi.MarshalException: error marshalling argume
nts; nested exception is:
java.net.SocketException: Connection reset by peer: socket write error
Remote engines have been started:[]
The following remote engines have not started:[xxx.xxx.xxx.xxx]
Waiting for possible Shutdown/StopTestNow/HeapDump/ThreadDump message on port 44
45
How I can fix it or how to determine, what exactly I should fix?
Check the log files on both master and slave, most probably they contain the cause of the error or at least a cloue
Looking into the output my expectation is that there is something preventing network communication between the machines, make sure that:
machines can "see" each other, i.e. they are on the same subnet and you reach from master to slave and vice versa using ping/telnet commands
the following ports are open in the operating systems firewalls:
1099 or if you changed server_port property value this new port
the port you define as server.rmi.localport
the port(s) you define as client.rmi.localport
You can check out JMeter Distributed Testing with Docker article which provides comprehensive explanation of the network setup for the distributed more of running a JMeter test
I am getting the following error when trying to connect to IBM's Watson API:
java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.watson.developer_cloud.service.security.IamTokenManager.callIamApi(IamTokenManager.java:190)
at com.ibm.watson.developer_cloud.service.security.IamTokenManager.requestToken(IamTokenManager.java:108)
at com.ibm.watson.developer_cloud.service.security.IamTokenManager.getToken(IamTokenManager.java:78)
at com.ibm.watson.developer_cloud.service.WatsonService.setAuthentication(WatsonService.java:375)
at com.ibm.watson.developer_cloud.service.WatsonService.createCall(WatsonService.java:206)
at com.ibm.watson.developer_cloud.service.WatsonService.createServiceCall(WatsonService.java:240)
at com.ibm.watson.developer_cloud.assistant.v2.Assistant.createSession(Assistant.java:107)
[...]
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:318)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:282)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:167)
at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:257)
at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:135)
[...]
This is the Java code which tries to initiate the API call:
// Init assistant
IamOptions imaOptions = new IamOptions.Builder()
.apiKey(API_KEY)
.build();
assistant = new Assistant("2019-03-13", imaOptions);
assistant.setEndPoint(END_POINT_FRA);
// Create session
CreateSessionOptions options = new CreateSessionOptions.Builder(ASSISTANT_ID).build();
ServiceCall<SessionResponse> session = assistant.createSession(options);
The exception is thrown in the last line. Interestingly, I am able to connect perfectly fine when I run this through a stand-alone unit test. It is only when I try to connect from a server application that I get this SSL error.
I have already tried the following:
import all required SSL certificates into the applications's
truststore
set system property to support TLS 1.2 prior to TLS 1.1
verified that JCE full policy files are installed (as part of Java 11,
which is the version I am on)
used nmap to verify the server's cipher suites and check that they are supported by the JDK ( nmap -sV --script ssl-enum-ciphers -p 443 wildcard.bluemix.net )
I have also read through and followed these here articles:
Received fatal alert: handshake_failure through SSLHandshakeException
https://confluence.atlassian.com/jirakb/sslhandshakeexception-received-fatal-alert-handshake_failure-due-to-no-overlap-in-cipher-suite-943544397.html
I am a bit lost now. Any ideas what might be cuasing the SSL handshake problem or how I could diagnose it further?
==== Update ====
After digging around this topic, I think I have managed to isolate it. It seems to be an actual bug in Java 11.0.1, which is also still present in 11.0.2. Root cause is that Java 11 (OpenJDK) does not play nice with TLSv1.3, as described here: https://webtide.com/openjdk-11-and-tls-1-3-issues/ and in a bug report here https://bugs.openjdk.java.net/browse/JDK-8213202
Now the issue is how to disable TLSv1.3. I have already tried the solutions provided here https://blogs.oracle.com/java-platform-group/jdk-8-will-use-tls-12-as-default and here https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html (protocols and properties), but for some reason this disabling does not take effect in my case. My code is using the org.apache.http.impl.client.ClosableHttpClient and the Builder does not allow me access to the underlying SSLConnectionSocketFactory (where I might be able to disable TLSv1.3). So, the question remains: How can I disable TLSv1.3 in this particular setting?
(PS: The problem also occures when trying to access the Google NL and Vision APIs - language.googleapis.com and vision.googleapis.com)
There is a bug in JDK 11.0.1 and 11.0.2 related to TLSv1.3. This version of the TLS protocol needs to be disabled by setting the following system property:
-Djdk.tls.client.protocols=TLSv1.1,TLSv1.2
Presumably, this bug will be fixed with the release of JDK 11.0.3., which is due mid-April '19.
i have some strange situation:
When i am trying to start managed server on the console i get the following error on Nodemanager:
PM weblogic.nodemanager.server.Handler run
WARNING: I/O error while closing socket connection
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:135)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at weblogic.utils.io.ChunkedInputStream.read(ChunkedInputStream.java:159)
at weblogic.security.SSL.jsseadapter.JaSSLEngineRunner$Context.fillBufferNetIn(JaSSLEngineRunner.java:323)
at weblogic.security.SSL.jsseadapter.JaSSLEngineRunner$Transition_NeedUnwrap.getNextState(JaSSLEngineRunner.java:822)
at weblogic.security.SSL.jsseadapter.JaSSLEngineRunner.doTransitions(JaSSLEngineRunner.java:763)
at weblogic.security.SSL.jsseadapter.JaSSLEngineRunner.closeInbound(JaSSLEngineRunner.java:1279)
at weblogic.security.SSL.jsseadapter.JaSSLEngineRunner.close(JaSSLEngineRunner.java:1365)
at weblogic.security.SSL.jsseadapter.JaAbstractSSLSocket.close(JaAbstractSSLSocket.java:245)
at weblogic.nodemanager.server.Handler.run(Handler.java:85)
at java.lang.Thread.run(Thread.java:745)
But when i am trying to start Managed Servers from command-line then it works correctly:
nohup ./startManagedWebLogic.sh server1 t3://xx.xx.xx.xx:7001 >/dev/null 2>&1 &
In oracle Documentation i found that this issue can happen when in nodemanager.properties file the following line is set to false:
NativeVersionEnabled=false
After i set it to true the issue is still persists.
The issue started after i did an Upgrade for Java from java jrockit to java JDK 1.80. I have also changed the certificates from Demo to custom.
Did someone had this issue before and knows how to fix it?
In the nodemanager.properties file set the SecureListener attribute to false.
In the weblogic server admin console, configure the machine to not use a secured connection with the node manager (Node Manager tab)
These 2 options configure a non secured connection between the admin server and the node manager.
I try to connect to a wss (Secure Websocket) server with a java applet but the ssl handshake fails without any helpfull log entrys.
If I connect to wss://echo.websocket.org the handshake works fine, so I think it's not a general java code error.
If I try to connect to my own server, the HelloDone bit is sent (verified by wireshark) but the connections ends in a hang-up and it's not in the log. Normally there should be the following message in the log: "*** ServerHelloDone"
See my java console log of "javax.net.debug=sll"
http://pastebin.com/ZuvKww4J
It is not truncated, it simply ends there.
After a couple of seconds the tcp connection timeout message is added to the log.
I use the following example of java code:
https://github.com/TooTallNate/Java-WebSocket/blob/master/src/main/example/SSLClientExample.java
But instead of keystore I use:
sslContext.init( null, null, null );
For the server I have two different test systems:
At port 443 a ha-proxy
at port 8443 a stunnel.
I tried to isolate the error with different methods. First I forced with stunnel the same cipher as echo.websocket.org "SSL_RSA_WITH_RC4_128_SHA" but no success.
Second I checked if the ssl certificate itself is still valid. But as web browser and normal https connection by my java applet, are accepted from the server (Same server. ha-proxy orstunnel) everything is working at that point to.
Problem was solved by maintainer of Java-WebSocket.
Big thans
I am facing problem on a centOS server while sending java mails. Getting the following exception.
javax.mail.MessagingException: Could not connect to SMTP host: localhost, port: 25, response: -1
I used the following command from the command prompt and I got the mail as expected.
echo "testing" | mail -s"test subject" shantanu.oa#gmail.com
The relevant entry from maillog looks like this...
Mar 28 20:13:16 postfix/smtpd[10120]: fatal: no SASL authentication mechanisms
Mar 28 20:13:17 postfix/master[28163]: warning: process /usr/libexec/postfix/smtpd pid 10120 exit status 1
Mar 28 20:13:17 postfix/master[28163]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling
Mar 28 20:26:22 postfix/smtpd[11001]: warning: SASL: Connect to private/auth failed: Connection refused
How do I correct the problem?
From the log entry
Mar 28 20:13:16 postfix/smtpd[10120]: fatal: no SASL authentication mechanisms
I suspect that the problem is on Postfix, of which I'm not an expert. Googling for "fatal: no SASL authentication mechanisms" gives lots of interesting links: maybe have a look here or here.
From the exception it seems like its not able to connect to the host.
Have you tried the telnet stuff?
One more thing to check would be whether the name to IP resolution is taking place properly.If not you can use the IP directly in place of host to see what happens.
does your smtp-server needs authentication?
Seems so, because the cmd call with mail works. In default postfix configuration a local user is allowed to send mails without authentication. And your Java application might not be a registered system user on this maschine.
Try to provide username and password in your code to login to the smtp server.