gwynlionhart commented on issue #4595: URL: https://github.com/apache/accumulo/issues/4595#issuecomment-2252674707
My main issue was that some SSL properties _are_ handled by the CredentialProvider. If you put the value for the property "rpc.javax.net.ssl.trustStorePassword" or "rpc.javax.net.ssl.keyStorePassword" into a Credential Provider, and you have the property general.security.credential.provider.paths set to point to that credentialprovider store (JCEKS in my example), then Accumulo will retrieve the password out of the JCEKS rather than expecting the property to be in the properties file. In contrast (and where I thought an issue might be) is that the property "ssl.truststore.password" on the client side does not get treated in the same way. If you put that into the JCEKS, the Accumulo code doesn't find it, so it then looks in the properties file (where it also doesn't find it), then fails b/c it can't open the truststore. The quickest workaround (which I did) is that even on the client side I put "rpc.javax.net.ssl.trustStorePassword" as the alias for the truststore password entry in the JCEKS. That property works even on the client side because in that ClientConfConverter it ends up converting "ssl.truststore.password" into "rpc.javax.net.ssl.trustStorePassword" anyway. But I originally thought it may be a bug that the property wasn't being found like the server side property was found. But on the topic of security of the JCEKS: absolutely agree, not a long-term solution. I will be looking for a secure way to store the password for the user/root user/truststore/keystore in some other manner that doesn't amount to a plain text representation on the file system. Maybe implementing something off the CredentialProvider interface to grab passwords in some other secure manner -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
