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?