Nun, ich habe ein paar Dinge getan und jetzt funktioniert es, also ist es einer der Fälle, in denen nicht bekannt ist, von welchen (n) es repariert wurde, aber zum Wohle der anderen habe ich folgendes getan:
- SRV-Einträge zu meinem DNS hinzufügen
In der Admin-Webkonsole von OpenFire habe ich unter Server | keine Warnung bemerkt Server Manager | Serverinformationen: "Es wurden keine DNS-SRV-Einträge für diesen Host gefunden". Darunter waren viele nützliche Informationen über XMPPs Bedarf an SRV-Aufzeichnungen, von denen ich noch nie zuvor gehört hatte. Kurz gesagt, handelt es sich um einen Mechanismus zum Weiterleiten von Verkehr von einer Domäne zu einer anderen, den XMPP manchmal benötigt (wenn der DNS- und der XMPP-Server anscheinend nicht auf demselben Server gehostet werden). Ein paar Dinge zu beachten: Stellen Sie sicher, dass Sie das Format des SRV-Datensatzes korrekt erhalten, da dies nicht offensichtlich ist. Mit Netfirms als Domain- und DNS-Anbieter musste ich den technischen Support für das Hinzufügen der SRV-Einträge anfordern, da es innerhalb von Netfirms keine Möglichkeit gibt, sie zu verwalten.
- Bei allen XMPP-Clients habe ich die Kontoinformationen geändert.
Speziell für die Benutzernamen-Informationen habe ich anstelle von xmpp.mydomain.com mydomain.com verwendet. Zum Beispiel habe ich für einen Benutzernamen von joe.blow joe.blow@mydomain.com anstelle von joe.blow@xmpp.mydomain.com eingegeben. Es war nicht meine Vorliebe, aber ich habe den Verdacht, dass es dazu geführt hat.
Bis zum heutigen Tag bin ich immer noch verwirrt über die ganzen XMPP - Server - Eigenschaften: XMPP Domain Namevs. Server Host Name (FQDN). Warum braucht es beides? Warum kann es nicht einfach den FQDN verwenden?
Ich weiß, es geht nicht um die Frage, aber ...
Noch ein OpenFire-Tipp, nur für den Fall, dass jemand Schwierigkeiten hatte, als hätte ich sicheren Zugriff auf Ihr Admin-Webportal erhalten. Wenn Sie Let's Encrypt für Ihre Zertifikate verwenden und Sie das Glück haben, Apache auf demselben Server auszuführen, versuchen Sie stattdessen, dass Sie versuchen, das Zertifikat xmpp.mydomain.com zu akzeptieren, damit Sie über https auf Ihr Administrationsportal zugreifen können : //xmpp.mydomain.com können Sie Apache stattdessen als Reverse-Proxy verwenden. Es ist viel einfacher, einen Apache-Webserver mit einem Let's Encrypt-Zertifikat aufzustellen und automatisch zu erneuern - zumindest habe ich das gefunden.
Ihre Apache-Conf-Datei könnte folgendermaßen aussehen (einschließlich einer Umleitung für http zu 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>