Yes. It's taking a while for everything to catch up with the XMPP changes, so I'll need both _xmpp-server and _jabber records for s2s. On the c2s end, clients frequently don't know about _xmpp-client records, so they will have to be configured with a server of chat.cam.ac.uk instead of being able to autoconfigure based on the user's JID.
The other evil area is TLS certificate verification. The IETF security wonks required the XMPP WG to specify a TLS cert format which is impossible to buy, because it requires the server identity to be recorded with an id-on-xmppAddr OID in an otherName entity inside the subjectAltName. As well as being unable to buy such a beast, there's no documentation about how to create one with OpenSSL - it involves such magic as defining new OIDs in openssl.conf, and beyond that I start to get lost.
(The IETF have perpetrated this stupidity for HTTP too: RFC 2818 says that the cert must identify the server using the dNSName (sic) entity inside the subjectAltName. At least OpenSSL knows about this OID, but still if you buy a certificate it'll use the cn just like certs from 10 years ago, and totally ignore these gratuitous new complexities.)
This is probably soluble by writing a JEP which says how Jabber software should handle de-facto standard cn certs :-)
There's also the question of what name to have in the cert you present to the client. XMPP says it must be the server's JID, i.e. the domain part of the user's JID, in my case cam.ac.uk. However traditional clients seem to check against the server name, in my case chat.cam.ac.uk. I can probably deal with this either by presenting different certs on ports 5222 (starttls, therefore new) and 5223 (tls-on-connect, therefore trad), or by pointing the _xmpp-client SRV record at a different address than chat.cam.ac.uk. Some interop testing will be required.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
Date: 2006-01-19 11:02 (UTC)The other evil area is TLS certificate verification. The IETF security wonks required the XMPP WG to specify a TLS cert format which is impossible to buy, because it requires the server identity to be recorded with an id-on-xmppAddr OID in an otherName entity inside the subjectAltName. As well as being unable to buy such a beast, there's no documentation about how to create one with OpenSSL - it involves such magic as defining new OIDs in openssl.conf, and beyond that I start to get lost.
(The IETF have perpetrated this stupidity for HTTP too: RFC 2818 says that the cert must identify the server using the dNSName (sic) entity inside the subjectAltName. At least OpenSSL knows about this OID, but still if you buy a certificate it'll use the cn just like certs from 10 years ago, and totally ignore these gratuitous new complexities.)
This is probably soluble by writing a JEP which says how Jabber software should handle de-facto standard cn certs :-)
There's also the question of what name to have in the cert you present to the client. XMPP says it must be the server's JID, i.e. the domain part of the user's JID, in my case cam.ac.uk. However traditional clients seem to check against the server name, in my case chat.cam.ac.uk. I can probably deal with this either by presenting different certs on ports 5222 (starttls, therefore new) and 5223 (tls-on-connect, therefore trad), or by pointing the _xmpp-client SRV record at a different address than chat.cam.ac.uk. Some interop testing will be required.