@girish in my provisional implementation I am using the key from httpPort for a predictable certificate/key locations.

given:

"httpPorts": {
    "CONFERENCE_DOMAIN": {
      "title": "Conference Service Domain",
      "description": "XEP-0045 domain",
      "containerPort": 5280,
      "defaultValue": "conference.chat"
    }
  },

the expected paths by convention are:

ssl = {
        certificate = "/etc/certs/secondary/CONFERENCE_DOMAIN.cert";
        key = "/etc/certs/secondary/CONFERENCE_DOMAIN.key";
    }

but I do not insist on this method. I would be perfectly fine with listing that directory to find out which domains exist, as well as environment variable based paths per a predictable httpPorts key.

So each feature is in it's own subdomain, is it?

not necessarily. E.g file uploads and proxy65 turned out to not need their own TLS certificates.

However, XMPP components that participate in federation MUST authenticate themselves for server-to-server communication via TLS. In my current configuration there is a Multi-User chat component that acts as it's own entity under "conference.chat.example.com" and must present a CA-trusted TLS certificate for that domain. Same goes for pubsub service.

This is necessary because other XMPP servers will expect to talk to "conference.chat.example.com" on port 5269 or 5222 with STARTTLS.

I do not expect many more components to be there. In total under 5 in the scope of this app. There may be a different XMPP Transports app that will have it's own configuration, but right now I'm focused on getting the core functionality.

As to why Jitsi is working ... I would need to check that code, but perhaps they do not do server-to-server xmpp ? Everything would happily work within the boundaries of the single prosody server, but outside world XMPP federation wouldn't work.

Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.

Cloudron Forum

syn