Are you wanting to extract cert data on the client or the broker? The broker already uses code like this to get cert data [1]. The problem in your case is that the SSL handshake fails so the broker has no chance to inspect the cert data on the connection.
Justin [1] https://github.com/apache/activemq-artemis/blob/main/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/CertificateUtil.java On Thu, Apr 3, 2025 at 2:16 AM Shiv Kumar Dixit <shivkumar.di...@it.eurofinseu.com.invalid> wrote: > Hi Justin, > Thanks for input. > > Also, we came across this link > https://stackoverflow.com/questions/9777864/how-can-i-get-the-client-certificate-in-netty-handler-to-identify-user > where it seems we can extract SSL information from ChannelHandlerContext > ctx object. Do you see if it is feasible? > > ChannelHandlerContext ctx = ... > SslHandler sslhandler = (SslHandler) ctx.channel().pipeline().get("ssl"); > > sslhandler.engine().getSession().getPeerCertificateChain()[0].getSubjectDN()); > > Best Regards > Shiv > > -----Original Message----- > From: Justin Bertram <jbert...@apache.org> > Sent: 28 March 2025 10:42 PM > To: users@activemq.apache.org > Subject: Re: Additional Info on certificate based authentication errors > > > > Unverified Sender: The sender of this email has not been verified. Review > the content of the message carefully and verify the identity of the sender > before acting on this email: replying, opening attachments or clicking > links. > > > One option to improve this situation for Core [1] and OpenWire [2] clients > is to specify the "local" port which will then be printed on in broker log > along with the IP address. By default both clients use a random, available > port which makes correlation difficult, if not impossible, in my > circumstances. Of course, every client which does this will need to use a > unique port to ensure there are no conflicts if they are all running on the > same machine. > > Let me know where you reached out to the Netty community and I'll follow > along. > > > Justin > > [1] > > https://activemq.apache.org/components/artemis/documentation/latest/configuring-transports.html#configuring-the-transport#:~:text=localPort > [2] > > https://activemq.apache.org/components/classic/documentation/how-do-i-define-a-local-address-and-local-port-for-tcp-or-ssl > > On Fri, Mar 28, 2025 at 10:12 AM Shiv Kumar Dixit > <shivkumar.di...@it.eurofinseu.com.invalid> wrote: > > > Hello Justin, > > Thanks for the response. > > > > We have clients using Core/AMQP/OpenWire with certificates. > > > > Passing SSL debugging flag is good idea but given we have many clients > > using broker concurrently, I fear we will have lot of logs and it will > > be difficult to analyse. I am also checking with netty community if > > they can provide some input. > > > > Best Regards > > Shiv > > > > -----Original Message----- > > From: Justin Bertram <jbert...@apache.org> > > Sent: 28 March 2025 08:33 AM > > To: users@activemq.apache.org > > Subject: Re: Additional Info on certificate based authentication > > errors > > > > > > > > Unverified Sender: The sender of this email has not been verified. > > Review the content of the message carefully and verify the identity of > > the sender before acting on this email: replying, opening attachments > > or clicking links. > > > > > > Unfortunately I don't think the broker itself will be able to provide > > additional information because it simply doesn't have it. The SSL > > handshake is delegated by Netty to the JDK (or potentially to OpenSSL) > > and it's the first thing done when the client connects. It happens > > before the messaging protocol handshake takes place so there's > > definitely no way to get the client ID because it hasn't been sent > > yet. Netty only provides a Throwable [1] and we print the relevant > information from it. > > > > It's possible you could get some relevant information from Java's SSL > > debug logging by passing something like > > -Djavax.net.debug=ssl:handshake to the JVM at startup. > > > > What kind of client are you using to connect to the broker in this case? > > > > > > Justin > > > > [1] > > > > https://gith/ > > ub.com%2Fapache%2Factivemq-artemis%2Fblob%2Fc4b315ba0c1fafbe2d2c3ebf0c > > dd84f921f42b5a%2Fartemis-server%2Fsrc%2Fmain%2Fjava%2Forg%2Fapache%2Fa > > ctivemq%2Fartemis%2Fcore%2Fremoting%2Fimpl%2Fnetty%2FNettyAcceptor.jav > > a%23L1014&data=05%7C02%7C%7C2d25dad5c33e4432379808dd6e1bbbe3%7C1a1dce2 > > 021b14beaa9d2130e9f1f6e2f%7C0%7C0%7C638787787610427088%7CUnknown%7CTWF > > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > > kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nJBF0dMqmOiPJdlUMBj > > 3q3Ia01NII0ykmP6XQisV%2Bao%3D&reserved=0 > > > > On Thu, Mar 27, 2025 at 2:03 AM Shiv Kumar Dixit > > <shivkumar.di...@it.eurofinseu.com.invalid> wrote: > > > > > Hi team, > > > Currently we are using Apache Artemis 2.37.0. We have > > > certificate-based customers. Many times, we see errors like below in > > broker log: > > > > > > AMQ222208: SSL handshake failed for client from /a.b.c.d:53838: > > > javax.net.ssl.SSLHandshakeException: Empty server certificate chain. > > > > > > AMQ222208: SSL handshake failed for client from /a.b.c.d:59132: > > > java.security.cert.CertificateExpiredException: NotAfter: Tue Mar 25 > > > 00:00:11 IST 2025 > > > > > > AMQ224088: Timeout (10 seconds) on acceptor "artemis" during > > > protocol handshake with /a.b.c.d:62403 has occurred. > > > > > > Here we only get customer IP along with error message. In real > > > world, we have many customer applications running from same IP but > > > not all use expired certificate or invalid certificate. We may have > > > only of such misbehaving client. Troubleshooting such cases require > > > validating all customer applications on single IP to trace the > > > issue. It is very time consuming as we need to check customer > > > configuration, start/stop applications to see how it impacts the > broker error etc. > > > > > > Can we get some additional information such as client id, > > > certificate CN details or any other certificate information which > > > can help us in identifying the erring client faster? If there is any > > > log level change which can enable to put such information in broker > log will be helpful. > > > > > > Thanks > > > Shiv > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > > For additional commands, e-mail: users-h...@activemq.apache.org For > > further information, visit: > > https://acti/ > > vemq.apache.org%2Fcontact&data=05%7C02%7C%7C2d25dad5c33e4432379808dd6e > > 1bbbe3%7C1a1dce2021b14beaa9d2130e9f1f6e2f%7C0%7C0%7C638787787610439797 > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XRb > > daTuyVGNgBH%2FDdvihBuYzv%2BiATnFUfURp8IU2L%2B4%3D&reserved=0 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org > For additional commands, e-mail: users-h...@activemq.apache.org > For further information, visit: https://activemq.apache.org/contact > >
