Ну, я сделал кучу вещей, и теперь это работает, так что это один из тех случаев, когда неизвестно, какой из них это исправить, но для блага других, вот что я сделал:
- Добавить записи SRV в мой DNS
В административной веб-консоли OpenFire я не заметил предупреждения в разделе Сервер | Диспетчер серверов | Информация о сервере: «DNS-записи SRV для этого хоста не найдены». Под этим было много полезной информации о потребности XMPP в записях SRV, о которой я никогда раньше не слышал. В двух словах, это механизм для пересылки трафика из одного домена в другой, который иногда требуется XMPP (когда сервер DNS и XMPP, очевидно, не размещены на одном сервере). Несколько вещей, на которые следует обратить внимание: убедитесь, что вы правильно указали формат записи SRV, потому что он неочевиден; используя Netfirms в качестве моего домена и поставщика DNS, мне пришлось обратиться в их службу технической поддержки для добавления записей SRV, потому что в Netfirms нет способа управлять ими.
- На всех клиентах XMPP я изменил информацию об учетной записи.
В частности, для информации об имени пользователя вместо xmpp.mydomain.com я использовал mydomain.com. Например, для имени пользователя joe.blow я ввел joe.blow@mydomain.com вместо joe.blow@xmpp.mydomain.com. Это не было моим предпочтением, но я подозреваю, что именно это заставило его работать.
До сегодняшнего дня, я до сих пор путают о целых свойствах XMPP сервера: XMPP Domain Nameпротив Server Host Name (FQDN). Зачем это нужно обоим? Почему нельзя просто использовать полное доменное имя?
Я знаю, что это не вопрос, но ...
Еще один совет по OpenFire, на случай, если кто-то изо всех сил попытается получить безопасный доступ к вашему административному веб-порталу. Если вы используете Let's Encrypt для своих сертификатов и вам повезло, что вы также используете Apache на том же сервере, вместо того, чтобы пытаться заставить OF принять сертификат xmpp.mydomain.com, чтобы вы могли получить доступ к порталу администратора через https: //xmpp.mydomain.com, вы можете вместо этого использовать Apache в качестве обратного прокси. Намного проще встать и автоматически продлить веб-сервер Apache с сертификатом Let's Encrypt - по крайней мере, это то, что я нашел.
Ваш файл Apache conf может выглядеть следующим образом (включая перенаправление для http на https):
<IfModule mod_ssl.c> <IfModule mod_proxy.c> <VirtualHost *:443> ServerName xmpp.mydomain.com ServerAdmin webmaster@localhost DocumentRoot /var/www/xmpp ErrorLog $/error.log CustomLog $/access.log combined SSLEngine On SSLCertificateFile /etc/letsencrypt/live/xmpp.mydomain.com/cert.pem SSLCertificateKeyFile /etc/letsencrypt/live/xmpp.mydomain.com/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateChainFile /etc/letsencrypt/live/xmpp.mydomain.com/chain.pem ProxyPreserveHost On ProxyPass / http://127.0.0.1:9090/ ProxyPassReverse / http://127.0.0.1:9090/ </VirtualHost> </IfModule> </IfModule> <VirtualHost *:80> ServerName xmpp.mydomain.com ServerAdmin webmaster@localhost DocumentRoot /var/www/xmpp ErrorLog $/error.log CustomLog $/access.log combined RewriteEngine On RewriteCond % off RewriteRule (.*) https: //%% [R,L] </VirtualHost>