We’ve found that Adium and Pidgin work very well with our pilot setup – Openfire server, DNS SRV records so that people can use @stanford.edu Jabber IDs, using TLS on port 5222 and SASL/GSSAPI (Kerberos) authentication. iChat worked fine in the test setup, but doesn’t work on the pilot setup – the main difference being the DNS SRV records.

I spent some time this afternoon trying different settings with iChat, certificates, Kerberos and Openfire, using itlab.stanford.edu and im.itlab.stanford.edu.

Settings

DNS SRV record for itlab.stanford.edu, pointing to im.itlab.stanford.edu:

_xmpp-client._tcp.itlab.stanford.edu. 3600 IN SRV 5 0 5222 im.ITLab.Stanford.EDU.

Other settings:

Kerberos principal	xmpp/itlab-im.stanford.edu
Openfire xmpp.domain	itlab.stanford.edu
Openfire xmpp.fqdn	I tried both im.itlab.stanford.edu and itlab-im.stanford.edu – no apparent difference

Certificate

iChat gets stuck in a loop complaining about the certificate in the pilot environment, and doesn’t seem happy with either the XMPP domain name or the server name. I created a certificate with some DNS subjectAltNames to try and appease iChat, while hoping that it wouldn’t break Adium:

	Subject: C=US, ST=California, L=Stanford, O=Stanford University, OU=IT Lab, CN=im.itlab.stanford.edu
         X509v3 Subject Alternative Name:
                DNS:itlab.stanford.edu, DNS:im.itlab.stanford.edu

KeyChain on my Mac contains the root CA cert used to sign the cert.

Results

With this final setup¹ I can get Adium working by just entering my JID, then everything just works (auto discovery, TLS, Kerberos auth).

iChat needs more persuasion than Adium – auto configuration doesn’t work in this environment, but it can be coerced into working in a couple of less than ideal ways:

iChat with Kerberos and the IM Server Name

iChat can be made to work by using the server name in the Jabber ID (user@im.itlab.stanford.edu rather than user@itlab.stanford.edu):

This mostly works – the server is “autodiscovered”, although iChat defaults to port 5223 and SSL rather than using TLS. Users need to be aware that their JID is really user@itlab.stanford.edu, not user@im.stanford.edu, and they will have to type in the full JID of chat rooms (e.g. test@conference.itlab.stanford.edu) the first time (iChat auto-completes later attempts).

However, since the server name is hardcoded into the configuration, should the server fail, iChat won’t automatically reconnect to other servers defined in the SRV records at lower priorities. More testing is needed to determine if the server name can be a CNAME (alias) for the primary server, and if iChat will successfully connect to the primary, then the failover (after the CNAME is changed).

iChat with Kerberos with the Server Name and TLS

Again, manually configure the account, but this time specify the server name and port:

The results are the same as before, but iChat uses port 5222 and TLS rather than the deprecated port 5223 and SSL.

iChat with Auto Discovery, but without Kerberos

iChat can be configured to use autodiscovery if Kerberos is not enabled. While this is not ideal, the Jabber server will accept the username and password through a secure connection (SSL or upgraded to TLS) and authenticate the user against Kerberos, just like our POP and IMAP services.

Sadly, iChat autodiscovers the server name and port, then switches to the legacy SSL on port 5223 mode. It can be manually configured to use TLS on port 5222, but then the failover will not work, since it won’t query for SRV records.

Conclusion

iChat can be made to work, but all the solutions have problems. iChat appears to have problems with auto-discovery and Kerberos authentication (although this combination results in certificate errors, it doesn’t appear to actually be a certificate problem, since the same certificates work with Kerberos disabled), and it still seems to prefer the legacy SSL connection method rather than the recommended TLS upgrade option on the standard XMPP port.

There are some things that should still be tested:

• CNAMEs for the servers
• Using a certificate for itlab-im.stanford.edu, with subjectAltNames for itlab.stanford.edu and im.itlab.stanford.edu

Footnotes

1 I tried some variations on the subjectAltNames in the cert which made Adium unhappy, and many, many variations that caused iChat to loop on certificate warnings