[ https://issues.apache.org/jira/browse/HBASE-28317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810110#comment-17810110 ]
ASF GitHub Bot commented on HBASE-28317: ---------------------------------------- bbeaudreault commented on code in PR #5644: URL: https://github.com/apache/hbase/pull/5644#discussion_r1464019537 ########## hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServer.java: ########## @@ -413,6 +415,19 @@ private void initSSL(ChannelPipeline p, boolean supportPlaintext) sslHandler.setWrapDataSize( conf.getInt(HBASE_SERVER_NETTY_TLS_WRAP_SIZE, DEFAULT_HBASE_SERVER_NETTY_TLS_WRAP_SIZE)); + sslHandler.handshakeFuture().addListener(future -> { Review Comment: @Apache9 do you think a listener is the right approach here? I'm wondering if we should instead pass the SSLHandler into NettyServerRpcConnection, and directly call `handler.handshakeFuture().get()` in `setupHandlers()`. That way it's more explicit that we have the certificate on the connection prior to handling any requests. With the listener approach, I'm not 100% sure we can guarantee that the listener is executed in the eventLoop prior to the channelRead0 in NettyRpcServerPreambleHandler. > RpcCallContext should expose client's TLS certificate > ----------------------------------------------------- > > Key: HBASE-28317 > URL: https://issues.apache.org/jira/browse/HBASE-28317 > Project: HBase > Issue Type: Improvement > Reporter: Charles Connell > Assignee: Charles Connell > Priority: Minor > > At my employer we plan on using a coprocessor to log information about some > requests to HBase. For this to be useful to us, we need to know who each > request is coming from. We use HBase's TLS support with mutual authentication > to authenticate clients. I'd like a way to expose the client certificate used > on a request to coprocessors. For setups using Kerberos authentication, > RpcCall exposes the Kerberos principal shortname via {{getRequestUser()}}, so > this would be the TLS equivalent to that. -- This message was sent by Atlassian Jira (v8.20.10#820010)