Subdomains and TLS-certificate fields confusion

Openfire
1

Hello.

Suppose my XMPP Domain Name is example,com and my Server Host Name is xmpp,example,com. I have an A-record on xmpp,example,com pointing to the actual server address and SRV-records on _xmpp(s)-client(server),_tcp,example,com subdomain, as was recommended in Openfire admin console.

What I’m unsure of:

  1. Do service names such as conference,example,com need to be DNS-resolvable?

  2. What should go in TLS-certificate’s CN and subjectAltName fields? Is it xmpp,example,com or example,com or maybe both? If the answer to (1) is yes, than maybe conference,example,com as well? I really want to avoid wildcard certificates here.

2

I had to use commas instead of dots in domain names, because the forum software thinks they were links.

3

Yes indeed. they need to be resolvable.

Also yes, your certificate needs to include multiple names, it depends on which service do you provide.
but i guess it all boils down to: example.com, conference.example.com, httpfileupload.example.com, proxy.example.com, pubsub.example.com, search.example.com.
adjusting with the services you intend to provide of course, these names can also be edited if you are not using the default.

So in the case that you are providing all these services your certificate must include all these names on the same certificate.

That being said, this is the proper way of doing it. But i believe that most people just run with the “example.com” and the rest end up being ignored. as long as the services are working for your clients, and you dont mind the logs complaining, i dont think its a big deal.

4

Thank you.

5

You can surround text with a back-tick character (`) to avoid this: www.example.org

1 Like
6

You can set up the Common Name (CN) of your certificate to the XMPP domain name (example.org) and then add Subject Alternative Names (SAN) for each of the component domains (conference.example.org, pubsub.example.org, etc) and the server’s fully qualified domain name (xmpp.example.org).

For XMPP authentication, it’s important to have the XMPP domain name be ‘covered’ by the certificate.

For any kind of browser-based application (the admin console, several of the web-based client plugins, etc), it’s important to have the server’s hostname in the certificate.

For XMPP server-to-server communication, it is very desirable to have the services in the certificate (most commonly used being the conference service(s) and the pubsub service). If your server does not take part in server-to-server communication, you might not need this one.

Make sure to also add DNS A, AAAA and/or SRV records for all of the domain names. Not only does this help with connectivity, it also makes it easier for a tool like Let’s Encrypt’s cerbot to automatically renew certificates.

1 Like
7

for me, I suggest using a wildcard cert. this avoids so many issue, but some security experts tend to advise against their use. Lets Encrypt support wildcards