_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-0368I don't think I have seen a client complain about the cert being for jabber.my-domain.com 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 ?