SSL Certificate import should be more forgiving


My Openfire server ( (pre 4.0 release) allowed the SSL certificate import of a StartCom signed cert with the following attributes:

Subject: C=US,
X509v3 Subject Alternative Name:,, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>, othername:<unsupported>

This certificate is no longer imported with Openfire 4.0 as the admin console complains that the cert's Common Name does not match my xmpp.domainname.

Openfire should be more forgiving and allow for certs to be imported that have a matching SAN to the xmpp.domainname as well.




Guus der Kinderen
March 4, 2016, 9:46 AM

Related discussion in the forum of LetsEncrypt:

Guus der Kinderen
March 4, 2016, 9:35 AM
Guus der Kinderen
March 3, 2016, 7:42 PM

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:

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

Guus der Kinderen
March 3, 2016, 7:33 PM

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.

Your pinned fields
Click on the next to a field label to start pinning.


Guus der Kinderen


Daryl Herzmann