Появилась у меня как-то необходимость поднять XMPP сервер для корпоративных нужд. Рассмотрел я несколько вариантов от коммерческих до бесплатных. Kerio Connect (совмещен с почтой), ejabberd, Prosody IM и OpenFire. Все их описывать я не буду. У каждого есть свои плюсы и минусы. Каждый сам для себя решит что использовать. Мой выбор остановился на OpenFire от Ignite Realtime. О нем и пойдет речь дальше.

Основан OpenFire на Java и реализован под множество OS (Linux / macOS / Solaris / Windows). Изначально была задача заживить его на Windows, но обкатав его, я решил уйти на Linux (Ubuntu Server). И там и там он настраивается без особых проблем и сложностей.

Сложность первая: SSL Certificate.
Если вы обратили внимание, то стартует OpenFire с самописными сертификатами и любой клиент при подключении вам об этом говорит. Что сертификат не имеет доверия. Не можем его проверить. По аналогичной схеме выстраивается и S2S общение с вашим сервером. Без SSL, т.к. нет доверия к вашему самодельному сертификату. Казалось бы, пустяк, сейчас я получу сертификаты (благо есть бесплатный ресурс) и пропишу их в OpenFire. Но.. в действительности, задача оказалась нетривиальная на, казалось бы, всю её простоту. И тут я решил поделиться своим опытом, чтоб как можно меньше народу возилось в этой части OpenFire.
Рассмотрю всё на актуальной на сегодняшней день версии OpenFire 4.2.2 и бесплатных сертификатах от Let's Encrypt, который можно получить тут: https://www.sslforfree.com
Сам процесс получения сертификатов не буду расписывать. Если вы взялись за настройку OpenFire и знаете что такое SSL, вопросов у вас не возникнет там. Сайт простейший.
Итак. Есть у нас в наличии 3 файла от Let's Encrypt. Это: private.key, certificate.crt и ca_bundle.crt. Ваш приватный ключ, сам сертификат и корневой сертификат подписчика.
Идём в настройки OpenFire в Server в  TLS/SSL Certificates и видим следующее:

Здесь, как гласит логика и 99.9% мануалов по инету, нужно было бы положить private.key+certificate.crt в Identity store, а недостающие корни в Trust store, что я и многие другие и сделали. При этом, получили успешно работающий SSL на панели управления (вэбморда) и HTTPS Binding (для HttpUpload). А клиенты (кроме Conversations) при подключении продолжают орать, что сертификат не имеет доверия. Казалось бы - что не так? В чем проблема? И вот суть, из-за которой я всё это затеял: В этом разделе Identity store относится к работе OpenFire с клиентами, а Trust store для работы OpenFire между серверами. В этом и есть вся суть. Стало немного понятнее, но... как же все эти наши три файла скормить в Identity store? Ведь поля там два и каждое подписано: Pass Phrase used for creating Private Key, Content of Private Key file и Content of Certificate file.

Давай те разберемся, ведь Pass Phrase used for creating Private Key - это пароль, которым мы шифровали ключ. У нас его нет. Мы его не паролили.
Content of Private Key file - логично, это содержимое файла private.key
Content of Certificate file - вроде тоже логично, что это содержимое файла certificate.crt
Как же быть? Куда пристроить наш ca_bundle.crt?
И тут, после длительного общения в общей комнате OpenFire и поискам по инету, была найдена интересная инструкция: https://www.digicert.com/ssl-support/pem-ssl-creation.htm
Которая гласит нам, что ваш сертификат должен состоять из самого сертификата certificate.crt и корней ca_bundle.crt вместе!
Таким образом, нам нужно указать в поле Content of Certificate file не только содержимое файла certificate.crt, но и содержимое файла ca_bundle.crt, но как гласит мануал, именно в такой последовательности. Сначала блок вашего сертификата, и потом корни.
Делаем так, как сказано, рестартим OpenFire и всё у нас становится с клиентами хорошо.
Но.. не забываем про S2S общение в OpenFire. Как выяснилось, "из коробки", у OpenFire нет корней, чтоб доверять Let's Encrypt и поэтому S2S общение не переходит на SSL. Для этого нам нужно импортировать наш ca_bundle.crt в Trust store и перезапустить OpenFire. После чего вы увидите в разделе Server Session, который находится в Session, что рядом с серверами ваших друзей (на которых используются Let's Encrypt) появился замочек, что говорит нам об SSL.
На этом наши (ваши) мучения с SSL закончены.

Сложность вторая: Не хватает Java Memory на Windows.
Распространенная сложность. В интернете есть решения, но я тоже решил отметить это у себя в блоге. Дело в том, что если вы используете OpenFire в Windows и при настройках указали EmbeddedDB, то всё происходящее в жизни OpenFire (и особенно история переписки) складывается в один текстовй файл \OpenFire\embedded-db\openfire.script и при каждом рестарте/старте содержимое этого файла читается в память. Плюсы и минусы такой базы я расписывать не буду. Они очевидны. И один из минусов - жор памяти. Но в OpenFire нет настроек памяти. Они удел Java.
И вот, чтоб увеличить объёмы памяти для работы OpenFire вам надо создать файл \OpenFire\bin\openfire-service.vmoptions в котором нужно указать объёмы памяти для работы OpenFire.
Например:
-Xms512m
-Xmx1024m
После чего следует перезапустить службу OpenFire, чтоб он применил новый файл параметров при старте.
Чтоб вам было понятно что это:
Xms - это минимальный объем выделяемой памяти (кучи – heap)
Xmx - это максимальный объем выделяемой памяти (кучи – heap)

После рестарта OpenFire видим, что с Java Memory на главной странице всё в порядке.

Однако, напомню, что чем больше истории переписки будет в такой базе - тем больший объём памяти ей будет нужен и тем дольше OpenFire будет стартовать и в целом "ворочиться". Т.е. это как снежный ком. Рекомендую посмотреть в сторону MySQL.

Сложность третья: OMEMO для пользователей из групп.
Все дело в том, что когда вы организовываете сервер для корпоративных нужд, вы создаете и общую группу со всеми сотрудниками организации. Так сказать "преднастройки", чтоб сотрудникам осталось ввести логин и пароль и поиметь полный список сотрудников в ростере, за исключением себя любимого. Так вот, при такой "подготовке" вы "подписываете" юзеров друг на друга без их согласия. Т.е. они само собой разумеются для каждого. Авторизованы. И нюанс в том, что все эти юзера не имеют ключей (записей) в PubSub о них. И да, вы правильно поняли, что чтоб работала шифровка OMEMO, нужно включить PubSub в настройках OpenFire.
Теперь. Что же делать в таком случае, ведь все клиенты не могут понять как так, юзер авторизован, а ключей OMEMO на сервере нет. Придется немного поплясать с бубном тем, кому это действительно нужно. Но сразу нужно учесть, что в историю на сервере шифрованные сообщения не складываются. Можете забыть о синхронизации переписки между девайсами.
Итак, нужно сделать следующее тем, кому это надо:

1. Отписываемся на нервом устройстве от получения статуса второго устройства.
2. Отписываемся на втором устройстве от получения статуса первого устройства.
3. На первом устройстве запрашиваем подписку на получение статуса второго устройства.
4. Подтверждаем на втором устройстве. Важно: без подтверждения подписка кривая!
5. На втором устройстве запрашиваем подписку на получение статуса первого устройства.
6. Подтверждаем на первом устройстве. Важно: без подтверждения подписка кривая!
7. Переподключаем оба устройства к серверу.
8. В диалоге выбираем OMEMO шифровку и происходит автообмен ключами с сервером.
9. Все работает. Если не работает, то перед переподключением устройств удалите уже существующие OMEMO ключи своего устройства.