SSLHandshakeException with okhttp - java

My code connects to apns for push notification. Am using clevertap library from git(https://github.com/CleverTap/apns-http2). It uses okhttp for the connection. When I run code on IBM WAS 8.5.5 and am receiving SSLHandshakeException. Details below. Can you pls help me on how to address this? Am trying with Synchronous mode of sending push message. I use Java 1.7, WAS 8.5.5. Pls let me know if you need more details.
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at com.ibm.jsse2.j.a(j.java:23)
at com.ibm.jsse2.j.a(j.java:21)
at com.ibm.jsse2.qc.b(qc.java:465)
at com.ibm.jsse2.qc.a(qc.java:451)
at com.ibm.jsse2.qc.h(qc.java:759)
at com.ibm.jsse2.qc.a(qc.java:353)
at com.ibm.jsse2.qc.startHandshake(qc.java:800)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:299)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.java:268)
at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:160)
When I googled for the issue, it seems the issue is because of IBMJSSE2, the JSSE implementation used by Websphere, in not compatible with this solution.
The problem is that for this implementation, the cipher suite names may starts with SSL_ or TLS_ (IBM documentation), both accepted: but that is not true for OkHttp. But I could not find a work around that I can use to fix the problem.
I read that version 3.7 of the jar will fix the problem but am using 3.9.1 and still running into the same issue.
I have the certificate imported into WAS trust store. I also have TLS 1.2 in the environment.

Related

Why SOAP-UI has SSL handshake issues in version 5.6.0 but version 5.5.0 works perfectly fine?

Recently we secured our servers with SSL v1.2. We have a SOAP web-service and many endpoints are exposed on it. The endpoints were used to be called/tested with SOAP-UI 5.6.0 with no issues when SSL was not enabled, but now when we call it throws:
ERROR:javax.net.ssl.SSLException: Received fatal alert: record_overflow
The only workaround we came across was downloading SOAP-UI 5.5.0 and using it since it has no issues calling SSL-enabled web-services.
I also checked similar question here but unfortunately there is no solid answer on it.
Any idea about the reason is highly appreciated.

How to fix 'unknown_certificate' error of a self-signed TLS certificate in java play framework

I am trying to implement the HTTPS on an internal web application which uses Play framework (version 2.5) as a Backend framework and Angular as Frontend and I have created a self signed certificate with Keytool following the Play framework documentation:
https://www.playframework.com/documentation/2.5.x/CertificateGeneration.
Then I save the '.crt' file in cacerts (java keystore) and provide the .jks when starting the application with these additional commands:
-Dplay.server.https.keyStore.path="path-to-jks-file"
and -Dplay.server.https.keyStore.password="the-password-here"
But after trying to make a request to the server I get an error:
javax.net.ssl.SSLException: Received fatal alert: certificate_unknown (image below)
Although the handshake happens after that and the HTTPS works correctly. Any ideas how to solve this issue
Link to error image
I have fixed this issue now. The problem with Chrome Browser was on 'Subject Alternative Name' missing, which is required from Chrome 58+ and that caused the error during the tls handshake. After adding SAN property to the certificate the problem is gone.
I posted this answer to help anyone who might have the same problem...

com.ibm.jsse2.util.j: Certificate chaining error while accessing a page through https in notes agent

I have following situation - I want to get page content using https request and java agent. However, I'm getting following error message:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.j: Certificate chaining error
I already imported internet certificates to my local notes cacerts file, but nothing changed.
However, when I'm running same code in Eclipse, using keystore with certificates downloaded from page I try to receive and it works fine.
I'm out of ideas, any suggestions will be appreciated!
===EDIT===
Dmytro Pastovenskyi's answer helped me, but additionally to get rid of protocol_version exception I had to use following code, setting version of TLS used:
System.setProperty("https.protocols", "TLSv1");
It seems nessesary to establish connection to some sites using 1.6 IBM JAVA.
I had same issue some times before.
It looks like IBM Domino server more strict when it check certificates. Our administrator who at the beginning said that chain is correct later found an issue with chain (and yes, it worked for .NET/JAVA and other platform, just not with Domino). Try to find some online tools that verify chain.
Before chain is fixed you can simply disabled certificate validation. I've an article how to do it (+ some other articles that may help you). Have a look here: Disabling certificate validation in Java

How to solve sun.security.provider.certpath.SunCertPathBuilderException?

I have written some code to connect to my mail server and read emails. I am using POP3 using SSL connection. I have also added SSL certificate to the java keystore. But still i am getting the same exception. Please help. Thanks in advance.
Possible cause this exception would be the cert from the keystore does not match the cert from the server.
Checkout these link might be helpful to you:
Unable to Connect to SSL Services due to PKIX Path Building Failed sun.security.provider.certpath.SunCertPathBuilderException
How to handle invalid SSL certificates with Apache HttpClient?
I got the same error, I disabled always scan encrypted connections in the settings of my antivirus software, and it worked.
I have groovy script, and I was using #Grab(group='org.apache.commons', module='commons-collections4', version='4.2')
I could not runt it because of an error Error grabbing Grapes -- [unresolved dependency: org.apache.commons#commons-collections4;4.2: not found]
Using -Divy.message.logger.level=4 I saw I was having the following problem:
Server access error at url https://repo1.maven.org/maven2/org/apache/commons/commons-collections4/4.2/commons-collections4-4.2.pom (javax.net.ssl.SSLException: Received fatal alert: protocol_version)
My qick fix was to use JDK8 instead of JDK7 it seems that JDK8 has updated certificates and it worked

javax.net.ssl.SSLException illegal_parameter bouncycastle related?

I'm trying to upgrade from BouncyCastle bcprov-jdk14-124.jar (oooold) to bcprov-jdk14-143.jar. When I replace the old jar with the new jar and build everything, my software will no longer establish an SSL connection, failing with a javax.net.ssl.SSLException: Received fatal alert: illegal_parameter. Googling for "bouncycastle javax.net.ssl.SSLException illegal_parameter" yields a whopping 4 results.
Any suggestions on where to start debugging this?
Additional context:
client is on WinXP
server on CentOS, using Oracle Application Server
The client is attempting to establish an SSL connection for an AXIS2 POST.
When the server uses bcprov-jdk14-143 and the client uses bcprov-jdk14-124, the POST succeeds, but when the client is upgraded to 143, I get this error
I am a little bit confused about your setup. Your error is from JSSE but BC doesn't provide JSSE. I assume the error is from server, which uses SunJSSE. You probably use BC's TLS API from client to make the TLS connection (check if you have TlsProtocolHandler).
If this is the case, getting everything working is already a miracle on Java 1.4, I wouldn't upgrade anything. Before Java 5, Sun's JSSE is partially hard-wired to SunJCE so you are practically using 2 JCEs at the same time on the server. I played with TLS from BC before and I never got it working so you are way ahead of me :)
Why do you need to upgrade BC? In my opinion, there is no reason to use BC at all if you are on Java 1.4 or later. However, it requires code changes to remove it if you use TlsProtocolHandler.
The specific error is caused by server sending down a list of compression methods. There is no way to get around that. Nobody supports compression but they all send down a list with only Null method.

Categories