Disclaimer
The solution I will describe here is not a standard one, so you must consider all the possible risks, including future updates / fix for the Lync 2013 server or for the clients that could enforce the best practices that are not fully respected in this approach with results that I can’t predict.
Reducing The Costs of Lync Certificates. Mismatched Domains and Other Tricks
Whenever you’re involved in a Lync project, you can be sure that the company you are working with will complain about the cost of SAN certificate required. If the infrastructure is shared between several different companies, you will have to add to the certificate more FQDN for the various SIP domains and the complaint will become sort of a howl.
The changes in the Lync 2013 client autodiscover process (and also in the Lync 2010 client, as I will explain later) and the possibility to use mismatched domains between the SRV and Host (A) records open an interesting opportunity to downsize the required SAN names to a total of six (S I X).
Our Scenario
Let’s imagine to have two companies, Lync2013.Org and MCEnigma.Org that will use a single Lync infrastructure (for example using a common resource forest). We want to keep the cost of our SSL certificates as low as possible, so we need to reduce the SAN names required to make our external users work (for the internal users a lot of different solutions including certificates from an internal C.A. are available).
A SIP domain for every company involved is required, so we will have to accommodate this in our solution.
Note: the process I will explain can be used to address multiple SIP domains. To keep it simple, in the example, I used only two domains.
First Step: Lyncdiscover
Lync 2013 client for Windows and Lync 2013 Windows Store App prefer to search lyncdiscoverinternal.<sipdoimain> and lyncdiscover.<sipdomain> for automatic sign-in.
The aforementioned FQDN are A records. The first suggestion, here, is to point the Lyncdiscover record to the address of our reverse proxy and leave the port 80 of the reverse proxy opened.
As you know, if your rules are well written, the server will retrieves resources on behalf of a client from the Lync Front End server on port 8080.
Working this way, you need no certificate for the automatic sign-in
Second Step: _sip._tls.<sipdomain>
The next step requires the record _sip._tls.<sipdomain> that you usually will point to the public FQDN of the Edge Server and you will have one FQDN for every domain.
But we are going to keep our costs low, so we will point _sip._tls. Lync2013.Org and _sip._tls. MCEnigma.Org to SIP.Lync2013.Org
Now, if your user’s SIP domain is Lync2013.Org the aforementioned solution will work with no issue.
What about MCEnigma.Org users ? Well, basically they will receive an error from their client, explaining that they are talking with a host that is not part of their SIP domain.
They can “hide” this message after the first time and they will be able to use Lync from the external network with no problem (you can also work on group policies to add Lync2013.Org to the list of trusted domains for MCEnigma.Org).
For more details please read this article Lync cannot verify that the server is trusted for your sign-in address
So, we no longer need a SAN in our certificate for the SIP record of every single domain.
Third Step: Webconf.<sipdomain>
The aforementioned record is required for web conferencing BUT in our scenario we will need to publish only Webconf.Lync2013.Org
Fourth Step: AV.<sipdomain>
Simply you do not need it, so you will not have to add it in the SSL certificate for any domain.
Lync Server no longer requires that the AV Edge FQDN is provided in the certificate.
Fifth Step: Simple URLs of Lync
Here we are talking about meet.<sipdomain>, dialin.<sipdomain> and admin.<sipdomain> that are the records required for the web services of Lync.
Let’s start from the latter admin: if you have no intention to open the Lync Control Panel from the external network, you do not need it.
Dialin: you will have a single name (let’s say dialin.lync2013.org) because multiple name for the dialin conferencing service are not supported.
Meet: as I explained here some time ago Understanding Simple URLs In Lync you are able to use a single root FQDN and to create a specific URL for all the required SIP domains in a form like
https://meet.lync2013.org/sipdomain1/Meet
https:// meet.lync2013.org /sipdomain2/Meet
Let’s Summarize
The reverse proxy requires to have in the SSL certificate the public FQDN of the Lync Enterprise Edition Pool or the public FQDN of our Standard Editions servers in the subject name of the SSL certificate.
The Lync Edge expects to have its public FQDN in the subject name of the certificate (you could use SIP that is required anyway or pick up another name).
We may decide to require two different certificates
_________________________________________________________________________
Certificate 1 (to apply on the Reverse Proxy)
Subject Name: FQDN of the Lync Front End
SAN: FQDN of the Lync Front End
SAN: meet.<sipdomain>
SAN: dialin.<sipdomain>
_________________________________________________________________________
Certificate 2 (to apply on the Lync Edge)
Subject Name: FQDN of the Lync Edge
SAN: sip.<sipdomain>
SAN: Webconf.<sipdomain>
_________________________________________________________________________
As you can see we are able to deploy our external user access with a six names that we could decide to distribute as in the aforementioned schema or to put in a single certificate, with Subject Nameè FQDN of the Lync Edge and the FQDN of the Lync Front End added as a SAN.
What About The Lync 2010 Client?
Looking at this article “Understanding Autodiscover” there is an important phrase: Additionally, newer versions of the Lync 2010 and Lync 2013 desktop client prefer Autodiscover over the domain name system (DNS) SRV records, using DNS SRV records only if lyncdiscover.<domain> or lyncdiscoverinternal.<domain> does not respond or does not resolve.
The implication are clear: if you have done your homework and kept the Lync 2010 client up to date with the various C.U. and patches, the autodiscover process is the same you have with the Lync 2013 client. And the solution depicted here works also for the “legacy” clients
What about federation? Presumably this will not work on your 2nd sip domain, unless the 3rd parties manually specify your sip domain and edge server? This also applies to desk phones, which require the registrar domain to match the sign in domain.
Good morning Ben.
You raise an important issue.
The only kind of federation that probably will not work properly with this configuration is the Dynamic Federation.
If things have not changed from Lync 2010, Dynamic Federation is limited to 20 SIP messages per second and a thousand contacts
So, you might want to use one of the following available solutions not only to resolve the issues with certificates.
Enhanced Federation and Direct Federation (both require a manual configuration) should not be affected by the measures used for certificates.
For desk phone, the problem arises only if they are distributed on the external network (which is not really common).
On the internal network you are able to use certificates from an internal CA , and in this scenario there is no need to “play” with domain names because you pay no money to add SAN names.
The Front End Lync supports two separate configurations for the certificates (also) for this.