I’ve been running an openfire server for a couple years now and there is something that I still can’t get a grasp on relating to my server domain and my server hostname and I’ve yet to properly deploy working SSL certificates as a result. This is one thing that is really making me feel like an idiot but I just can’t seem to grasp it. Jabber usernames are user@domain.com but, obviously, the jabber server is rarely reachable at domain.com which is why you use SRV records to point to jabberserver.office.domain.com… I grasp that concept and have SRV records set up, etc. But here’s where I can’t seem to get things right… it seems that the jabber server wants to operate as domain.com and not jabberserver.office.domain.com so it would make sense that you would get an SSL certificate signed for domain.com but this creates an issue when you go to https://jabberserver.domain.com:9091 and when your XMPP client is connecting to your server at jabberserver.domain.com since the certificate being presented is for domain.com.
Could someone please shed some light on how things work… I’ve tried googling and figuring this out but I can’t seem to find any information that relates to this – and some of it is probably quite simply that I don’t know what to look for.
I am not 100% sure, but from my gut feeling, your certificate needs to be signed for the service/domain name (e.g. domain.com), not the hostname.
XMPP clients should usually verify the domain.
I’ve found this quite useful for my development:
Java/Android SSLSocket Vulnerable to MitM Attacks
If the service you are using employs DNS SRV, the hostname (the actual machine you are connecting to, e.g. “xmpp-042.example.com”) might differ from the service name (what the user entered, like “example.com”). However, the certificate will be issued for the service name, so the verification will fail.
I agree, it gets confusing fast. A big help is this example in the RFC that defines the XMPP protocol. Look at the text just before the example for the specification. In short: certificates that are used for XMPP (servers) make use of certificate-extensions, to define the XMPP-specific characteristics that apply.
Most implementations will fall back to the common DNS name entries when those extensions are not available, which is why things often work as intended.
So right now I got a certificate signed for domain.com and installed it on my openfire server. My SRV records are pointing to jabber.office.domain.com (which is what my openfire server is running on, obviously) and I’ve specifically removed the “Connect server” from my Pidgin client… when trying to connect I get an error saying the peer presented an invalid certificate. It does identify domain.com in the error message rather than jabber.office.domain.com which is would do if I had the connect server specified but for some reason it still doesn’t like the certificate. I suspect that what you folks are saying is that something needs to be specified in the certificate specifically for the use of SRV records but I’m not quite sure I follow what or how. In the RFC link there are references to “An otherName type of SRVName” which seems to indicate that these need to be included in the certificate somehow which would make me think I need to include that in the CSR so that all of these “otherName” things are included in the signed certificate… but it’s my understanding that certificates essentially only sign a hostname so I’m completely confused.
I should also add that I tried creating a separate keystore for the client section and putting self-signed certificates in there and still get the same error. The only way that I seem to be able to connect to my server is if I generate certificates for jabber.office.domain.com and also put that server in the “connect server” field in my pidgin client…