Thanks. I finally got it work by taking your advice changing the FQDN to be the same as XMPP domain name so the tls certificate error disappears.
Just one little thing: it seems that, if i use server-props.jsp to change ip to domain name, it doesn’t work. I had to directly edit openfire.xml. (if i do the reverse, from domain name to ip, server-props.jsp works). Don’t know why. Maybe you find it interesting to look into.
Thank you so much for your time and help!
On a deeper thought, may I suggest that in future versions of openfire, better function for the FQDN to be IP address can be considered? The reason is as following:
For users like myself, who runs their openfire on VPN, usually do not bother having a “proper” DNS network name and CA approved certificate. If FQDN and XMPP domain name are set to the same other than IP, client side needs to solve the name (in my case, “raspberrypi”) with hosts file or other method, for httpupload to work.
However, for mobile client such as Conversations App, there is very hardly any such solution unless the phone is rooted. I tried to set both XMPP domain name and FQDN to “raspberrypi” while add it to my hosts file, PC based clients work perfectly while mobile App cannot use httpfileupload anymore (Text message still works). Though they offer advanced login method which allows you to give IP separately, apparently httpfileupload function built in the App still use https://fqdn/… format.
I wonder if the thinking makes any sense. Thank you for your time.
Openfire is by definition a networking-oriented application. The requirement of having a “properly set up” network isn’t to far-fetched from that perspective.
As for TLS certificates: when you choose to run with the self-generated one, you’re already making large concessions that largely defeat the purpose of using certificates in the first place (security). With the recent uptake in clients being more strict in requiring TLS certificates, this adds some additional burden on the administrator of things.
There are both “the cost of doing business” I suppose: if you want a properly functional server-sided application, you’ll need to invest a bit in making sure that the network that it is running on is configured.
One thing that we could investigate is to have the FQDN of the server being added as a SAN to the self-signed certificate, which could help a bit - but even that will likely not cover most commonly used networking setups - it’s just to diverse a range of possibilities. I’m also wondering if client connections will accept self-signed certificates that cover more than just their issuer’s subject.
Totally agree with the SAN idea. This is indeed the challenge of a server like openfire and clients deveoloped by other parites. XMPP protocal does not cover so many features. Different people may have qutie different needs.