Hi, I played a bit with the SSL Client Authentication which is supported in the last versions of the Java Broker. It seems to work fine, but there are some differences compared to the implementation in the C++ broker.
The C++ broker implementation is based on the NSS library from Mozilla. The user creates an certificate database and configures the broker to load the database at start-up The NSS certificate database can store the private keys used by the broker as well as the public keys related to the connecting clients. The public keys can be divided into several groups - the keys of trusted CAs and the keys of trusted peers. The difference between the trusted CA and trusted peer is that the trusted CA allows to log in even to clients who have a certificate signed by the CA, while the peers allow to log in only to clients who have the certificate exactly matching the certificate loaded in the certificate database. When the client is logged in, the CN from the certificate is used as the authenticated username. That makes the trusted peers very important, because if you want to use self signed certificates, you need to be able to distinguish between the client connecting with the exact certificate or a client connecting with a certificate which was signed by the original certificate and has possibly a different CN. The SSL Client Authentication in the Java broker is based on the Java JSSE implementation. The certificates are stored in the JKS format. The JKS format doesn't distinguish between trusted peers and trusted CA. Therefore all public keys behave as trusted CAs. As a result, the current implementation cannot be used together with self signed certificates. Additionally another minor difference is in the way the username is constructed - the Java broker doesn't use only the CN as the authenticated username, but it uses a complete distinguished name. But that isn't such a big deal. Together with my colleague we tried to solve the problem with the trusted peer. As far as we found out, there seems to be no support for the trusted peers in the JKS truststores. First we investigated the possibility to replace the JKS / JSSE implementation used in the Java broker with the NSS library (its Java implementation called JSS). Unfortunately, the JSS doesn't implement the Java APIs currently used in the broker - therefore using JSS would require more significant changes (e.g. use the JSS SSLSocket etc.). As a second approach we tried to implement our own TrustManager, which would use the JKS truststore but handle all the certificates inside as trusted peers. That seems to be a easier and more feasible approach. As a result of our investigation, we would like to suggest following enhancement: - The current configuration for the SSL Client Authentication supports only one truststore - We can add a second configuration entry which would allow to specify "peerstore" - When creating the SSL context, the existing truststore would be handled as it is handled today - If the "peerstore" is specified, the new TrustManager will be added to the SSL context - The custom TrustManager will use the peerstore to verify the peers only as a peers - The client will pass the authentication if it is authenticated either with the original Trustmanager against the keystore or by the custom trust manager against the peer store such solution would allow - the change to be backwards compatible ...anyone using it will not see any change - provide support for signed and self-signed certificates at the same time - it will be based on the standard Java APIs wherever possible Please let me know whether you think this makes sense and if yes, we can open a JIRA for it and prepare a patch. The second problem - using CN as a username versus using complete DN as username - cannot be so easily solved in a backward compatible way. The SSL related classes can be changed to use only CN as username, but that would be change for everyone already using it. Another option would be to add some mapping table between distinguished names and username which can be optionally used. Thanks & Regards Jakub
