An issue was raised on the user list [1] that the Cluster client SSL requires the trustCertChain to be set explicitly or suffer the wrath of WARN logging. And that got me thinking about the server too. It seems like the only good reason to have the client trust everything by default is simply because the server's most simple ssl default is to create self-signed certs. Since there is no access to these certs, they can not be imported into the client thus the client must trust anything. Well, this is not good security all the way around.
If we take a 'security should be secure be default' posture, then 1) the client would never trust all certs without verification by default. logging messages, at any level, are not sufficient. 2) the server would never create self-signed certs. It's not that hard to create self-signed certs anyway. Instead, the server should require certs to be configured explicitly whether self-signed or commercial. The client should trust packaged ca certs by default. The client can be configured to trust self-signed certs. An additional config option can be used to configure the client to disregard hostname. (This is where the hostname doesn't match the cert. It is sometimes a necessary evil). In order to use self-signed certs, the rather painless process to configure the client and server will have to be followed. This is pretty standard stuff for applications. I've create two tickets to address these issues. TINKERPOP-2022 - https://issues.apache.org/jira/browse/TINKERPOP-2022 TINKERPOP-2023 - https://issues.apache.org/jira/browse/TINKERPOP-2023 If there are no objections in 72 hours then it shall be done starting with tp32. 1. https://groups.google.com/d/msg/gremlin-users/2z7Si4wM0SU/lL3OqR0LCgAJ Robert Dale
