Related discussion in the forum of LetsEncrypt: https://community.letsencrypt.org/t/using-cert-in-openfire-xmpp-server/

Unit test + suggested fix: https://github.com/igniterealtime/Openfire/pull/555

Openfire might have been more forgiving in the past. I think the changes in this PR formalized the identity resolution, but also made it more strict: https://github.com/igniterealtime/Openfire/pull/249

I'm working on some unit tests to verify the behavior.

As I understand it, there are (at least) three ways that a certificate can include an identifier for an XMPP server:

• the Common Name

• a subjectAltName entry of type otherName with an ASN.1 Object Identifier of "id-on-xmppAddr"

• other subjectAltName entries

As I understand the issue, Openfire currently tries to resolve the identities related to a certificate based on entries of the second type "id-on-xmppAddr", and tries to resolve the Common Name only when no "id-on-xmppAddr" entries are defined. What is missing here is evaluation of other subjectAltnames.

From a discussion we had in open_chat with dwd earlier today, I believe that the following is the desired way to identify the list of identities related to a certificate:

1. Obtain all subjectAltName entries (including "id-on-xmppAddr" as well as others).

2. Only when no subjectAltName entries exist, evaluate the Common Name.

When trying to match a particular identity to a certificate entry:

1. Prefer "id-on-xmppAddr" subjectAltName entries

2. fall back to other subjectAltName entries when no "id-on-xmppAddr" entries are available in the certificates, or when "id-on-xmppAddr" entries are available but do not match the desired identity.

3. fall back to Common Name when subjectAltNames entries do not exist. The Common Name fall back should not be used when subjectAltName entries exist (even when those do not match).

Note that falling back to other subjectAltName entries when "id-on-xmppAddr" entries exist but do not match is debatable, but RFC 6125 says never to fall back to CommonName if something better exists.