Hotdeploy "does not cover the domain"

Openfire Plugins
1

Hello,

I have problems installing certificate for a server, using hotdeploy. The openfire log says:

2021.07.19 19:15:16 INFO  [pool-5-thread-1]: org.jivesoftware.openfire.keystore.IdentityStore - The supplied certificate chain does not cover the domain of this XMPP service ('example.com'). Instead, it covers [autoconfig.example.com, autodiscover.example.com, mail.example.com]

I don’t understand, why the certificate should cover the domain, instead of the server?
The SRV records are pointing to the server, just as is the client configuration:

_xmpp-client._tcp.example.com. IN SRV 0 0 5222 mail.example.com.
_xmpp-server._tcp.example.com. IN SRV 0 5 5269 mail.example.com.

covering mail.example.com should be just enough here.

2

Certificates are used in Openfire to identify the server in several different scenarios.

When the certificates are used to identify the XMPP domain, or any of the sub-services on it (over XMPP), then the XMPP domain name is used. This typically occurs when users try to authenticate over XMPP.

Another way the certificates are used is when the server uses its full address (FQDN), which typically occurs when HTTP is involved (the Admin Panel, BOSH, etc).

This is why both the FQDN as well as the XMPP domain name (plus a few subdomains that match the name of XMPP components) need to be covered by the certificate.

3

I wonder, because in this case, users set up servername into their clients, so clients compare the certificate to the servername, not domain.

Could Certificate Manager/hotdeploy relax (or skip) those checks?
(optionally)

I’d be happy to add the needed hostnames to DNS and certificate, but now I can’t get Let’s Encrypt certificates and I’m stuck with self-signed certificate.

4

users set up servername into their clients, so clients compare the certificate to the servername, not domain.

This is not true for regular TCP clients. XMPP servers are always set up to connect to an XMPP domain name, which is resolved to a (set of) server name(s) using DNS SRV lookups. Many clients allow you to override this lookup, which can be extremely useful - but even then, any TLS will use the XMPP domain name, not the FQDN of the server.

For BOSH clients (that communicate over HTTP) things are different. There, the browser will validate the certificate that’s presented at the BOSH endpoint, which very often is based on the FQDN of the server.

Most deployments of Openfire will need both types of names covered in the certificate, otherwise TLS simply can’t be established in important parts of the system.

A work-around with Let’s Encrypt is to request a certificate that matches various subdomains of a webserver, which will result in a certificate with various Subject Alternative Names. Such a certificate can be used by Openfire.

If all else fails, the Java-provided ‘keytool’ command can be used to manually manage the key stores that hold the certificates. However unless there is a very specific reason to do so, requiring to go down that path typically is a sign that some kind of environment was set up incorrectly.

5

My problem is that I can not get Let’s Encrypt to sign “example.com”. I can use “mail.domain.com” add some subdomains, but if certificate manager or openfire require “example.com”, I’ll have to stay with current self-signed CA.

Can those requirements get relaxed a bit, e.g. only require “servername” so I can have at least something working?

6

You can install any certificate/key combination that you deem appropriate by modifying the various Java keystore files (in <openfirehome>/resources/security) directly. That will bypass any restriction that the admin console adds.

7

yes, but this means external modifying of keystore files and I guess also requires restating openfire.
optional relaxing of restrictions would be nice alternative

8

@fantomas, the following batch file may serve as an example of how to restart the Openfire HTTP server instead of the whole service:

@echo off
setlocal

set naam=admin
set wagwoord=geheim$
set herlaaiblad=http://127.0.0.1:9090/server-restart.jsp
set inlogblad=http://127.0.0.1:9090/login.jsp
set curl=C:\Nutsgids\curl\curl.exe
set koekies=koekies.txt

%curl% %inlogblad% -c %koekies%

for /f "tokens=7" %%i in ('findstr csrf %koekies%') do (
  set csrf=%%i
)

%curl% %inlogblad% -b %koekies% -c %koekies% --data-raw "login=true&csrf=%csrf%&username=%naam%&password=%wagwoord%"
%curl% %herlaaiblad% -b %koekies%

del %koekies%

endlocal

@guus, thanks for all you do to make Openfire such a polished and easy to use platform.