powered by Jive Software

Import SSL Certificate (Openfire 4.3.0)


#1

I am trying to import my SSL (wildcard) certificate.

There used to be an option in the WebGUI (Server Settings -> Server Certificates) that would allow you to import the SSL cert.

I upgraded to Openfire v4.3.0 today & that sub-menu is no longer listed.

The Openfire server is running on CentOS 7.


#2

There is now a separate plugin Certificate Manager. Maybe that menu is part of that plugin.


#3

Thanks for the tip, wroot!

I placed my .crt and .key files into the directory that the “Certificate Manager” is designed to check.
/opt/openfire/resources/security/hotdeploy

I also have the option labeled “Delete files from the hot-deploy directory after installation” checked-off. However after restarting the (Certificate Manager) plugin my 2 files (still) remain in-tact within this directory.

Also, I don’t think I WANT to add my SSL cert to the “Openfire identity store”.
I just want to assign the certificate to the HTTPS service, so when I navigate to https://hostname.domain.com:9091, the web browser will not display a message saying “untrusted site”.


#4

I’m not familiar with what types of certificates files should be put in that folder. Maybe you should ask in chat on this site (Guus was the author of this plugin). Openfire uses the same certificate for HTTPS and encrypting clients connections (TLS), so i think it should be imported to the store.


#5

TLS is a tricky beast.

It’s good to know that the certificate manager plugin does not add any functionality, apart from automation. You can manage the content of your stores, without that plugin, in the Openfire admin console under “Server” > “TLS/SSL Certificates”

Openfire uses a set of stores, consisting of:

  • Identity Store - this holds your private key and certificate (identifies your instance of Openfire)
  • Trust Store - this holds certificates for CAs that your instance of Openfire will trust (used to verify the certificates that are served by others).
  • Client Trust Store - (this often is unused/empty) Can hold certificates that are used to perform mutual authentication (eg: when your clients authenticate using a certificate, instead of the more traditional username/password).

Under water, all of these stores are Java keystores (it is fine to modify them directly, using Java tooling, although you might need a restart to see changes pop up - I’m unsure).

By default, Openfire will use the same set of stores for all types of connections. You can, however, define distinct sets of stores for different types of connections. You can do this by clicking on the link that is under this text on the “Server” > “TLS/SSL Certificates” admin console page:

(…) but Openfire allows you to configure a distinct set of stores for each connection type

Caveats:

  • Using different sets for different connection types is not used often - here might be dragons
  • It’s unlikely that using different sets for different connection types plays nice with the certificate manager plugin (tha’d be one of the aforementioned dragons).

#6

Also, the user running openfire needs to have access to the certificates in the hotdeploy directory. For me (also CentOS7), that’s daemon.

Previously, we had to delete the previous (to be replaced) cert from the keystore via “keytool -delete …”, but I don’t know if that’s necessary now.

If you have good results replacing an existing certificate using hotdeploy alone, I’d appreciate some confirmation.


#7

Here is what I ended up doing.

Believe it (or not) it was only a five-step process!


#8

This is exactly what I needed in order to get me on the right track. Thanks guss!!


#9

I (tried to) automate this with an LE cert:

  1. Delete old certificate (not sure if this is necessary): /opt/openfire/jre/bin/keytool -delete -alias -keystore /opt/openfire/resources/security/keystore -storepass

  2. Copy certs to /opt/openfire/resources/security/hotdeploy

  3. chown daemon:daemon /opt/openfire/resources/security/hotdeploy/*.pem; sleep 10; systemctl restart openfire

The certificates usually get sucked up immediately after chown daemon:daemon.


#10

systemctl restart openfire

:scream:

That defeats the purpose of ‘hot-deploying’!

Note that in the upcoming 1.2.0 release of the certificate manager plugin, useful new features are added, including more robust detection of new certificate files, as well as backups.


#11

It does!

In my case, I’m more utilizing the hot-deploy as a means to automate deployment of the updated certs.

Is there a better way to restart the webserver to utilize the new cert?