You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Lionel Cons (JIRA)" <ji...@apache.org> on 2016/06/21 05:53:57 UTC
[jira] [Commented] (ARTEMIS-577) Do not log a stack trace in case
of expired certificate
[ https://issues.apache.org/jira/browse/ARTEMIS-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341161#comment-15341161 ]
Lionel Cons commented on ARTEMIS-577:
-------------------------------------
FWIW, the expired client certificate was the client one.
Most Java programs I've seen report stack traces when they encounter unexpected situations and they want the developer to do something (hence the line numbers).
Expired client certificates are common, just like invalid passwords (typos). They indicate a kind of client configuration error and not something a developer should fix. A stack trace in this case is useless, a single {{WARN}} line is enough.
This is what ActiveMQ 5.x does. An expired certificate triggers the following one line warning:
{code}
2016-06-16 04:27:45,602 [ActiveMQ Transport: ssl:///192.1168.192.46:51995] WARN Transport - Transport Connection to: tcp://192.168.192.46:51995 failed: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed
{code}
The warning is a bit cryptic but we know it maps to an expired certificate and we also have the IP address of the culprit to fix the problem (renew the certificate).
IMHO, Artemis should be as good as ActiveMQ 5.x in this domain and log a single line warning (not a stack trace), with the source IP address (and maybe also the DN) to help the broker manager to get the problem fixed.
> 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)