A few facts to start with:
- The root CA is in the system-wide truststore and the intermediate CAs (for StartCom Class 1 and 2) are in Openfire’s keystore.
- The XMPP domain of the server (the server name) is jabber.podzimek.org.
- A StartCom Class 1 certificate with two altsubject names (jabber.podzimek.org, podzimek.org) works fine (attached in working.crt).
- A StartCom Class 2 certificate with the same two altsubject names also works perfectly fine.
- A StartCom Class 2 certificate with one more altsubject name (jabber.podzimek.org, podzimek.org, xmpp.podzimek.org) fails (attached in failing.crt).
- Importing with import-certificate.jsp yields a message saying Failed to establish chain from reply, which seems to be a nonsense, considering that the intermediate CA certificate is installed and other certificates from the same CA work fine.
- Importing manually into the keystore doesn’t work either, I’m getting the message Found RSA certificate that is not valid for the server** domain** from Openfire’s web interface.
- For the other two certificates, import-certificate.jsp just worked, no errors reported.
- I’m running OpenJDK 7.u65_2.5.2 on ArchLinux.
I tried to hack CertificateManager.java and X509Certificate.java just to find out what’s happening, i.e., why would a certificate with one additional alternative subject name get rejected. At the first glance it seems that no alternative subject names are extracted from failing.crt for some reason, but I didn’t have time to properly diagnose this issue.
Is there a quick hack to override these failing certificate “sanity checks” when I’m sure that my certificate is correct and valid? For example, the web interface disables some of the sanity checks by using “*” instead of the domain name. Is it possible to make the XMPP logic use the same “trick”, at least until this gets fixed?
working.crt.zip (4514 Bytes)
failing.crt.zip (4686 Bytes)
1 Like
Just a update on this: There’s also some kind of a discrepancy between /opt/openfire/resources/security/keystore and /etc/openfire/keystore, as supplied by the default ArchLinux package. Adding my Class 2 certificate to the keystore into /opt/openfire/resources/security/keystore yields a warning about the domain name mismatch (and the certificate is ignored), whereas adding the same certificate into the keystore in /etc/openfire/keystore causes a message saying that the keystore is corrupt. This is indeed a strange and buggy behavior. The import-certificate.jsp site adds the Class 1 certificate to the keystore in /etc/openfire/keystore, but refuses to add the Class 2 certificate anywhere.
1 Like
Same here. My cert is valid for www.domain.com (as an example) and domain.com. When imported, I see it in the certificate list as www.domain.com, and Openfire claims that more certificates are needed. I allow it to auto-generate out of curiosity, and it creates self-signed certs for domain.com. Instead of this behavior, it should validate all domains on the cert (as the cert I provided it works for domain.com too).
Your problem is benign and completely orthogonal to the one I reported above. Openfire always reports a missing certificate and wants to generate a DSA certificate (in addition to the RSA one). However, if you simply ignore the warning, it’s perfectly fine and encryption will work as expected. The missing DSA certificate warning has been in Openfire at least since 2007 and it has never been a real issue.
In my case, the certificate cannot be imported at all, i.e., it cannot be seen anywhere on the list of certificates, and encryption does not work at all, which implies that connections with mandatory encryption are not established at all. If you have a certificate for something.domain.com and domain.com and your JIDs have the form of user@something.domain.com, it will work perfectly fine, just as it worked for me up to now. The problem only gets exposed when your certificate is valid for something.domain.com, domain.com and somethingelse.domain.com. In such case, even though your Jabber domain is something.domain.com, Openfire will neither import your certificate, nor show it on the certificate list after you import it manually, because of a bug affecting the resolution of altsubject names in certificates. Certificates with one 3rd level domain work, but ones with two 3rd level domains are not recognized, despite the fact that one of the domains corresponds to the server name / Jabber domain.