Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

handshake_failure

See original GitHub issue

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

Issue Analytics

State:
Created 7 years ago
Comments:17 (8 by maintainers)

Top GitHub Comments

1reaction

jchamberscommented, May 20, 2016

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.

1reaction

huan-zhoucommented, May 20, 2016

@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.