We're updating the issue view to help you get more done. 

SSL Certificate import should be more forgiving

Description

My Openfire server (xmpp.domainname=weather.im) (pre 4.0 release) allowed the SSL certificate import of a StartCom signed cert with the following attributes:

Subject: C=US, CN=xmpp.weather.im/emailAddress=hostmaster@weather.im
X509v3 Subject Alternative Name:
DNS:xmpp.weather.im, DNS:weather.im, 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.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
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.

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: https://github.com/igniterealtime/Openfire/pull/249

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

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

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

Assignee

Guus der Kinderen

Reporter

Daryl Herzmann

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Affects versions

Priority

Minor
Configure