Control auto-creation of self-signed certificate


Currently a self-signed certificate is created when Openfire does its autosetup and no certificate for the current XMPP domain is present. I would like the option to turn off the auto-creation of self-signed certificates.
We have a dev/test setup which, for historical reasons, uses the same xmpp domain as our production system, but uses a different host URL. Whenever we do a deployment to our dev environment we have to remember to remove the self-signed certificate otherwise clients can’t connect.

Best regards

Hi Johan,

Auto-creation of that self-signed certificate will be skipped when the keystore, before first start, holds a valid certificate for the domain that Openfire is configured with. If you can replace the keystore file with an older copy before you start Openfire, you might be able to prevent the issue.

We have a keystore which holds a certificate for the URL at which clients connect to. But that doesn’t seem to be enough. The auto-created self-signed certificate is created with the XMPP domain as the primary name, and the FQDN (which we already have a CA-signed certificate for) as a subject alternative name. This has the effect that our CA-signed certificate is hidden by the self-signed certificate and clients can’t connect since they don’t trust it.

A certificate needs to be present that at least covers the XMPP domain. I don’t believe that it matters if it’s covered by the Subject of the certificate, or throught a SAN entry.

Note that I suspect that having more than one certificate might not work in all cases: I’ve observed some versions of Java to pick one certificate (maybe at random) from the keystore (even when there are more suitable certificates in that store), and use only that certificate.

For our purposes it doesn’t matter if it covers the XMPP domain, we have successfully used certificates for several years which only covered the urls where clients connect to, which is different from the XMPP domain.

The whole world is moving slowly towards HTTP-only, I guess. :slight_smile:

I wasn’t suggesting that you needed the XMPP domain to be covered in your certificate, but if you can make that happen, it should prevent the auto-generation of that self-signed certificate. That might be a workaround for the issue that you’re experiencing.

As a workaround I wrote a plugin which deletes any self-signed certificates at startup, which solves our problem for now. But the thing with a workaround is that it is just that, a workaround. It would be infinitely better if we could control this at startup.

I think it also could be beneficial for those that use the CertificateManager plugin together with the short-lived certificates that e.g. Let’s Encrypt issues. It’s not always that a certificate is present at start time, the certificate request could take a while.