Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have the following problem: After I setup an intranet Jabber/XMPP server, I asked an SSL certificate for my server, so people can connect securely using a valid certificate.

The DNS of is configured to redirect

root@dowa-01:/var/log/ejabberd# host -t SRV has SRV record 5 0 5222
root@dowa-01:/var/log/ejabberd# host -t SRV has SRV record 5 0 5222

The problem is that when I try to connect with the XMPP client, I get an hostname mismatch between and ?!

As long the DNS is redirecting to another domain, why is the client asking about a certificate on original domain?

Details: the is a domain used by the corporate intranet, most internal stuff are on it. Obviously, people are supposed to login with their email address and domain password.

How am I suppose to solve this problem? I am pretty sure that Security would not give me a root domain certificate for the public domain.

I assumed that pointing the DNS would work, but it seems that it doesn't.

Any workarounds?

share|improve this question
Having your SRV records point to, your certificate should list that host name in the SubjectAltName list, too. – vautee Mar 7 '14 at 14:07
@vautee I do have a SSL certificate that has the the wildcard intranet domain (* in SAN list. Still, when I try to connect with XMPP clients they will complain about HOSTNAME not matching certificate. My impression is that the clients do expect an valid certificate even if the DNS server does report that that XMPP server is running on – sorin Mar 10 '14 at 15:04
Never forget: * NEVER matches itself. And since your JIDs are named, your jabber clients will check for in the certificate - simply "ignoring" the host name from the SRV lookup. – vautee Mar 17 '14 at 19:31

1 Answer 1

up vote 2 down vote accepted

Yes, you need a certificate for, it being valid for does not matter. This is because DNS is considered untrusted: it would be very easy to poof your SRV record to point to a malicous server, for which an attacker might have a valid and trusted certificate.

There are some proposed solutions to this problem (including DANE and POSH), but none of those are currently supported by clients. The only solutions are: 1) make everyone accept the certificate mismatch, 2) use as your XMPP domain or 3) convince security you need a certificate for

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.