CFLDAP issue with multiple SSL certificates

Hi @gigemags , I must have missed your post. Could you let us know how you solved the problem?

gigemags, while I've not seen that error before, "SASL bind failed", I can say that in looking into it (not limited to regarding CF), I find that it seems to be rather catch-all, high-level error that occurs when a secure ldap connection cannot be made. As such, I see other folks providing more details, including "root" exception info including such things as "Root exception is javax.net.ssl.SSLHandshakeException" or "PKIX path building failed". Those are classic errors when there's some problem with CF (Java) communicating via TLS/SSL to some server.

So first and foremost, can you look at the exception.log in CF to see if you see more details when this error occurs? And does it container words like those above?

If so, I know you feel the problem started "after we updated one of our SSL certificates in our keystore". But did you also restart  CF to make that take effect? If so, note that the restart of CF could have caused other prior changes to take effect. For example, perhaps someone updated the JVM which CF uses. You mention being on CF11, and depending on what update of that you're running, it supports Java 11 or 8. Can you confirm what JVM CF is using? You can view that in the CF Admin on its "settings summary" page.

I'll add that it could be someone updated it from an older Java version (even perhaps a few to several years old) to a more recent one. I can say that with the JVM updates starting in Apr 2021, Oracle changed the default to no longer allow calling out to servers that didn't support at least TLS 1.2. Note how that has nothing to do with certs. I have a blog post on that here.

On teh other hand, sometimes what happens is that servers you call make changes that REQUIRE that the JVM calling it be updated. I have a blog post on that, here.

Please let us know if any of the above helps, and if not, again please report at least the Jvm version and CF update, both reported on the CF Admin "settings summary" page. (Someone will want to also point out how CF11 came out in 2014 and got its last udpate in 2019. It is indeed potentially a grave security risk to still be running it, or CF2016 or CF2018--both of which got their last updates 5 years after they came out.)

In ColdFusion, when using CFLDAP with SSL certificates, you can specify the certificate alias using the ‘clientcertalias’ attribute. This attribute allows you to specify the alias of the certificate you want to use from the keystore.

Here's an example of how you can modify your code to include the clientcertalias attribute:

<cfldap server="myserver"

         port="1636"

         secure="CFSSL_CLIENT_AUTH"

         clientcert="/my/keystore"

         clientcertpassword="mypassword"

         clientcertalias="your_certificate_alias"

         action="query"

         name="results"

         start="mystart"

         filter="myfilter"

         attributes="myattributes"

         timeout="600000">

Replace "your_certificate_alias" with the actual alias of the certificate you want to use from your keystore.

Regarding how ColdFusion chooses which certificate to use when multiple certificates are present in the keystore, the exact behavior depends on the underlying Java implementation. In most cases, the selection is based on the certificate's alias. However, it's always a good practice to explicitly specify the certificate alias using the clientcertalias attribute to ensure that the correct certificate is used.

If you're uncertain about the current state of your keystore or the certificates it contains, you can use keytool (a Java tool) to list the certificates and their aliases within the keystore. The command to list the certificates is as follows:

keytool -list -keystore /my/keystore

This command will display the certificates and their respective aliases, allowing you to verify the alias of the certificate you want to use.

Remember to restart your ColdFusion server after making any changes to the code or the keystore for the changes to take effect.

If you are still having problems, you can try the following:

1. Make sure that the certificate in the keystore is valid and has not expired.
2. Make sure that the password for the keystore is correct.
3. Check the permissions on the keystore file.
4. Try using a different keystore.
5. Contact your LDAP server administrator for help.