DecoderException: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown with 4.1.7

Expected behavior

No DecoderException on server emitted if client rejects HTTPS connection, as per 4.1.6.

Actual behavior

This is emitted through the pipeline …

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:341)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:363)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:349)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:129)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:642)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:565)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:479)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:441)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
	at ratpack.exec.internal.DefaultExecController$ExecControllerBindingThreadFactory.lambda$newThread$0(DefaultExecController.java:136)
	at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLException: Received fatal alert: certificate_unknown
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1666)
	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1634)
	at sun.security.ssl.SSLEngineImpl.recvAlert(SSLEngineImpl.java:1800)
	at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:1083)
	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:907)
	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
	at io.netty.handler.ssl.SslHandler$SslEngineType$2.unwrap(SslHandler.java:218)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1028)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:950)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
	... 17 more

The exact same code does not emit this exception with Netty 4.1.6.

AFAICT, all that is happening is that the client is failing the https handshake (which is what I expect in this case). I expect that the channel is closed without this exception being emitted.

Steps to reproduce

TBA.

Minimal yet complete reproducer code (or URL to code)

TBA.

Netty version

4.1.7 (and 4.18 and 4.1.9)

JVM version (e.g. java -version)

OS version (e.g. uname -a)

Mac OS.

[ldaley]

@normanmaurer I think we are talking past each other on one point. I’m not saying anything should change regarding SslHandshakeCompleteEvent. What I am advocating for is returning to the 4.15 behaviour were this scenario does not cause an exception to be propagated through the handler pipeline that requires some kind of user action to avoid log noise.

Will provide a test case.

[ldaley]

@normanmaurer this isn’t the most useful behaviour for a Netty user. I can’t imagine many cases where a server implementor wants to treat this as an error. Moreover, I can’t see any way as a server implementor to prevent this exception from happening. The only thing I can do is catch, inspect (i.e. look at type and message), and ignore.

Seems like it would be better for the SslHandler to emit a user event describing the handshake failure.