> Это странно, что он должен себя анонсировать в рамках запуска TLS именно
> как domain.tld. Твоё мнение я понял, но не понял, почему это обязательно
> для фазы запуска TLS ? Мне не очень нравится ситуация, когда машина с
В данном случае (xmpp) "нет времени объяснять". Суй огурцы, как говорится.
> другим доменом (xmpp.domain.tld) получит также сертификат на другой, по
> сути, домен (domain.tld). Как хак - сертификат с SAN - я догадываюсь,
Почему другой? Ты ведь в SRV _xmpp-client для домена domain.tld явно
указал хост xmpp.domain.tld? Своими собственными ручками?
> что можно сделать, но сама концепция мне кажется сомнительной.
> Например: твой почтовый сервер в подобной ситуации бы мог обойтись
> сертификатом без SAN. Потому, что TLS заводится отдельно от протокола
> внутри него.
> Ну или, если есть какие-нибудь пруфы - покажи, плз, хочу разобраться.
Проверь практикой.
>> SASL к TLS в общем-то отношения не имеет. Скорее всего SASL не находит
>> подходящий бэкенд для указанного тобой fqdn. Т.е. не "tls не
>> заводится", а аутентификация.
> Тоже непонятно, какой такой бэкенд ? Читаю доку на gsasl, но пока не
> дошёл до понимания принципов работы. Вроде бы всё для работы находится
> внутри приложения, все бэкенды в нём. Ну или я тут тоже не понял.
"Бэкенд" в данном случае - это база или место хранения
аутентификационной информации для твоего домена. Который к xmpp не имеет
никакого отношения, как я полагаю. SASL в данном случае палка с двумя
концами. На одном механизмы для аутентификации а на втором - место, где
лежит инфа о пользовательских credentials.
