pushy: handshake_failure
I’m getting this ugly error in my production env ( CentOS 7 ):
2016-05-12 07:21:32.267 INFO 9786 --- [ main] com.relayrides.pushy.apns.ApnsClient : OpenSSL (via netty-tcnative) not available; will use JDK SSL provider.
2016-05-12 07:21:32.472 WARN 9786 --- [ main] com.relayrides.pushy.apns.ApnsClient : Asked for socket channel class to work with null event loop group, returning NioSocketChannel class.
2016-05-12 07:21:33.320 INFO 9786 --- [ntLoopGroup-2-1] com.relayrides.pushy.apns.ApnsClient : Failed to connect.
javax.net.ssl.SSLException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:219) ~[na:na]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666) ~[na:na]
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634) ~[na:na]
at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800) ~[na:na]
at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083) ~[na:na]
at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907) ~[na:na]
at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) ~[na:na]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) ~[na:1.8.0_71]
at io.netty.handler.ssl.JdkSslEngine.unwrap(JdkSslEngine.java:82) ~[netty-handler-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1098) [netty-handler-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:970) [netty-handler-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:904) [netty-handler-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:387) [netty-codec-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:245) [netty-codec-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.ChannelHandlerInvokerUtil.invokeChannelReadNow(ChannelHandlerInvokerUtil.java:83) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.DefaultChannelHandlerInvoker.invokeChannelRead(DefaultChannelHandlerInvoker.java:154) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:354) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:145) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:1078) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:117) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:527) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:484) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:398) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:370) [netty-transport-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:742) [netty-common-4.1.0.CR7.jar!/:4.1.0.CR7]
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:145) [netty-common-4.1.0.CR7.jar!/:4.1.0.CR7]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_71]
2016-05-12 07:21:33.350 WARN 9786 --- [ntLoopGroup-2-1] .s.ApplicationProtocolNegotiationHandler : [id: 0xea75c5a3, L:/172.16.1.14:45883 - R:api.push.apple.com/17.110.227.95:443] TLS handshake failed:
But the same software with the same p12 certificate runs fine in my development machine ( Mac ). So it cannot be a certificate issue…
Can you help me?
Best regards
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Comments: 17 (8 by maintainers)
Huh. That’s surprising, but I’m not sure if I’d call it an OpenJDK “bug” per se. If the problem is a missing cipher suite, I wonder if using a different JCE provider (BouncyCastle?) would help.
@fjordansilva I faced the same problem. Do NOT use openjdk 8 (I don’t think openjdk 7 is a good choice either). It is a bug of openjdk and maybe also a bug for APNs. Although the cipher suite use DHE, it really won’t work. Jdk 8 from Oracle will use ECDHE, which works fine. However, if I enable ECDHE and forbid DHE in java.security file under openjdk 8, then there is an error: no suite to use. My solution is to use JDK 8u91 from Oracle.
Centos 7 using: openjdk version “1.8.0_91” OpenJDK Runtime Environment (build 1.8.0_91-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
and alpn-boot-8.1.7.v20160121.jar
Mac OSX El Capitan v10.11.4 using: java version “1.8.0_20” Java™ SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot™ 64-Bit Server VM (build 25.20-b23, mixed mode)
and alpn-boot-8.1.0.v20141016.jar
Seems right to me…