tested this theory against a clean install of OF 4.0.3. in its default configuration, sasl.mechs is not set to the database, however it appears to offer PLAIN and ANONYMOUS. Spark 2.8.0 is answering and authenticating using SASL PLAIN, as expected.
Curt, it looks like your issue may be caused by something else.
Thank you. I really think this is going to be something on the 2.8.0 client end. But I don’t know that, but because it gave me the invalid username/password error on a nonexistent server even when I purposefully gave it a bad server address and port in Advanced. Maybe that error isn’t related to this one, though. But since I can log into the Admin console and also the 2.7.7 client works fine, maybe it’s something to do with Smack et al?
OK the Server properties has “sasl.mechs” set to “PLAIN” but rebooting our Openfire server did not fix it. If it helps any, I went to the Accounts tab and tried to connect to the server using IP address expecting to get a permissions error because we are using AD but instead got a message that it could not reach the server. Telnetting to port 5222 on the server works, and last time I tried the 2.7.7 client, it worked fine.
When 2.7.6 was released, some people had trouble logging in. It was some Java issue. They were able to login by replacing Spark’s internal jre folder with the one from the older version. You can try this (copy jre folder from 2.7.7 to 2.8.0). Though it sounds unlikely. Btw, are you using the full installer? Maybe you are using online one with some older version of Java on the system?
Java used by Spark is shown on its Help > About page.
It would be good if you post that error you found in warn.log, Curt.
OK I had 32-bit Java 8u102 installed anyway. In fact, I renamed the jre folder in the 2.7.7 program folder to force it to use the 8u102 system Java (though I could have just copied its jre folder contents to the jre folder under Spark) and verified it using Help: About. Anyways, so I tried copying the 2.7.7’s jre folder somewhere else, uninstalling 2.7.7 completely and making sure the Spark folder under Program Files (x86) was gone after, and also deleted the AppData\Roaming\Spark folder so I could start fresh. Then I installed 2.8.0, moved its jre folder somewhere else, and put in the 8u92 jre from 2.7.7 instead. Then I started Spark and tried to login again and got the invalid username/password error. Also in the AppData\Roaming\Spark\logs\warn.log file there is the following error which looks like what some other user had, but the solution for them did not fix me (I have accept all certificates checked in Advanced):
Aug 25, 2016 11:39:37 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.SmackException: java.security.cert.CertificateException: Hostname verification of certificate failed. Certificate does not authenticate ims.domain.com
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1029)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPCon nection.java:956)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:971)
at java.lang.Thread.run(Unknown Source)
Caused by: java.security.cert.CertificateException: Hostname verification of certificate failed. Certificate does not authenticate (removed)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.proceedTLSReceived(XMPPTCPConnecti on.java:775)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.access$1000(XMPPTCPConnection.java :140)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1022)
… 3 more
Oh! I missed it or I would have removed it when I pasted it in. Thanks.
It may have something to do with the way I set up the server originally. My xmpp.domain is “openfire” so my actual ID is like username@openfire instead of firstname.lastname@example.org like it should be. What I removed from the log above and what we typically use is what I call a DNS alias (I don’t know what the actual term for it is), which is a name used both externally for offsite users and internally and resolves to a different IP address on either side of our firewall, I think is how it was explained to me. At any rate, I have tried the DNS alias, the actual FQDN, and our internal IP address (since I am testing this on my work machine on our internal network). I haven’t tried the external IP address but I don’t think it would work anyway. All I know for sure at this point is that 2.7.7 works with both 8u92 and 8u102, and 2.8.0 does not work, either with 8u92 or 8u102. I don’t know if it is even connecting to the server. Like I said somewhere else, I can telnet to port 5222 on the server and successfully connect to it, but cannot get 2.8.0 to give me any other error than invalid username/password (except when out of curiosity I tried to add an Account knowing that it shouldn’t work anyway, and it told me it could not reach the server).
So, the problem is that your certificate is issued for ims.domain.com probably, but you are trying to login to ‘openfire’ server. Domains do not match. Smack 3 would allow that, which wasn’t very secure. Smack 4 is more strict about that. You can try putting ims.domain.com in the server field and in the Advanced menu uncheck Automatically discover host and port and put openfire or server’s IP address there.
Already tried that. Even with the actual FQDN and IP address. I am not sure if we have a certificate. I don’t think so. Because other than being handed a Windows Server VM on which I installed Openfire 4.0.2 at the time (now upgraded to 4.0.3), I didn’t do anything but the normal install with LDAP. Except somewhere I forgot or missed the domain name field for the xmpp.domain property or whatever it is.
Go to Openfire’s Admin Console > TLS/SSL Certificates > press the first link “Manage Store Contents”. Does it shows two certificates like:
You may try to recreate them. Though i think in such cases, when xmpp domain has been manually changed after the server’s setup it might not work. I’m afraid the only option in such case is to rerun the setup (it won’t delete the database). And then input the correct domain during the setup. Of course, no guarantees it will work. Make backups before.
In spark, the server name field is also used to construct part of the jid(username). So this has to match what your xmpp domain is. So if your openfire server name or xmpp domain is @openfire than you have to use that. Since that doesn’t resolve , then you have to take the additional step by adding your DNS resolveable name to the connection field in advanced property. Both fields are needed.
Yeah, i kind of suggested a vice versa procedure, because i suspect his certificates were generated for ims.domain.com (because Openfire generates them during setup now). So even if he changes server to openfire and puts IP in the Advanced settings, Smack might still refuse it because of cert and domain mismatch. Unless he will be able to regenerate those certs maybe…
At one point I even tried to login as username@openfire and the server IP address and port in Advanced and was a “no go”. I’m thinking about reinstalling Openfire. But I will try wroot’s directions first.
There is no need to do a fresh install. Its easy enough to reconfigure a server. There are few “gotcha” to watch out for when changing the xmpp domain. Regardless, I’ve submitted a patch to allow a user to override the hostname verification.
However, it would be best to update your server configuration.
change the system property xmpp.domain . If you don’t want to use SRV records, than you’ll need to make it a fqdn, like im.domain.local
if you’re using LDAP/AD, update the system property “admin.authorizedJIDs”. change @something to match your xmpp.domain
sign into openfire and delete the old certificates and generate new ones.
Well, I feel kind of silly now. I finally tried the simplest possible scenario which I just now thought of and it worked. Because our server is named “openfire” I just put that in the server field in Spark, left the automatically discover server and port option checked, and the only other thing I did was turn compression on (I almost always do), and turn on use Spark version as resource so I can see it when I look at the list of users on the server. And it worked!
However, I just now changed it in Spark to where I manually specify our server FQDN and port in Advanced and that works fine. I will have to wait until I get home from work, but I will try it from an external connection and see if that same scenario works. I think the key is probably in specifying the “openfire” server name since that is what I input during setup and it generated certificates against exactly what I input. So far I have not had to make any changes to the server and I would prefer that, but that also means having to change our client setup in the future from 2.8.0 onwards. Smack (I am supposing that is the culprit) has become very strict with the new version (a good thing for security, I am sure).