CFLDAP Error: One or more of the required attributes may be missing or incorrect or you do not ...

[tevansresdat]

One of the Coldfusion applications I manage is currently making simple LDAP Binds to a Domain Controller over port 389. This is bad as it is sending credentials in cleartext, so I am trying to update the cfldap tag to make a secure connection over port 636. This currently looks something like the following:

<cfldap
  action="QUERY"
  name="ldap_query"
  attributes="#variables.attributes#"
  start="#variables.start#"
  scope="SUBTREE"
  maxrows="20"
  filter="(sAMAccountName=#arguments.theUsername#)"
  server="#variables.ldapServer#"
  port="636"
  username="#arguments.theUsername#"
  password="#arguments.thePassword#"
  secure="CFSSL_BASIC">

I'm getting the following error:

Detail: 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.
Message: An error has occurred while trying to execute query :<servername>:636.

I found the following within the cfldap docs:

If you use the security="CFSSL_BASIC" option, ColdFusion determines whether to trust the server by comparing the server's certificate with the information in the jre/lib/security/cacerts keystore of the JRE used by ColdFusion. The ColdFusion default cacerts file contains information about many certificate granting authorities. If you must update the file with additional information, you can use the keytool utility in the ColdFusion jre/bin directory to import certificates that are in X.509 format.

Thinking this might be the issue, I imported the certificate into the cacerts keystore as suggested above and restrarted Coldfusion, but I am still getting the same error.

Just FYI, I do not have any control over the DC, however my client does and I am currently working with them to resolve this, but they don't have any CF experience -- they have the LDAP experience that I lack. I believe this issue is likely on the CF side of things since I get the same error when I try to connect to a different DC (that uses the same cert).

[Charlie Arehart]

Either of 4 questions may get us to your answer:

1. What is the Java home value on the cf admin jvm page?
2. Did you import into  THAT folder's lib/security/cacerts? If  not, that's why it may not have worked for you. 
3. Before you try that, you may not NEED to do the keytool import. What is the Java version of the jvm that cf is using? That can be viewed on the cf admin settings summary page.
4. Related to that, what version of cf is this, and what update, also reported on that page?

You may just need to update the jvm, whose version you can go to depends on your cf version. For more, see my post :

https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/

[tevansresdat]

Thanks for the feedback. It is running Java 11.0.5 and I've confirmed that I updated the keystore for the correct JVM specified in cf admin. This is for CF 2016 update 14.

[tevansresdat]

I was back to working on this again today. Surprisingly, I am seeing the same error from your post in the exception log, even though the JVM is relatively up to date (updated to 11.0.6 since last week).

[Root exception is javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]

Might it be worth trying Java 12, since it is supported with CF2016u14 (according to your post from last year)? What aboout 13 or 14? Are they supported yet?

[Charlie Arehart]

You could try Java 12, yes (supported for CF2016 after its update 12), though note that Oracle no longer supports it. Sadly, no, Adobe has not yet come out with support for Java 13 or 14. Those releases are moving fast, and Adobe just isn't keeping up. (For more on this, for those interested, see my post from Oct, https://coldfusion.adobe.com/2019/10/coldfusion-now-supports-java-12-already-eol-use-java-13-11/.)

That said, you could certainly "try" any of them, just to see if they fix things. If they do not, then it doesn't matter if CF doesn't "support" them. If they DO work, that's when you will have to consider the risks of using 13 or 14 before Adobe does support them (13 is already also EOL).

But assuming it does NOT help, consider again what Dave W shared below. You did not reply to him after saying you'd check, on Apr 3. Any news there?

Finally, if that's not it, as for your saying that your CF is using Java 11 currently, can you tell us how you confirmed that? I proposed you look at the CF Admin "settings summary" and its reporting of the jvm version. Let's make sure you haven't made a mistake and it's still using an older jvm. 🙂

[tevansresdat]

Regarding the certificate chain, I just followed up with Dave below. Still no luck with that so far, but could be I'm not importing things properly.

Regarding the Java version, here is a screenshot from the system information screen of the CF admin:

I'll likely give some of the other Java versions a try in the coming days. Juggling lots of projects currently. Thanks again for all the advice.

[Dave Watts]

Certificates are a pain in the ass. That said, you might take a look at all the resources out there about dealing with certificates for HTTPS. Those will generally apply for any other TLS transactions.

First, your version of Java simply may be too old for talking to newer TLS servers. I see Charlie mentioned that so I won't continue down that track. Second, you may need to import a certificate chain, not just the individual certificate. TLS relies on a "web of trust" where you have root, intermediate and server certificates (and may even have multiple intermediate certificates). You need to import all of them - in the correct order. Third, you need to make sure the certificate is actually in X.509 format. Different certificate export tools might give you different formats, especially if you're exporting from something other than a web server. You can of course use openssl to get certificates from anything:

https://stackoverflow.com/questions/7084482/how-to-save-the-ldap-ssl-certificate-from-openssl

Again, there are lots of details out there on all this stuff, but they're mostly focused on web servers. They'll still apply to your situation here, though.

Dave Watts, Eidolon LLC

[tevansresdat]

Thanks for the feedback. Java is pretty well up to date (see my reply to Charlie). I'll check with my counterpart regarding the certificate chain.  I exported the certificate on the machine using the Windows certificate export tool and chose base-64 encoded X.509 format, then imported the certificate to the keystore using portecle, following the instructions from this SO answer: https://stackoverflow.com/questions/11617210/how-to-properly-import-a-selfsigned-certificate-into-ja...

[Dave Watts]

Yeah, my bet is the certificate chain. You should be able to see all of the certificates with openssl or the Windows certificate export tool.

Dave Watts, Eidolon LLC

[tevansresdat]

Unfortunately, even after importing the certificate chain in what appears to be the correct order, I'm still running into the same error. I was provided the certificate chain in a .p7b file, which I was not able to import directly as both the Java keytool and Portecle complained about it not being a X.509 certificate. So I exported each of the certficates in X.509 format and imported them individually. Maybe that is not the right process?

[Dave Watts · Accepted solution]

You should be able to fetch the certificate chain yourself, directly, using openssl. I always forget which order the certificates within the chain should be: either root to lowest intermediate, or vice-versa. So when I look online, I'm told it's from lowest intermediate to root.

Once you've done that, you might be able to test this more effectively using a different Java LDAP client, and having said client use the same JVM. The Java LDAP client I've used (not for this, but for other things) is called JXplorer, and it seems to still be around. It's free.

http://jxplorer.org/

Dave Watts, Eidolon LLC

[tevansresdat]

Getting the certificate for the LDAP server directly using openssl and importing it did the trick. Thanks for the assistance!

[Dave Watts]

You're welcome! I'm glad that worked out.

Dave Watts, Eidolon LLC