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)

Most upvoted comments

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…