Issues with Lync/Skype SIP Domains Not Present in Certificates

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, 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, 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:  This also discussed in the knowledge base article by Microsoft:

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 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 with a hostname of, 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=””;fqdn1=”″;source=””


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.

2 thoughts on “Issues with Lync/Skype SIP Domains Not Present in Certificates

  1. Kurshun

    hello, if I check the “Do not show me this again” this popup still remains after restarting my pc.
    do you have any reg key or a manual that I can force the do not show me this again option?

Comments are closed.