Ну, я сделал кучу вещей, и теперь это работает, так что это один из тех случаев, когда неизвестно, какой из них это исправить, но для блага других, вот что я сделал:
- Добавить записи 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 Domain Name
: имя домена XMPP и имя 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 ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/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 ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https: //%{HTTP_HOST}%{REQUEST_URI} [R,L]
</VirtualHost>