Wednesday, July 30, 2008

x509 certs and XMPP servers

Ok, one last XMPP post for tonight.

I came across an interesting issue with our test XMPP server today. When the server was initially created, it was setup with an x509/SSL certificate that was self signed. That cert expired the other day, and I had to replace it.

Some of the people who were using the server started getting cert warnings while others did not. After a bit of investigating, I found the problem.

There are two ways that an XMPP client can connect to a server.

The first method is simple. You configure your client with your Jabber ID (username@company.com), and define an XMPP server (servername.company.com) to connect to. This is how our early documentation recommeded configuring your clients, but it is not the generally recommended method.

The second method is the preferred one. You define a service record (SRV record) in DNS for _xmpp-client._tcp.company.com which points to your server name. Once your client has your Jabber ID (JID), the client will automatically look up the SRV record, and connect to that service.

Now comes the cert warning. Apparently if you use an SRV record, your x509 cert needs to have a common name (CN) of company.com. If you define a server manually however, your CN needs to be the name of the server.

Our self-signed cert was for company.com. I replaced it by a properly signed cert for servername.company.com, and broke everyone using the preferred configuration method. Seeing the issue, I replaced it with a properly signed cert for company.com, and broke the people following the published documentation.

*sigh*

So now I get to update the documentation and answer the various questions for people. Longer term I'm going to see if its possible to provide certs for both methods. While you can't have two certs on the same port, it may be possible to either use a cert with an altCN, or possible have the SRV port point to a non-standard port so that people who define the server name can connect to the default port number (5222/5223).

Managing your own Chat server

Recently for work I've been dealing with trying to build a robust IM server environment for the company I work for. The plan was to allow employees to chat with each other without the conversations ever leaving the company. Our hope was to also tie the system into the various public instant messaging systems (AIM/MSN/YIM) so that we could use the same system to communicate with customers.

After looking around at various offerings, the choices boiled down to a Jabber/XMPP based solution or a SIP/SIMPLE service like Microsoft OCS or Lotus Sametime. Since XMPP has more open source libraries for coding against it, we decided to go the XMPP route. Personally I was happy since the peer to peer nature of the SIP protocol introduces a few problems on our network.

Of course, deciding on XMPP doesn't really narrow things down too much. There are a number of open source XMPP/Jabber servers out there, and quite a few commercial ones as well.

We looked at Jabberd2, eJabberd and Jabber XCP.

As far as I can tell, Jabberd2 and Jabber XCP are very similar in codebase, at least judging by the configuration file format. The thing that the commercial Jabber XCP product provides is a nice web interface for configuring the service, a pair of supported clients (one Windows client, one web based client) as well as commercial support.

eJabberd was impressive. It is an open source application written in Erlang, which I wasn't familiar with. Erlang was a programming language created for distributed computing by Ericsson. On smaller installations, it can handle clustering without any form of external database. It automatically manages synchronization between nodes of the cluster.

Version 2.0 of ejabberd also included a very nice web interface for managing the service, and included an inpressive number of plugins. Configuring the service was very very easy.

At the end of the day, we ended up going with Jabber XCP. The main reason is the one feature that no one else was able to provide. The ability to really tie into the public IM systems, or at least one of them. Any XMPP server can tie into other XMPP services (like Google Talk), but Jabber XCP offered the ability to tie into AIM as well.

The majority of Jabber/XMPP servers offer transports for the various IM services. What these transports do is essentially allow you to log into your own AOL/MSN/etc account from within your IM client. So I may be myname@company.com within my company, but I would be logging into my gdfuego account on AIM.

Jabber XCP has a plugin (for additional per user cost), which allows you to actually use the same myname@company.com address within AIM itself. Unfortuantely MSN and YIM aren't an option at this time.

Right now I'm getting close to turning our new server live, and I've been hitting a number of snags, but that'll be a story for another day.