A while back I posted a blog article related to how many SIP domains Lync supports. In this article we discussed the sip domain that does not exist in the certificate. I wanted to quickly revisit that a bit and explain some of the caveats to this method and show a couple of examples of what the connection looks like when you’re using a certificate that isn’t fully trusted.
Let’s start with what the login looks like when you’re using a certificate that’s not fully trusted by the server and you don’t have your TrustModelData registry key in place. As you can see from the below screenshots, a popup is warning us that even though our sip domain is student.weseeuc.com, the certificate does not include a record that matches this domain.
Similarly, you can see the response from the Lync 2013 mobile client for the iPhone. Our sip domain is student.weseeuc.com, but that does not match the domain name on the supplied certificate.
There are a few methods to combat this. One is the already mentioned TrustModelData registry key we can push out to clients. The other primary one is to simply communicate to users to check the “Do not show me this again” box or equivalent, which they would likely have done anyway over time.
With one of these client side settings in place, we should be able to log in and use Lync without the warning. Still, there are two situations I wanted to discuss however that are a bit harder to navigate around.
The first is strict domain naming with Lync Phone Edition, we discussed this a little before. Jeff Schertz has covered this long ago in an article that has more views than my entire blog: http://blog.schertz.name/2013/08/lync-phone-edition-cu7-registration-issues/. This also discussed in the knowledge base article by Microsoft: http://support.microsoft.com/en-us/kb/2933146
The LPE issue can potentially be avoided by 3PIP phone devices, but there’s another issue that’s even more difficult to overcome and that’s open federation.
Open federation refers to the ability to openly chat with other organizations without hard-coding each other’s edge server FQDN in your respective Lync deployments. This federation is made possible with the use of the _sipfederationtls._tcp.sipdomain.com SRV record. Open federation simply will not work if you don’t reference a host matching the sip domain, and this host needs to exist in your certificate For example, if you have an SRV record for _sipfederationtls._tcp.student.weseeuc.com with a hostname of sip.weseeuc.com, open federation with outside firms will fail by design. If you’re watching your logger, these may manifest as a 504 server time-out: ms-diagnostics: 1009;reason=”No match for domain in DNS SRV results”;domain=”student.weseeuc.com”;fqdn1=”sip.weseeuc.com:5061″;source=”sip.domain.com”
So with these caveats in mind, please understand that while it is possible to have SIP domains that do not exist in your certificates, there are functionality limitations that you will need to plan for carefully.