gwynlionhart opened a new issue, #4595: URL: https://github.com/apache/accumulo/issues/4595
**Describe the bug** When you setup a CredentialProvider JCEKS file with an alias "ssl.truststore.password" for use in the accumulo-client, then Accumulo will not be able to find and retrieve that value from the JCEKS. I got a bit lost, but I think what was happening was that the ClientConfConverter class was only ever looking for the server property "rpc.javax.net.ssl.trustStorePassword" and not the client-specific value. So long as I put "rpc.javax.net.ssl.trustStorePassword" as an alias into the JCEKs file I didn't have an issue. **To Reproduce** Steps to reproduce the behavior (or a link to an example repository that reproduces the problem): 1. Setup an accumulo-client.properties with basic info but importantly ssl enabled, a credential provider specified, and a ssl.truststore.path ``` #Whatever you have for instance.name and instance.zookeepers in accumulo.properties instance.name=instance instance.zookeepers=zookeeper:2181 #When defined, Accumulo will try to retrieve matching properties out of the jceks general.security.credential.provider.paths=jceks://file/path/to/accumulo/conf/accumulo.jceks auth.principal=accumulo auth.type=password auth.token=password #SSL Configuration ssl.enabled=true ssl.truststore.path=/path/to/accumulo/conf/ssl/truststore.jks ``` 3. Launch Accumulo itself with SSL enabled, then try to connect to Accumulo shell with the above accumulo-client.properties 4. See error ``` [root@accumulo scripts]# accumulo shell --config-file accumulo-client.properties 2024-05-23T13:27:21,382 [clients.ClientServiceThriftClient] WARN : Failed to find an available server in the list of servers: [ssl:accumulo:9997 (120000)] ``` With java debugging enabled you will see that it is giving an empty password to the truststore. And if you debug on line 172 of ClientConfConverter.java and click play a few times to see the properties it's looking for, you will find that it is only searching the for properties like "rpc.javax.net.ssl.trustStorePassword" **Expected behavior** Entering Client properties should work in the CredentialProvider lookup in the same way that we are able to use the Client properties in the accumulo-client.properties file. I'm unsure if that's feasible if the list of properties supported by Credentialprovider is defined by Hadoop and not Accumulo. In which case, another (easier) solution would be to update the list of properties in the documentation to include a caveat about CredentialProviders and how the property name conversion thing means you need to put the server property into the JCEKS. For example, in the Description column of "ssl.truststore.password" you could include "Note: if protecting this property in a CredentialProvider specified in 'general.security.credential.provider.paths', then you must use the property "rpc.javax.net.ssl.trustStorePassword" inside of the CredentialProvider." Semi-related when it comes to properties documentation, but I think there are a few server properties you _do_ need to specify in accumulo-client.properties that aren't documented on the client properties page. For example, if Accumulo is using TLSv1.3, then the accumulo-client.properties file _has_ to specify "rpc.ssl.client.protocol=TLSv1.3" though that property is only listed in the server properties page, otherwise you get infinite "2024-05-23T13:34:54,194 [transport.TIOStreamTransport] WARN : Error closing output stream. java.net.SocketException: Connection or outbound has closed " stack traces. You have to put the property in both server and client property files if the value isn't the default TLSv1.2, or else "accumulo-cluster stop" will throw a similar error. Oh, and currently the client properties don't mention that general.security.credential.provider.paths is a supported property either, though I'm very grateful that it is supported still. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org