New CF2023 Install on Linux Can't get CFLDAP to Work

Question

I have a newly setup REHL 9.3-0.5.el9.x86_64 server. I have Apache 2.5.47 running on it. I installed CF2023 using the GUI installer and set it up with the Production Profile. I upgraded to Update 7 and then upgraded the Java to 17.0.11 and in the CF Admin I can see that it is running Tomcat version 9.0.85.0. In Apache I setup two virtual hosts and on my windows machine I edited my hosts file so that I can access both of those sites through a web browser on my local computer.

I can access the CFAdmin just fine and .cfm test pages work fine. I am having problems getting the cfldap tag to work. I have setup many CF servers over the years from CF2008 until the current version and to get LDAP to work all I ever had to do was install some LDAP security certs into my java key store, restart CF, and then it would work. I have done that for my new server as well but I get an error on my test page “One or more of the required attributes may be missing or incorrect or you do not have permissions to execute this operation on the server.” I have worked with the LDAP team and the Unix team and we can verify that LDAP call work using the command ldapsearch in the bash shell but we have tried deleting and reimporting the certs and trying different java installs with the certs imported. Everything we have tried so far we get the same error. The exact same ldap test page I am using on the new server works fine on my other servers so I know the code is correct.

I can’t find anything helpful in the log files. It is basically the same error message:

I have installed the certs into the correct java that CF is using.

Does Java have log files that might give better debug info? Or does anyone have a suggestion?

flyingmonkey1 · Accepted Answer

I did a clean import of the the certs. I didn't copy any cacerts files from a different computer. I used this process to import the certs:

1. I copied the certs to the security folder at (/java_for_cf/jdk-17.0.11/lib/security)

2. Then I went to the folder where the keytool is at (/java_for_cf/jdk-17.0.11/bin)

3. And then I ran a command like the one below for all 4 certs I had.

sudo ./keytool -importcert -file /java_for_cf/jdk-17.0.11/lib/security/us-ldap-ha-renew-2024.crt -keystore cacerts -alias "US-LDAP" -v -trustcacerts

The only non-standard JVM arg I have is the one you gave me to log the SSL handshake: -Djavax.net.debug=ssl -Djavax.net.debug=ssl,handshake,verbose

I'm reading the Stack Overflow you sent me do other google searches. I'll try to keep track of everything I do so if I find a fix I can document it.

I finally got the cfldap to work. I followed some of the suggestions about making sure the keystore type and the truststore type matched. They did and they were both type PKCS12.

Next someone suggested that you could define the path to your keystore so I did that by adding this to the JVM Args:

-Djavax.net.ssl.trustStore=/java_for_cf/jdk-17.0.11/lib/security/cacerts

That did not fix the problem.

Next I added this line to the java args.

-Djavax.net.ssl.trustStorePassword=changeit

And that is when it started to work.

I next removed the jvm arg about the path to the cacerts file since if I ever update java in the future I would have to update that line as well so that makes it one less thing to remember when I update java in the future. After the CF restart it still worked which is good.

So in the end all I had to do is tell java the password for the truststore. I'm not sure why I never had to do that before on linux or windows but maybe the newer version of java, or CF, or RHEL that I'm using requires it. Anyway, I hope this post helps someone in the future solve this problem.

Thanks again Charlie for pointing me in the right direction.

Charlie Arehart · Answer

I have a few thoughts for you, and perhaps an unexpected solution.

1) First, Java has no built-in logs to help you, no. There's something you could enable, if this turns out to still be about the tls communication/certs--but I realize you think you're all set there (imported cert, updated jvm).

2) Before digging further, are you saying any of this was WORKING for this cf2023 instance, before you did any of that? Or did you do all that and THEN test things? If it was working BEFORE but then stopped--and that's what prompted the updates--do you know of anything that changed regarding the ldap server you're calling? I realize it may be out of your hands/you have no idea.

3) Next, before enabling any "java logs", you've said you couldn't find anything helpful in the CF logs, but can you please look more closely at the exception.log, and specifically when this error occurs? Once you find the same error (above), look DOWN that log for the nested errors that will apear BELOW it .

You may well find that this IS a problem about TLS and/or the cert, after all. Let us know if you find a more specific error (even if you end up solving this), so that future readers finding this could know what more specific error to look for in THEIR exception log.

4) As for why I think it will be a cert problem, it's that someone raised this issue (same error) in another forum thread in the past, and Dave Watts helped them determine that it WAS a problem with how (in their case) they'd experted the cert that they then imported. See that discussion starting at this comment.

5) Finally, if somehow that's not the solution for you, as for enabling other java logging, note that there is TLS handhsake logging you can enable (via jvm args, at CF's startup), and those would be written to CF's coldfusion-out.log file. One form of the JVM arg to add is:

-Djavax.net.debug=ssl,handshake,verbose

For more on using this with CF, see posts such as this one.

But I hope the simpler solutions above may help. Digging through those tls handshake logs can be painf ul.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded