Where does Lucee get its default cacerts from?

Having issues accessing a site over cfhttp that uses a geotrust root cert:

Common name: RapidSSL SHA256 CA - G4
Organization: GeoTrust Inc.
Location: US
Valid from June 29, 2015 to June 29, 2025
Serial Number: 281c8929661443804263553a3240aeb3
Signature Algorithm: sha256WithRSAEncryption
Issuer: GeoTrust Primary Certification Authority - G3

I can install it manually, but I figure Lucee’s cacerts should be updated
to include this. But what is the upstream Lucee uses for this and how
often is it updated?



Hmm … so when the server context is created for the first time, it is
copied from the java installation?

But then it would get very stale over time… which is exactly what
happened here.


Hi Phil,

No, I don’t believe it is copied, it literally uses whatever the JVM has.
Did you install it using the installer? If so it uses it’s own copy of the
JVM instead of the JVM you might already have installed on the system, so
it is more likely your JVM is out of date. Check in the server admin
homepage to see what version of the JVM Lucee is running on. Also if you
upgraded from Railo to Lucee using the JAR replacement method then the JVM
is likely to be pretty old.

Kind regards,

about.me http://about.me/andrew_dixon - mso http://www.mso.net - Lucee
Association Member http://lucee.org


Have you tried using the SSL Certificates interface in the Lucee admin
panel? All you may need to do is enter the site’s url and Lucee will
install the needed certs down the whole chain, if I’m not mistaken.

If it works, it’s a heck of a lot easier than installing them via the
command line, and if indeed Lucee uses certs from the path you indicated
and the above process installs them there, then that might imply that every
time you apply a Java update, you won’t have to reinstall your certs.


The only time I’ve needed to install certs on a server is when using a web
service. I don’t have a lot of experience here, but I’ve always needed to
install the primary certificate plus the rest of the chain to get them to
work over https. And if the primary cert expires, I’ve needed to reinstall
it, and again, I always install the whole chain while I’m there for good
measure. Just having the root and intermediate certs updated in the JVM
keystore doesn’t help.

Even if in some cases it does help, I’d argue that the pain of installing
certs via the command line interface every time the JVM is updated and/or
every time a cert expires completely overshadows it. It’s so much easier
to use the admin panel.

That said, it may be that the Lucee architecture makes use of both its own
keystore and the JVM keystore. The way to test this might be to set up an
http call that will fail because the certs aren’t installed, install them
using the keytool into the JVM keystore, and see if it works.

Ok, so I’ve tried installing a few certs using the SSL Certificates panel
in the Lucee admin on my local dev instance as an experiment. What I see is
that the timestamp on cacerts file in the path indicated above in Phil’s
post is updated to the datetime I clicked the Install button on the panel,
and using Java’s keytool in the command line, I see that the number of
entries in that keystore increased by the number of certificates installed,
including the intermediate and root certs. So it seems pretty clear that
the admin interface installs certs to that location.

I needed to leave off the https:// part of the domain to get it to work. So
use, for example, subdomain.highrisehq.com and not

I’ve said this before, but a big thank you to the Lucee team for
implementing this! Now that I see it installs certs to its own keystore
rather than Java’s, it’s even more impressive to me, because it seems
apparent that certs will persists across Java updates.

Aria Media Sagl

I’ve said this before, but a big thank you to the Lucee team for implementing this! Now that I see it installs certs to its own keystore rather than Java’s, it’s even more impressive to me, because it seems apparent that certs will persists across Java updates.

The downside of it though is that you don’t get any updates to the JVM certs automatically, right?

Is this behaviour/design documented somewhere?


Nando, I can confirm it does not use the JVM truststore, because I solved
my problem by symlinking the Lucee cacerts file to the JVM one.

My problem is that I’m not accessing web services - I’m accessing normal
public https websites with root certs from major vendors. If my
application requires the ability to connect to random https websites (just
like a web browser), then manually adding certificates via the Lucee admin
page is not practical.


I think the idea solution here (and I think we’d need @isapir or @micstriit to chime in here) would be something along the lines of:

  1. Lucee manages its own keystore for certs added through the admin
  2. For anything else, Lucee falls back to using the JVM default keystore

Unfortunately you can’t have multiple keystores at the same time without jumping though some hoops, but this guy has some good suggestions:


This solution worked for me. I did not know Lucee had a SSL Certificate installation tool. In my case I am setting up Authorize.net. This year they moved to Cloudfront and had a 5 step rollout. Things went well until step 4b. We had to install new SSL certificates for Authorize.net. The documentation was terrible and did not work. Calling Authorize.net I spoke with two people who could not help me and suggested I go to the community forum where others had the same issue.
To resolve the issue I used this suggestion.
I just had to enter entrust.net in the Service -> SSL Certificates under the Lucee Admin Server Admin. I entered entrust.net and clicked install. Everything suddenly started working.
Verbose response in hopes search engines will pick up on this and help others.

FYI the cacerts was updated recently for and in last November for

1 Like