activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Justin Bertram (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (ARTEMIS-577) Do not log a stack trace in case of expired certificate
Date Mon, 20 Jun 2016 22:10:58 GMT

     [ https://issues.apache.org/jira/browse/ARTEMIS-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Justin Bertram closed ARTEMIS-577.
----------------------------------
    Resolution: Won't Fix
      Assignee: Justin Bertram

I'm not clear on whether or not you're talking about the server or the client.  However, in
either case I don't believe it's possible to consistently determine the cause of the exception
with the specificity you're looking for.  The {{javax.net.ssl.SSLHandshakeException}} thrown
to the Netty channel handler doesn't have any meta-data to determine why exactly the hand-shake
failed and the exception's message is equally generic (i.e. "General SSLEngine problem").
 Also, any checks for particular exceptions from the {{sun.security.*}} package would fail
on other JVMs (e.g. from IBM).

Lastly, the situation here deals with a failed _handshake_ which is managed by the JVM and
Netty and doesn't provide much (if any) opportunity to log details about the client's DN.
 If the handshake succeeds but authentication of the client's certificates fails that's a
different story.

> Do not log a stack trace in case of expired certificate
> -------------------------------------------------------
>
>                 Key: ARTEMIS-577
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-577
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>            Reporter: Lionel Cons
>            Assignee: Justin Bertram
>
> When trying to authenticate using an expired certificate, Artemis logs a very noisy stack
trace:
> {code}
> 2016-06-20 09:13:56,571 [io.netty.channel.DefaultChannelPipeline] WARNING An exceptionCaught()
event was fired, and it reached at the tail of the pipeline. It usually means the last handler
in the pipeline did not handle the exception.: io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException:
General SSLEngine problem
> 	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:380)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:244)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:308)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:294)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:846)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:131)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:511) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:468)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:382) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:354) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_92]
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> 	at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1431) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:535) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:813) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_92]
> 	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_92]
> 	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1138) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1028) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:968) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:349)
[netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	... 11 more
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> 	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:304) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1909) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:230) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker$1.run(Handshaker.java:919) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker$1.run(Handshaker.java:916) [jsse.jar:1.8.0_92]
> 	at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.8.0_92]
> 	at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1369) [jsse.jar:1.8.0_92]
> 	at io.netty.handler.ssl.SslHandler.runDelegatedTasks(SslHandler.java:1164) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1067) [netty-all-4.0.32.Final.jar:4.0.32.Final]
> 	... 13 more
> Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
> 	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:387) [rt.jar:1.8.0_92]
> 	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292) [rt.jar:1.8.0_92]
> 	at sun.security.validator.Validator.validate(Validator.java:260) [rt.jar:1.8.0_92]
> 	at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:324) [jsse.jar:1.8.0_92]
> 	at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:279)
[jsse.jar:1.8.0_92]
> 	at sun.security.ssl.X509TrustManagerImpl.checkClientTrusted(X509TrustManagerImpl.java:130)
[jsse.jar:1.8.0_92]
> 	at sun.security.ssl.ServerHandshaker.clientCertificate(ServerHandshaker.java:1896) [jsse.jar:1.8.0_92]
> 	... 21 more
> Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
> 	at sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
[rt.jar:1.8.0_92]
> 	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
[rt.jar:1.8.0_92]
> 	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:280) [rt.jar:1.8.0_92]
> 	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:382) [rt.jar:1.8.0_92]
> 	... 27 more
> {code}
> A single line warning such as "expired certificate" or "invalid certificate" (along with
the culprit DN) would be enough.
> As a general comment, all failed X.509 based authentications should log the culprit DN,
just like failed plain authentications log the user name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message