After upgrade from 3.9.3 to 3.10.2 AD users can’t login with Spark 2.7.1 build 686, Spark says “Invalid username or password”.
At the same time admin console login is successful.
In debug log and error log nothing is present about spark error message.
Server side Centos 6.6 x86, client side Windows 7 x64 without SSO.
Openfire 3.9.3 works with some noncritical issues.
what version of java are you using on the client and server?
Definately something wierd going on here, started getting PKI path validation errors on the LDAPS connections to my (samba) AD authentication server. I shoved my ca, and even host cert in both truststore and keystore in /etc/openfire/security and also the ca-certificates.pem file in there in appropriate format.
I thought for a while I’d nailed it to me calling the server “localhost” and thus violating the CN on the certificate, but even with me fixing this via database editing it just doesn’t seem to validate…
And the error is fairly explicit, its not a timezone or CN mismatch but the path failing to validate…
I can, however, connect just fine to said LDAPS server with validation from the CLI
/etc/openfire/security# openssl s_client -connect (fullhostname):636 -CAfile ./ca-certificates.crt
(snip)
SSL handshake has read 4487 bytes and written 501 bytes
(snip)
Verify return code: 0 (ok)
But openfire logs are spammed with
==> openfire/error.log <==
2015.06.26 17:39:19 org.jivesoftware.openfire.ldap.LdapAuthProvider - Error connecting to LDAP server
javax.naming.CommunicationException: simple bind failed: (fullhostname):636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
Downgrading to 3.10.1 immediately solves the problem.
I can confirm the same issue with a similar setup on 3.10.2. Problem does not exist in 3.10.1.
2015.06.26 09:35:05 org.jivesoftware.openfire.ldap.LdapAuthProvider - Error connecting to LDAP server
4465 javax.naming.CommunicationException: simple bind failed: hostname.domain.com:636 [Root exception is javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
Importing the self-signed certificate from the Windows DC into /opt/openfire/jre/lib/security/cacerts resolves the issue.
please see this…near the end it talks about what changed in 3.10.2 and ldaps. basically, you need to import your root ca into the jre being used. The ssl behavior changed a bit in order to quickly get connection pooling with ssl working
OpenFire 3.10.1 Upgrade Breaks Authentication
I did accidentally originally reply to that thread before replying to this one (that threads supposed to be about 3.10.1?), I’m not really seeing the relevance though, I know to restart the jvm after tinkering with the keystores, and did so (also openfire seems to cache the SSL failure state, it doesn’t spam the error for every authentication attempt it seems, so restarting is also necessary to generate new errors i think).
I dont understand “custom socket” etc, I’ve done nothing like that, this is a fresh install of openfire from about 3-4 weeks ago, out of the box. I did once upon a time enable clustering but it didn’t work very well for the config i needed so turned it back off. The LDAPS setup is the “out of the box” authentication mechanism supplied with the box. I figure turning off the change in 10.3.2 about “pooled connections” might fix it but at that point I decided I didn’t want to dev test changes i’d eventually forget to back out and just rolled back fine.
I’m not sure what the recommendation is from this other thread. Custom sockets doesn’t mean much to me and i’ve bounced the thing endlessly. Even now I can “dpkg -i” between the two versions at whim, which also restarts the process, and it will switch from working, to not working, with each switch to 3.10.1 and 3.10.2 respectively.
Any specific part of the thread you were referring to?
Oh, right, never mind, my bad. Doesn’t help the CA store is called ‘cacerts’ not keystore etc when searching filesystems.
I found the presence of /etc/openfire/security/* to be a significant red herring then.
Can confirm when imported into the native JRE store it resolves the problem.
This part
Check to see if you have a root certificate from you CA in your java store. Thats likely the issue, and you’ll need to import your root CA into the JRE that Openfire is using. Here is an example of the command
“C:\Program Files (x86)\Java\jre1.8.0_45\bin\keytool” -importcert -keystore “C:\Program Files (x86)\Java\jre1.8.0_45\lib\security\cacerts” -storepass changeit -file ROOTCA.cer -noprompt
and
… but 3.10.2 requires the chain to be added… does that make sense?
I tried doing what you said and initially it failed. I later realized that OpenFire has to be bounced in order to pick up the change, as it appears that the JVM is somehow caching the contents of the store and doesn’t pick up changes made after it was started.
Here’s what did work:
[blentz@muxrhim01 ~]$ sudo service openfire stop
Shutting down openfire: [ OK ]
[blentz@muxrhim01 ~]$ sudo cp /usr/java/default/lib/security/cacerts /usr/java/default/lib/security/cacerts.orig
[blentz@muxrhim01 ~]$ sudo /usr/java/default/bin/keytool -keystore /usr/java/default/lib/security/cacerts -importcert -file ldap.muxier.com.cachain.crt -storepass changeit -noprompt -alias ldap.muxier.com.cachain.crt
Certificate was added to keystore
[blentz@muxrhim01 ~]$ sudo service openfire start
Starting openfire:
[blentz@muxrhim01 ~]$
The custom ssl socket factory is reference to some code that is used within openfire when using ssl. The original socket would accept accept any type of ssl cert, (which imho isn’t the best at security practices, although it makes things really convenient). Because the orginal code used a custom ssl socket factory, the pooling of connections to ldap didn’t work…which resulted in poor ldap performance. The quick way to resolve this was to revert to the default ssl socket factory. I hope that makes things a little more clear.
speedy, is it LDAP related only? I suppose Spark 2.6.3 would still have problems with login in this case, not just 2.7.x versions. Maybe it is worth putting an announcement about this and including it in the documentation?
wroot, yes…but only ldapS only, not standard ldap. I guess I under estimated the how many people this would affect!
Do you think the previous behavior should be restored? I read there is a way to have both the custom ssl socket factory, and have ssl connection pooling enabled, but since I’m just learning I wasn’t ready to take that on.
Regardless, I think an announcement would probably be a good idea.
Apologies if this is already a well known fact. AD by default requires SSL on all credential-transfering operations, such as binding, changing password etc. Some of these can be relaxed I think but probably wont be. As AD is likely one of the more represented LDAP implementations I would expect to see SSL enabled configurations at least as frequently, and overall more SSL representation inside LDAP than other protocols.
I think a tick box in the auth page as to wether to validate SSL or not would be ideal, upgrades could default it to off and future installs to on (best practise), though its probably a bit late to be considering “smooth backward compatible release”. I dont really know anything about your socket or pooling but you can replace the default Java trust validator (which is emiting those ‘standard java PKI errors’) in such a way that it wont check CA chains for example.
As it affects auth, it breaks ldaps based accounts entirely, regardless of client, yet alone version.
I have branched out this issue into a separate thread. Will post an announcement pointing to this thread.
Have filed [OF-926] Clients can’t authenticate using LDAP SSL - Jive Software Open Source to track this.
speedy, if it improves the security and performance, i think we should find a way to keep it. But if it creates too much troubles now, maybe we can revert this change until the better way to handle this is implemented.
ok, I’m testing this now, but I believe I’ve restored the ability to accept unsigned/invalid ssl, while still being able to have connection pooling with ssl.
I was unable to get Comparator to work withe the custom socket factory. Prob more from my lack of knowledge than anything else. I used XTrustProvider (code provided by f5 SSL Trust Provider for Java )
I’ve also added an openfire property call ldap.disableSslValidation. The default value is currently set to true. When set to false, the server will verify the certificate with JRE.
Openfire 3.9.3 Admin Console
Environment
Java Version:
1.7.0_55 Oracle Corporation – Java HotSpot™ Server VM
Client PowerShell console
PS C:\Windows\system32> java -version
java version “1.8.0_45”
Java™ SE Runtime Environment (build 1.8.0_45-b15)
Java HotSpot™ Client VM (build 25.45-b02, mixed mode)
I can’t understand why this issue is related to ldaps.
There is my configuration:
ldap.host
ldap.port 389
ldap.sslEnabled false
This is means that Openfire connects to AD without ssl, isn’t it?
Step,
I think there was a little confusion on your issue vs the others. Since you are not using ldaps and since you are able to authenticate against ldap from the administration page, ldap is working correctly. It sounds like your issue may be something else. I’m hoping to fire up a Linux install today to see if I can reproduce the issue.
Step,
I just tested with a fresh install of centos 7 and a clean install of 3.10.2. I was able to connected to AD/LDAP without any problems. However, I when I tried to connected with spark I received “Invalid username or password”. I was able to resolve this quickly by checking if port 5222 was open on linux. It was not. Once I disabled the firewall, I was able to connect with spark and sign in using ldap for authentication. Please verify your firewall settings and confirm that the required ports are open.
Good find
And even if iptables is not installed, there is also such a thing as SELinux, which is also worth a try disabling.
Selinux and iptables are disabled on Centos where openfire is installed.
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
iptables: Firewall is not running.
SELINUX=disabled
SELINUXTYPE=targeted
Step and speedy, we need to compare as closely as possible.
Server OS:
Step - CentOS 6.6
speedy - CentOS 7
Openfire version:
both 3.10.2
AD/LDAP login with no SSO, no LDAPS:
both
AD OS:
Step - ?
speedy - ?
Spark version:
both 2.7.1
Java used by Openfire (shown in admin console):
Step - ?
speedy - ?
Java used by Spark (shown in Help > About window):
Step - ?
speedy -?