So if you tell spark to connect directly to aaron@chat.exmaple.tld , it works?
Yes, but that seems counter-intuitive. Why should users suddenly have to remember a new thing that looks almost exactly like their e-mail address and Windows login, and wireless authentication usernameâŚexcept it has âchat.â in front of it nowâŚ
Your xmpp domain is chat.example.tld and thatâs why it doesnât work as you are trying to login to exampe.tld when you put just example.tld into Domain field in Spark. The SRV records will only help when your xmpp domain is example.tld and your serverâs FQDN is chat.example.tld. If this is not yet a production server, you can re-run the setup and change the xmpp domain. After rerunning the setup one should also remove old TLS certificates as Openfire will first still provide old ones to the client.
Hey,
Iâd just like to mention the existence of X509v3 Subject Alternative Name extension to the public key infrastructure (details) which I believe addresses exactly this issue, but I may be wrong. I usually put all names that the host may appear under as a subjectAltName on its certificate but havenât tried that with Openfire + Spark setup.
Please comment.