Now that Lucee 6 is no longer using it’s own cacerts file by default, it’s time to think of a better, and more resilient way to handle certificates. To me, it would seem that the either/or approach doesn’t work very well. If you use the JVM’s cacerts file, you can only update it via keytool or other third party tools, which may or may not be easy to do in some hosting environments. If you use Lucee’s cacerts file, it becomes harder to update the file when Lucee is updated.

My suggestion is this: Luceee should get rid of it’s cacerts file altogether and start fresh with a luceecerts file, that would be empty, or contain only a dummy certificate when created. When upgraded, Lucee would not touch this file at all, only upgrading the JVM’s cacerts file if required. This would eliminate the need to make a choice between files and make it much simpler to manage from the admin, as it would be clear, that any changes in the admin were being made to the luceecerts file.

In order for this to work, Lucee would need to implement some custom TrustManagerFactory and SSLContext code to enable it to use both files. I’d love to help with this, but I don’t know a lick of Java, but I do know how to Google. I came across a could of ways to accomplish this, but the best to explain it was written by and can be found here:

The section starting at “5. Programmatically Consider Both TrustStores” is relevant to my proposal here and explains how to write the revised functions necessary to accomplish what I have described. There are other, similar ways to do the same thing, but in going through the source for Lucee and the source examples in his article, I saw many similarities which made me think it would be the most straightforward to implement. I think this is a fairly elegant solution which accomplishes many things.

1. Ends the need for Lucee to maintain or update cacerts, other than the one included with the JVM.

2. End the need for users to choose between Lucee’s and the JVM’s truststores.

3. Would allow for code to be added to the admin to update the JVM’s cacerts file automatically or manually in the event that is needed without disturbing any user-imported certificates. This could be done even without upgrading the JVM.

4. Would allow for the easy transfer of user imported certificates when moving to new hardware.

5. Would allow for the SSL Certificates page in the admin to display the currently imported certificates, without the clutter of the root certs (although they could be displayed as an option).

6. Would allow for the removal of certificates from the luceecerts file without disturbing the JVM’s cacerts file.

Other enhancements suggested:

1. In the short term, add to the docs of SSLCertificateInstall and SSLCertificateList that if they are using the JVM’s cacerts file, these functions will have no effect. The admin mentions this, but not the docs for those functions, so users may think they do not work, although this problem goes away if the above solution is implemented.

2. Add info to the Overview page showing which cacerts file is currently being used and it’s location. This should also be added to the server scope. I think it only shows up in the server properties if it has been switched to Lucee’s truststore.

Would love to see the basic functionality of this included in Lucee 6.2, with maybe the expanded Admin utilities included in Lucee 7.