Certificate name question

hi, i have a couple of openfire servers. currently they are using a commercially signed wildcard certs. The certs will be expiring soon and we now have an internal CA for company certs. So I generated a cert based on the servers name but when I tried to import it into the identity store, I got this message:

There was an error while trying to import the private key and signed certificate. Internal server error: The supplied certificate chain does not cover the domain of this XMPP service.

So now I am confused as to what to generate the cert for…can anyone enlighten me on what the identity cert should be? I assumed the server name. here is my server info

image

Your certificate should be issued for your XMPP Domain Name. That is ultra-fei.com in your case. Server name is not important for certificate.

hi, thanks for your quick reply. I want to make sure I understand because this seems counter-intuitive. If i want to manage the chat server, I go to https://fei-vic-chat-1.ultra-fei.com:9091 however, the cert you are telling me to install as an identity cert is for ultra-fei.com…that will not cover the server…right? how does https://fei-vic-chat-1.ultra-fei.com:9091 work if the cert is not right, unless you mean a star cert? *.ultra-fei.com?

Ideally you should be going to https://ultra-fei.com:9091 for administration. Same with web clients. They would be going to https://ultra-fei.com:7443/http-bind/ and would be covered by the same cert. Your regular XMPP clients also should be logging in using ultra-fei.com as domain/“server” in their settings. XMPP domain is the main thing in XMPP, not the real name of a server.

I’m not sure what to do best in your case. I guess you can issue cert for ultra-fei.com and when going to https://fei-vic-chat-1.ultra-fei.com:9091/ you can add an exception in your browser to allow anyway no matter the mismatch in names. I wouldn’t make admin console available on the internet, so maybe not a big deal.

hi, I work a lot with certs etc and to be honest, I have never heard or seen an application attempt to take over the top of the domain the way you are suggesting.
There are many problems with this, non the least of which is that in a network with Microsoft active directory…like mine and most, ultra-fei.com is pointing to the domain controllers, i could never point it to the chat server.
I am really confused as to how nobody had complained about this. Also, now that i think of it, I have SRV records in my dns that point to the server name…how could it ever be anything else.
Sorry if I am going on about, I mean no disrespect, but this does not sound right to me.

First of all, i personally don’t have practical experience with using Openfire on internet or on a main local domain. So maybe someone else can comment on that. I know @Guus is planning or is already hosting Openfire, so maybe he had to deal with that. @speedy is our AD\Windows network guru, so maybe he can give advice regarding the local AD network.

In my understanding XMPP was born as a global network to live in internet and compete with AOL/Skype/etc, with federation in mind. So its design is more suitable for such global deployment. Although it can be installed as a local chat, it still has the same requirements and constraints.

As about pointing to the main domain. Same is with email. You can have AD domain abc.com, a website www.abc.com and emails with user@abc.com addresses. Your Exchange server might be mail.abc.com, but email addresses doesn’t have to be user@mail.abc.com. And you can manage this with DNS (SRV, MX) records. Say this site has a website on igniterealtime.org and the chat server on the same name (i put igniterealtime.org in Spark to login). Although i think its server’s FQDN is probably xmpp.igniterealtime.org. It could be that its using the same cert for both website and chat server. But maybe Guus can comment on that.

For client connections you can manage this with SRV records like:
_xmpp-client._tcp.abc.com. 18000 IN SRV 0 5 5222 chat.abc.com.

Not sure what to do about Admin Console though. This is not a part of a global XMPP design/standards. Servers’ developers had to come up with something to administer servers. Openfire uses web console. Some use cmd or config files.

Is your external domain and internal domain the same? Anyway, you’ll want to create a few SRV records, since your xmpp domain the the top level.
I like to use a wild card cert in this case, as its just makes things easy. Id suggest that, but you could also create a cert for whatever your SRV resolves too…I’m guessing its fei–vic-chat-1.ultra-fei.com. basically you’ll do the same thing as if you were getting a cert of a website. create a cert for fei–vic-chat-1.ultra-fei.com, and include the root, ultra-fei.com as a SAN. Most commercial CA will actually include the root domain example.com in the SAN when your get a cert for www.example.com, so your not really doing anything different here!

1 Like

Yeah, i haven’t though about the SAN. This way you can have one cert covering client connections to abc.com and Admin Console say on admin.abc.com.

Guys, thanks for you time on this. I guess I got lucky when I did the initial install, I put a star cert on because I had one.
I think you should make it clearer in the requirements that either a star or SAN cert is required.

thanks again for your time.