jabber.org recently switched to Let's Encrypt, and now offers not a linear chain, but a tree-like structure in their certificate chain:
Openfire tries to order the chain in org.jivesoftware.openfire.keystore.CertificateUtils#order. This implementation cannot handle the tree-like structure, and fails.
At this time, I've yet to find the best solution for this. Some considerations:
Even if the TLS RFC defines such a chain to be invalid ("This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it."), they obviously occur. Openfire shouldn't choke on them.
According to the same RFC quote above, the chain should already be ordered. I'm not sure why Openfire explicitly tries to order the certificates from the chain.
If ordering is needed, Openfire could perhaps be modified to order the collection of certificates in a tree-like structure, rather than a list.
Environment
None
Activity
Show:
Guus der Kinderen March 25, 2016 at 11:47 AM
Administrators of jabber.org have now modified the certificate chain on their end. It now again is a linear list, which will resolve the issue for Openfire instances that do not have this fix.
Guus der Kinderen March 25, 2016 at 11:25 AM
Openfire will now try to order the certificates from a chain, but no longer treat an ordering failure as a show-stopper. Instead, the first certificate from the chain is then used.
We've rolled this out on igniterealtime.org, which restores jabber.org connectivity.
Guus der Kinderen March 25, 2016 at 10:05 AM
Note that by default, the Lets Encrypt root CA's are not in Openfires truststore, as far as I'm aware.
jabber.org recently switched to Let's Encrypt, and now offers not a linear chain, but a tree-like structure in their certificate chain:
Openfire tries to order the chain in
org.jivesoftware.openfire.keystore.CertificateUtils#order. This implementation cannot handle the tree-like structure, and fails.At this time, I've yet to find the best solution for this. Some considerations:
Even if the TLS RFC defines such a chain to be invalid ("This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it."), they obviously occur. Openfire shouldn't choke on them.
According to the same RFC quote above, the chain should already be ordered. I'm not sure why Openfire explicitly tries to order the certificates from the chain.
If ordering is needed, Openfire could perhaps be modified to order the collection of certificates in a tree-like structure, rather than a list.