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 have branched out this to a new discussion as it looks to be a different issue.
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
My spark.properties file:
#Spark Settings
#Thu Aug 25 23:51:22 CDT 2016
hostAndPort=false
And my error.log file is 0 bytes (empty).
I think it wasnāt that checkbox that worked for Kyle, but using xmpp domain name as a server to login, as ssl certificate has that in it and it should match.
Btw, you might want to replace your real domain in the log.
So, do you put ims.domain.com as your login server in Spark? Is your xmpp.domain system property is ims.domain.com? Do you have dns entry for that name in your AD?
That chexkbox only helps when self-signed certs are in use i think.
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 username@domain.com 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:
*.ims.domain.com (ims.domain.com_dsa)
*.ims.domain.com (ims.domain.com_rsa)
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ā¦
I might have been wrong about this. It might just because be caused by the certificate/hostname verification failure. 
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
restart openfire
sign into openfire and delete the old certificates and generate new ones.
thats pretty much it.
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).
If you were able to login by using āopenfireā and automatic discovery, this means that āopenfireā is actually resolvable in your network. maybe it is also in the DNS as a record.