-
|
Hello, We recently switched from old java-apns to pushy-apns, our service runs on IBM WebSphere Application Server 9.0. It worked fine with old java-apns library, while legacy push notification server was up, but pushy-apns has problems contacting apple server. I get this error java.util.concurrent.ExecutionException: io.netty.handler.proxy.ProxyConnectException: http, none, (our proxy uri)/(our proxy ip):8080 => api.push.apple.com:443, disconnected traffic is allowed through proxy. But in this case proxy doesn't even register that there was attempt for communication. I tried modifying this service so it would work on Tomcat server and when I use Tomcat instead of WAS it works, request gets to the proxy and successfully finishes. iOS device gets the notification as expected. So that means code is OK. We tried to solve it with our system guys but whatever we tried didn't work in case of WAS.. In the end we tried recording traffic with WireShark and there was one interesting frame, for some reason it won't upload screenshot here so I'm using imgbb.com Immediately after CONNECT request was sent server sends [FIN, ACK] request that terminates this CONNECT. Does anyone have an idea what could be the issue? We tried it even on "clean" WAS with default configuration and same thing happens, so it doesn't seem that it's someone in the company configured. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
To answer my own question after a lot of testing. Problem lies in IBM Java that runs the WAS. As last desperate attempt I tried running Tomcat with Java from WAS installation and got the same error. For some reason by default it provides only TLSv1.0, while "regular" Java (8) blend by default provides TLSv1.0, TLSv1.1 and TLSv1.2. On WAS this can be "fixed" by setting these parameters -Dcom.ibm.jsse2.overrideDefaultTLS=true but that will simply force it to provide only TLSv1.2 which might not be ideal if you have services or applications that need TLSv1.0. But if you set second parameter to -Dcom.ibm.jsse2.overrideDefaultProtocol=SSL_TLSv2 this will force it to provide TLSv1.0, TLSv1.1 and TLSv1.2 support, just like with "regular" Java. Contrary to expectaction SSL isn't enabled by default because of POODLE vulnerability. Though if you really really need it, it can also be enabled. More on that here: Just another not, setting these parameters on Tomcat didn't work, it still provided only TLSv1.0, it worked only on WAS. Probably because of difference how SSLContext and other things are implemented on IBM Java... |
Beta Was this translation helpful? Give feedback.
-
|
I'm glad you worked things out, and I'm sorry I couldn't be more help! Thank you for sharing the results of all your work and research. |
Beta Was this translation helpful? Give feedback.
To answer my own question after a lot of testing. Problem lies in IBM Java that runs the WAS. As last desperate attempt I tried running Tomcat with Java from WAS installation and got the same error.
For some reason by default it provides only TLSv1.0, while "regular" Java (8) blend by default provides TLSv1.0, TLSv1.1 and TLSv1.2.
On WAS this can be "fixed" by setting these parameters
-Dcom.ibm.jsse2.overrideDefaultTLS=true
-Dcom.ibm.jsse2.overrideDefaultProtocol=TLSv12
but that will simply force it to provide only TLSv1.2 which might not be ideal if you have services or applications that need TLSv1.0. But if you set second parameter to
-Dcom.ibm.jsse2.overrideDefaultProtocol=SSL_TLSv2
th…