3 ms·

You need a certificate for the domain you are going to serve of course. You can get one with ACME DNS challenges pretty easily (I have my clients set up a CNAME

You need a certificate for the domain you are going to serve of course. You can get one with ACME DNS challenges pretty easily (I have my clients set up a CNAME for the _acme-challenge subdomain of their domain).

yosamino 8mo ago
I worded that poorly. Yes, that is of course correct. But that means that your clients have to trust you without technical safeguards, that you will not use this to get for certificates for purposes other than XMPP. Which, in my mind, is a problem if the domain is not used just for XMPP, but lets say for a website as well.
- Joe_Cool 8mo ago
  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 ?
- singpolyma3 8mo ago
  Yes there is a new DNS challenge coming which will make this even easier.

yosamino 8mo ago

I worded that poorly. Yes, that is of course correct. But that means that your clients have to trust you without technical safeguards, that you will not use this to get for certificates for purposes other than XMPP. Which, in my mind, is a problem if the domain is not used just for XMPP, but lets say for a website as well.

Joe_Cool 8mo ago
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 ?
singpolyma3 8mo ago
Yes there is a new DNS challenge coming which will make this even easier.