Hostname configuration, existing cert and AWS

Hi,
what would be the correct configuration for the following setup:

I have a domain name: mydomain[.]com (with an existing website and a valid signed certificate)
I setup an openfire server (from bitnami on AWS) with xmpp domain: mydomain[.]com
I added an SRV record to my DNS _xmpp-client._tcp.mydomain[.]com pointing to the aws name ec2-…aws[.]com

clients can now find my openfire instance, all is well!
but they complain about the self-signed certificate - so i’ve been trying to add a certificate to openfire.

i’ve tried:
importing my existing cert into the keystore
set server hostname to ec2…aws[.]com in the admin console.
i can’t get this to work ( nor can i change the hostname anymore, admin console reports success but old value is maintained.)

What is the correct hostname ec2…aws[.]com or mydomain[.]com?
how do i change it (via the cli preferably)

thanks!
(sorry I had to mangle the domains, forum won’t let me post otherwise)

There are two different values of interest:

  • the XMPP domain name - this is used to identify your server (and the entities it defines, like user accounts) over XMPP
  • the server host name (FQDN) - this is mainly for networking purposes. It’s also over this name that HTTP Bind / BOSH endpoints and the Admin Console are exposed

From what I understand, the values for your setup aught to be:

  • XMPP domain name: mydomain[.]com
  • server host name (FQDN): ec2…aws[.]com

You can see what values are currently in use by logging in to the admin console, and looking at the first page. I’ll share a screenshot of what this looks like on our server.

As you can see, our XMPP domain name is igniterealtime.org and our server host name (FQDN) is xmpp.igniterealtime.org.

Note that it’s not required that the server host name (FQDN) and XMPP domain name share a domain part. It is, however, convenient for TLS (more on that later).

You provide both values when you initially set up Openfire.

The server host name (FQDN) can be changed by editing the configuration file in <OPENFIRE_HOME>/conf/openfire.xml. That file has an XML based structure. You’ll find an element named fqdn in the first level under the jive element. You’ll have to restart Openfire for changes to be applied.

Changing the XMPP domain name is recommended against. After setup, that value will have been used in various places (eg: as part of the identifiers for your users - their JIDs). If the XMPP domain name needs to change, I recommend simply reinstalling Openfire.

Openfire has a handy page that will show you what DNS SRV records it detected for your server. That page also lists which records you’d best add. Again, a screenshot for our server, which shows how our igniterealtime.org XMPP domain name will, through DNS SRV, resolve to xmpp.igniterealtime.org, the server host name (FQDN).

Openfire will, during setup, generate a self-signed certificate. To manage the certificates that are used by Openfire, navigate to the Server > TLS/SSL Certificates > Certificate Store admin page, and open “Manage Store Contents” of the Identity Store.

If you install your own certificate, make sure to explicitly delete the self-signed certificate that was generated by Openfire! A known issue is that some versions of Java will only use one of the installed certificates, even if there’s a more suitable one available.

A certificate that you install should, at the very least, cover the XMPP domain name (in your example: mydomain[.]com) This value is used by XMPP clients that connect over TCP (port 5222 / 5223), as well as by other XMPP servers when they establish server-to-server connections. However, you’d probably also want the certificate to cover any MUC conference service names (default: conference.<XMPP_DOMAIN>) which will help establish group chat over federation. Other XMPP services might also be good to have (although I’ve rarely seen a real-world issue with them not being covered by the certificate).

The above will take care of the XMPP-side of things, but sadly, there’s more: your server will expose various endpoints on the server host name (FQDN). The most obvious one is the admin console. Another important one is the HTTP-based endpoint used by most webbased clients (that use BOSH / HTTP-Binding). That address is based on your server host name, and not your XMPP domain name. Other endpoints that are exposed like that are services for HTTP File Upload (for file sharing) and various REST APIs that you might use.

As you can see, there’s a good deal of names to be covered by the certificate that you use. By far the easiest setup is one where you make your hostname be an address that is covered by the XMPP domain name value, and have a certificate that covers your XMPP domain name and all of its subdomains via a wildcard.

I hope this helps!

1 Like

wow Guus, thanks for the helpful (and lengthy) reply - your sundays are amazing :wink:

anyway, it looks like I got myself into a complicated situation here…
(i’m using let’s encrypt as CA)

i have two options it seems:

  • setting hostname to ec2…aws[.]com but violates the policies of letsencrypt
  • setting hostname to mydomain[.]com but fails as mydomain[.]com is hosted on another server

I think my best option is to move the openfire server to a subdomain and update the DNS.
(that or moving the cert from mydomain[.]com … 5pm … still time for some experiments)

thanks again

If you can create DNS records, then you can probably create A records for subdomains of mydomain[.]com too. I think that it is easiest to create an A record for the IP address of your host as a subdomain of mydomain[.]com (for example xmpp.mydomain[.]com) and use that instead of ec2…aws[.]com.

This way, all of your domain names (both XMPP as well as network) all are covered by mydomain[.]com or subdomains thereof. You can then create a LetsEncrypt certificate that covers mydomain[.]com as well as xmpp.mydomain[.]com (or whatever subdomain that you choose).

For bonus points: You could even create dummy DNS records for XMPP components (like conference.mydomain[.]com). XMPP won’t use those DNS records at all, but they allow you to have the relevant SANs be added to the certificate by LetsEncrypt, so that those names are covered when resolved through XMPP.

Is there a menu to get to that dns-check.jsp? Or is it only available if you have an issue and a warning message is shown?

There’s no menu item. If Openfire detects that it would benefit from DNS entries that are currently missing, a warning is shown on the dashboard, with a link to that page.