2 ms·

You should be able to do that via DNS SRV entries. _xmpp-client._tcp.domain.tld. TTL IN SRV priority weight port target _xmpps-client._tcp.domain.tld. TTL

You should be able to do that via DNS SRV entries. _xmpp-client._tcp.domain.tld. TTL IN SRV priority weight port target _xmpps-client._tcp.domain.tld. TTL IN SRV priority weight port target example: _xmpp-client._tcp.not-my-domain.com. 3599 IN SRV 5 0 5222 jabber.my-domain.com. You could also build a reverse proxy setup. Then you wouldn't need the keys to the SSL certs. But that is probably overkill to run at your client: https://wiki.xmpp.org/web/Tech_pages/XEP-0368 https://wiki.xmpp.org/web/Tech_pages/XEP-0368 I don't think I have seen a client complain about the cert being for jabber.my-domain.com Which one is giving trouble there? source: https://datatracker.ietf.org/doc/html/rfc6120 https://datatracker.ietf.org/doc/html/rfc6120 https://wiki.xmpp.org/web/SRV_Records https://wiki.xmpp.org/web/SRV_Records

yosamino 8mo ago
> Which one is giving trouble there? Probably all of them. Section 5.4.3.1 > The receiving entity SHOULD choose which certificate to present > based on the domainpart contained in the 'to' attribute of the > initial stream header (in essence, this domainpart is > functionally equivalent to the Server Name Indication defined for > TLS in [TLS-EXT]). and 13.7.2 says > Once the identity of the stream peer has been validated, the > validating entity SHOULD also correlate the validated identity with > the 'from' address (if any) of the stream header it received from the > peer. If the two identities do not match, the validating entity > SHOULD terminate the connection attempt (however, there might be good > reasons why the identities do not match, as described under > Section 4.7.1). You can manually set a server in most clients, and I don't know how that is generally implemented. I guess that should work then. But if you serve a certificate for jabber.example.com for a user trying to connect to an account user@example.com using SRV records then that mismatch will give you at least a certificate warning popup. And for good reason too: How would a user verify that a certificate abcde.1234.jabber.freshhosting.donut is valid for the account joe.doe@example.com ?

yosamino 8mo ago

> Which one is giving trouble there? Probably all of them. Section 5.4.3.1 > The receiving entity SHOULD choose which certificate to present > based on the domainpart contained in the 'to' attribute of the > initial stream header (in essence, this domainpart is > functionally equivalent to the Server Name Indication defined for > TLS in [TLS-EXT]). and 13.7.2 says > Once the identity of the stream peer has been validated, the > validating entity SHOULD also correlate the validated identity with > the 'from' address (if any) of the stream header it received from the > peer. If the two identities do not match, the validating entity > SHOULD terminate the connection attempt (however, there might be good > reasons why the identities do not match, as described under > Section 4.7.1). You can manually set a server in most clients, and I don't know how that is generally implemented. I guess that should work then. But if you serve a certificate for jabber.example.com for a user trying to connect to an account user@example.com using SRV records then that mismatch will give you at least a certificate warning popup. And for good reason too: How would a user verify that a certificate abcde.1234.jabber.freshhosting.donut is valid for the account joe.doe@example.com ?