Unknown host: java.security.cert.CertificateException: No X509TrustManager implementation available


Trying to diagnose an issue when using Lucee to do a test CFHTTP call to a WSDL.
The endpoint is being served also by Lucee on the same server via Apache and Tomcat.

The URL is viewable from a browser, but when trying to invoke as web service with CFINVOKE it fails.
As a test, I have a bit of cfscript;

cfhttp(method="GET", charset="utf-8", url="https://somedomain/wf/webservice/wf_webservice.cfc?wsdl", result="result") { } writeDump(result);

When I try to access it, I’m gettiing
Unknown host: java.security.cert.CertificateException: No X509TrustManager implementation available

Where in the stack is Lucee experiencing this exception? Is it.

  1. In the JAVA/JRE/JVM keystore/truststore?
  2. In Tomcat?
  3. In Lucee?
  4. in the OS?

After asking around in some forums, it’s been suggested that the endpoint is the issue.
How can I eliminate where the problem is?

The URL in question works fine when the same is called from a CF9 tomcat instance on the same server.
Why is it failing in Lucee and how can it be resolved?

As a further test to see if my “endpoint” is the culprit - I tried simple CFHTTP requests from both a CF9 instance and the Lucee instance like so:

   param name="URL.host" default="";

if (URL.host EQ ‘Lucee’){

 writeoutput('Lucee 5 server);
 httpService = new http(method = "GET", charset = "utf-8", url = "https://lucee_server.com/wf/webservice/wf_webservice.cfc?wsdl");
 result = httpService.send().getPrefix();


else {

 writeoutput('CF9 server call);
 httpService = new http(method = "GET", charset = "utf-8", url = "https://CF9_server.com/wf/webservice/wf_webservice.cfc?wsdl");
 result = httpService.send().getPrefix();


Both of these calls work fine from the CF9 box.
Both calls fail from the Lucee box.

If the endpoint was causing the issue, I’d expect it to fail from both the Lucee and CF box.

Both instances of CF9 and Lucee are on the same server, same TLD etc.

Is Lucee not able to make CFHTTP requests over SSL?


which versions of java, tomcat and lucee are you running?


Java 1.8.0_171 64bit
Apache Tomcat/7.0.52


You might have to import a missing certificate into the keystore:
keytool -importcert -file certificate.cer -keystore keystore.jks -alias "Alias"


A few questions:

Is the missing certificate on the server I’m trying to connect to? (even though its the same machine/domain)?

Can I install the certificate using the Lucee server admin, or is that something separate?

Does it matter what the “Alias” value is?

Thank you


I tried that as previously suggested, but it had no effect. To which keystore do I need to be importing to?
I tried the Lucee one located for me at: /WEB-INF/lucee-server/context/security/cacerts

How can I confirm which keystore is Lucee using?


Maybe this will help.

What kind of certificate? Self signed?


I’ve been using that as a reference, but it didn’t seem to fix the problem.
The actual certificate isn’t self signed. Not sure if I have to create a keystore.jks file or just import the certificate using keytool as described.


Lucee would be using the key-store of the associated JRE (Java runtime) that it is hosted on. The information to java path should be in the Lucee admin.

It is the calling lucee instance (the client) that needs to accept the certificate and thus updates to keystore should be there conducted there. (the assumption is that is the issue here).

So the question you will need to answer:
Which certificate are you using to secure the communication?
Who issued it?

Normally you need to accept the public cert of the certificate authority so all certificates from that authority can be accepted.


That is just an example command line.
Yours will look different.

Look up to keystore commands example here:

You will most likely import a .cerfile without modification and not need a jks file. Did not mean to confuse you on this…


Well, technically this is Java and has not much to do with Lucee. Usually you just use the Admin SSL import feature.

Things to check.
Make sure you have the right JRE that Lucee is using. CF9 and Lucee usually have their own jre. Check JRE_HOME from a command line.
Make sure you have certificates for the whole chain. I had a similar problem once with a self-signed and didn’t have the base CA.


Pause here - because this is actually not correct. Adobe CF DOES use the java cacerts - which depending on your distribution may be OS maintained, or java supplied. For instance, on most linux distributions, the java cacerts is actually generated from the same place the browser and openssl trust certs are generated from.

However, if you download lucee and start it, when it’s unpacking itself you’ll see this:
2018-08-08 21:31:28.879 write file:/Users/mrwizard/Downloads/lucee-express-

Lucee includes its own cacerts file, it’s checked into Github with the source. It’s distributed as part of Lucee. It’s done this way largely to allow for adding certs through the administrator. (Which requires a writable cacerts store) I have some reservations about this structure, but that’s how it is. I issued a PR to have the Lucee cacerts updated awhile back but I can’t speak to how up-to-date it is now. (edit: it’s still including the file I updated in Jul 2016 )


I am one to agree that Java’s SSL warnings leave a LOT to be desired when tracking down a problem, but if it were an untrusted certificate, I’d expect to see sun.security.validator.ValidatorException: PKIX path building failed, especially because you’re running the Oracle JDK. The fact that it can’t find ANY X509 Trust manager strikes me as something different. (Actually, worse)

So you asked -

And now I ask you the same thing. Can you do a cfhttp against https://www.google.com or some other SSL Site?

Pretty sure the system has a default X509TrustManager, and it can be overridden with system properties - but in Lucee, that trust manager should live in core (and reference the Lucee cacerts file as indicated above) and load before all the other jars fire up - so it should be accessible from anywhere. I’ve never seen an error where it can’t load a X509TrustManager because the JDK provides one - so the fact it can’t find one at all is puzzling. If you can’t hit google, then it can’t find a trust manager AT ALL, or it has been overridden/set to use the name of another trust manager that doesn’t exist.

Another possibility is your cert is funky - like maybe it’s a DSS cert or a ECDHE cert, or some specific cipher which the normal X509TrustManager can’t handle.

I have a pretty dumb, non-responsive question though - if the WSDL and service is literally on the box you’re on, why are you bothering with SSL? Does a non-SSL URL work? There’s very little chance someone’s going to intercept traffic from localhost, and if they can do that, they can probably read your certificate private key too.

But regardless, if you can’t hit google on SSL - then you’re going to want to solve the actual TrustManager problem.


Seems to indicate you can run into this if the system properties point to a non-JKS keystore, or it’s corrupt. You can download a fresh copy from here:


Or copy the one from your installed JDK over Lucee’s copy. Should be in JDK_HOME/jre/lib/security/


Thanks everyone for providing an explanation of what to try.
I dumped the java system properties and here’s what I’ve got:

(I assume this is where Lucee stores its cert)

java home

( * I think this is java’s keystore location?)

Does Lucee itself have a place where the password is set to access a keystore?

javax.net.ssl.trustStorePassword has a value - that I haven’t configured in Lucee.
Does that happen in Lucee, or do I need to use keytool?


Thanks Joe.
I’m going to try a fresh copy of the JKS and check if I can get to google over https.


Replaced Lucee’s JKS with the

restarted Lucee, and tried to make a CFHTTP call to https://google.com. Same error.

Unknown host: java.security.cert.CertificateException: No X509TrustManager implementation available


Even cfhttp to https://google.com is throwing an error cinfigurafter replacing the Lucee JKS.
Do I need to replace the JAVA JKS as well?

Do I need to use the keytool to configure anything afterwards?


Is this a custom Lucee install? or did you use the installer?
The installer usually puts it’s own jre under /opt/lucee/jdk.
If it is custom, it will use JAVA_HOME.
Since this isn’t self signed, something seems broken with Java. Can you reinstall it?
My tomcat doesn’t have WEB-INF before lucee-server.
You also list java under /opt/java/… but the cacerts under /java/… Typo?

FYI. I hope the Tomcat is patched (many distributions keep the same version and add the latest code security patches). Tomcat 7 is up to 7.0.90 for security updates.


It’s a custom Lucee install with our in house deployment system which is perhaps most if not all of the problem. Running Lucee locally through CommandBox, there is no issue with making test CFHTTPS requests.


I would echo @kabutotx
Since a fresh install of Lucee does not seem to run into this issue,
i.e… it is able to call google.com using cfhttp, there is something different about your setup we cannot surmise.

You seem to have done your share of research. Have you approached a paid support provider such as Rasia or Lucee consulting (https://lucee.org/get-support/consulting.html) to fix it for you?



I had a very similar issue yesterday that caused a cfhttp connect failure due to a sun.security.validator.ValidatorException: PKIX path building failed on a win-box. I had to install all the CAs of the entire SSL certificate chain (java version didn’t have that CA certificates preinstalled. That were 2 CA certificates in the complete SSL-Certificate- Chain (that i both exported to .cer with firefox browser). i had to install it via javas keytool in the lucee-context, but in the jre security cacerts-file as well. That worked for me. I installed into the windows certificate store also, just to have it all in the complete environment.