LDAP SSL issues in Openfire 3.10.2

speedy · July 1, 2015, 12:09pm

centos7

OF-3.10.2

Java-1.7.0_76 Oracle Corporation

AD-2012r2

Spark 2.71

Windows 8.1

java 1.8.45

Step,

From your workstation, can you telnet to your openfire server over port 5222?

c:\telnet 5222

Are you able to connect,or do you get a connection time out? Have you double checked DNS? Please check to make sure nothing else is running on Centos that could be used port 5222? Is windows firewall blocking spark?

Its also possible that your update to 3.10.2 didn’t go as planned. Have you tried removing completely, and reinstalling?

Step1 · July 4, 2015, 8:02am

AD OS ADAM instance Windows 2003 sp1 (not Windows 2003 R2)

Java used by Openfire Java Version: 1.7.0_76 Oracle Corporation

Java used by Spark - JRE Version: 1.7.0_80

Step1 · July 4, 2015, 8:12am

Telnet connection is established.

My issue does not depend on Openfire DNS name because Spark does not connect to Openfire both DNS name and IP address.

Netstat on Centos shows that port 5552 used by Openfire.

Windows firewall is disabled.

And I agree, it is possible that update did not go as planned.

I deleted all plugins in Admin Console and now Spark can connect correctly.

Thanks for advices.

wroot · July 4, 2015, 8:54am

Maybe you had the Asterisk-IM plugin installed? It was causing login problems for clients since the 3.10.0 upgrade.

Step1 · July 4, 2015, 10:16am

Yes, one of plugins was Asterisk-IM.

wroot · July 4, 2015, 10:36am

I think you can install back all the plugins except Asterisk-IM. Then you can try to use Asterisk-Im modified by speedy from here Help save the Asterisk-IM plugin

Greg_Moeller · November 10, 2015, 7:59pm

I’m upgrading a very old version of open fire (3.6) to current and I’ve been bit by the ldap bug.

I did manage to get the root cert from the AD admin and it got me a bit further but then got stuck at:

[Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: timestamp check failed]

Which seems to imply our cert has expired.

I don’t think I can prod our AD admin to run around fixing AD servers all over but I noticed a fix for the problem has been submitted.

submitted pr #364 to replace pr #244 for review.

pr #364 returns the previous behavior and use of the custom socket factory, while still being able to enable to use connection pooling with ssl

Is this available somewhere? I tried a nightly build and I’m getting the same behaviour.

Thanks

wroot · November 10, 2015, 8:07pm

This PR hasn’t been applied yet. You can see its state is Open https://github.com/igniterealtime/Openfire/pull/364

It should say Merged. Then you will have a way to test it with a nightly build.

Update: it has been merged recently. So this change most probably will be in 2015-11-11 nightly build.

speedy · November 10, 2015, 10:03pm

looking forward to hearing about this one!

Greg_Moeller · November 12, 2015, 2:22pm

Grabbed the nightly and…

Success! It logged into the LDAP (AD) server just fine.

Thanks for the update!

olo · November 16, 2015, 1:53pm

Hi.

I’m having issues with configuring LDAPS despite the latest nightly build installed (CentOS 7).

How can I troubleshoot LDAPS connectivity/trust issues?

The domain controller returns error Source: Schannel, EventID: 36887, Message: The following fatal alert was received: 46.

speedy · November 16, 2015, 5:05pm

I have yet to see any of that my domain controllers. what have you tried up to the point of trying the nightly build? I feel like there may be something else going on outside of openfire. are you using the included jre or a system wide jre?

olo · November 17, 2015, 7:28am

# /opt/openfire/jre/bin/java -version

java version “1.7.0_76”

Java™ SE Runtime Environment (build 1.7.0_76-b13)

Java HotSpot™ Server VM (build 24.76-b04, mixed mode)

I’m using SSL for authentication to Admin Console (our domain certificate is trusted, so should the openfire’s certificate be trusted to the domain controller)

My goal is to switch from working LDAP connection (port 389) to one using SSL (port 636 - btw. I’m able to use LDAPS to this DC from different CentOS server). I tried to change settings on Profile Settings - Directory Server, Step 1 of 3: Connection Settings. The error occurs after pushing “Test Settings” button.

speedy · November 17, 2015, 3:42pm

I’m not sure that your running the latest nightly build…but 3.10.3 should be released any day now which will address this. You might want to try reinstalling the nightly build or you can import your root certificate used by your domain controller/AD into the java trust store

3.10.2 with LDAPS (LDAP over SSL)

olo · November 20, 2015, 7:55am

After installing 3.10.3 LDAPS works. Thank you