[
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)
