Spark 2.8 failed to login

Not sure if this aligns with the announcement post but it seems like maybe 2.8 should be fixed given all the issues its caused…

Spark 2.7.1 is my version of choice now

2.8.0 fails to connect with any known user / password combo to a dns name [chat.domain.com].

server is Openfire, Version: 3.10.3

The thing is that 2.8 IS fixed as 2.7 version didn’t behaved correctly. And most probably 2.7 version will stop working starting with Openfire 4.1 for the same reason. 2.8.1 most probably will have an option to ignore hostname mismatch between domain and certificates (not secure, but a workaround).

From talking to wroot and speedy, it appears that you now have to put the exact server name in the Server field in the Spark login, and probably have to go into Advanced and manually set the Server name/IP address and port. This finally worked for me, because when I installed our server at work, I called it “openfire” and that’s exactly what I have to put in the Server field (don’t think it’s case sensitive, but haven’t tried that yet) because it auto-generated security certificates with exactly that name that I entered for “domain” during setup (initially Openfire 4.0.1 I think for our current server but now 4.0.3). I didn’t get involved with our Spark until recently, so I have no idea really how 3.x works. And the guy who started us off on Openfire no longer works here.

I don’t remember now, but maybe automatic generation of certificates was introduced in 4.0. You had to go and manually generate them and enable SSL\TLS manually before.

You can try the testing build of 2.8.0 which have an option (in the Advanced menu on the Login screen) to Disable certificate hostname verification: http://download.igniterealtime.org/spark/dailybuilds/spark_2_8_0_886.exe

Keep in mind, that this will make your client vulnerable to certificate spoofing attack. But you might not care about it in a closed safe environment.

1 Like

Then i just wont update Openfire - until this problem is resolved. This is a big problem that cant just be worked around.

That sucks pretty badly if thats the case - i really dont want to have to put in D7-Openfire01 into my clients and its especially awkward if i have to help them set that up over the phone instead of just telling them “chat.domain.com

Ill give that a try now - thanks.

EDIT: Confirmed that works - must be the same issue as the announcement then but it even matters if youre using a DNS name.