i have installed openfire 5 in a windows domain. it’s a corporate environment so they have their own CA. they installed a certificate on the machine , i exported it into a file from MMC and imported it into Openfire’s keystore with “keytool”.
then, i went back to the Openfire console and i see the message “there is no suitable certificate for this xmpp domain”.
i thought i covered all possible FQDNs
the xmpp domain, conference, search, pubsub, whiteboard, the server’s own ID, the IP address, just the host name ???
is there a place (it’s not in the log!) where i can see which SAN i have missed?
actually, i installed two servers and clustered them with Hazelcast, would that matter?
The certificate is used for a number of things, based on what services you enable or rename, which makes this a difficult question to answer. It needs to cover the XMPP domain, service addresses on the XMPP domain like conference, search and pubsub and the network names of servers that are part of the cluster.
There is no admin console page that shows you what SANs you need, but you could inspect the self-signed certificate that Openfire generates by default, or the CSR that you can generate from the admin console.
Genetically, this is the easiest setup:
make the hostname of the server that is running Openfire be a ‘subdomain’ of the XMPP domain name. For example, if your XMPP domain is example.org let your servername be server1.example.org. Then, have your CA issue a wildcard certificate, that covers example.org and *.example.org - this will be rather foolproof for 99% of all ways you can expose Openfire, even in a cluster.
i forgot to say that a wildcard is not allowed in this environment.
so, I cannot do *.mydomain.com
i, too, thought i could examine the self-signed certificate installed by default at the time of installation but no luck, it includes the name *.mydomain.com, LOL
it would be very helpful if there was a button in the console that “creates a CSR” which will possibly include all required names
so, if i understand you correctly, I’m out of luck. eventually, someone will try to use a service that will fail and we will know what we missed
Having looked at the code, I found that when you let Openfire configure a self-signed certificate, it will add SANs for all the names it thinks are needed. We should probably make this a bit easier, though.
One thing to note: Openfire will quite verbosely warn about missing names, but there’s a good chance that you do not need some of these names to be in your certificate. Generally, it’s only required to have SANs in your certificate for domain names that entities from remote domains wan to interact with. This is often limited to:
Conference services (conference.<domain>)
The XMPP domain itself (<domain>)
And sometimes, your pubsub domain (pubsub.<domain>)
These are the most likely services to be used.
Make sure to add the hostnames of your servers to this, as that’s used for various web-bindings.
