Terminate SSL at f5 LoadBalancer


We are investigating the possibility to use OpenFire in our online gaming products. We want to terminate the SSL communication at our f5 loadbalancer (to keep our certificates in one place, and not spread over all our servers). We also want to use the Smack libary to have an easy integration between our Java Clients (e.g., Poker) and the OpenFire server. Initially we will go with only one OpenFire node behind the load balancer, but may consider scaling up later on (using Hazelcast plugin) if needed.

I guess this is a quite normal setup, so I hope that it works. But I did not find any conclusive information in earlier posts.

How do we setup this? What will the Connection code look like using the Smack library? What kind of work will be needed in the f5?

I appreciate all feedback.

/ Niklas

SSL was used in the beginning of XMPP, now TLS is used. Clients create an unencreypted connection to the server and negotiate encrcyption before they log in.

I have no idea whether there is a plugin/code for f5 to do what you want.

It makes little sense to use the SSL port (5223) as it is depreciated.

Hi and thanks for the fast reply.

I assumed to much about the solution in my original mail. SSL is not a requirement in itself. The reqs are actually the following

  1. We do not want to buy certificates and install on the OpenFire node (we have that in our f5 LB today).

  2. We need some kind of secure connection to protect the password send during the login.

Can you please elaborate on a solution for this?

I assume that you don’t want to share the certs on F5 with Openfire as you are concerned about the security of Openfire/your certs. Then you either have to buy one ($60/y - so quite cheap compared to other lic.+supp. costs) for Openfire or use your own CA and teach your clients to trust your CA.

Then you can also use client certs for authentication as described in the ssl guide.

An option to get rid of passwords is using Kerberos/GSSAPI - nothing for internet clients. But one will use TLS anyway to make sure that the conn. is encrypted.


We found the solution at


Problem now resolved.

/ Niklas