The document discusses certificate planning and assignments for various Lync server components including Edge, Reverse Proxy, Director, Frontend, Mediation, and WAC servers. It provides details on the common name and SAN entries required for certificates on each component depending on the topology, whether it is an internal, external, or complex geographic deployment. Certificate requirements differ based on the server's role and whether it is facing internally or externally.

1. © 2013 - Thomas Pött, Microsoft MVP LYNC
Lync Certificate Planning and Assignments
(Edge,ReverseProxy,Director,Frontend,Mediation,WAC)
Copyright© and written 2013 by Thomas Pött, MVP Lync/ Unified Communication
Blog: http://lyncuc.blogspot.de/2013/02/demystify-lync-enterprise-voice-phone.html
Email: Thomas.Poett@live.de
1 About the Author:
Thomas Pött, Microsoft MVP LYNC and MCITP Lync
Extensive experience in business and market development. Specialized in intercultural and business
relationship in Asia. Successful in providing leadership on new topics and complex global projects that require
interfacing with internal/external teams and ecosystems. Early adaptor of visionary technologies.
• 20+ year career within different companies in the areas software development, telecommunication, IT,
mobility and hosted/cloud services.
• Strong technical and business background – was member of Microsoft´s German Inner Circle.
• Organized, logical, rationale thinker and problem solver with superb communication and collaboration
skills.
• Business Management skill in strategic and organized developing German SME subsidiaries in Asia
Specialties: Management:
Start up companies, Business Relation Management, Partner Relation Management, Enterprise Business
Sales Skills, strong team leader and motivator, perfect Asian business and human behavior understandings,
excellent financial cash flow management
Technical:
Microsoft Office 365, Public and Private Cloud Computing, specialized in Hybrid Cloud integration, Unified
Communication (LYNC, OCS, Exchange), Security (PKI, ForeFront), Active Directory, German efficiency in
consulting
I’m living in Bad Wiessee, Germany near Munich and work for ACP IT Solutions AG. Beside the technical
interests, I enjoy paragliding and para-motor.
This article will part of my new book I’m working on, since Lync Enterprise Voice is a more and more complex
environment, where it’s difficult to get the right information.
Any suggestion what areas of EV are from interest, I would be glad to be inspired.

2. © 2013 - Thomas Pött, Microsoft MVP LYNC
The following article is optimized for Lync 2013, but in general valid for Lync 2010 or OCS 2007
NOTE:
First I need to highlight to you is a topic, I’m always ask for support. Lync Server and Client make use of
Certificates, therefor the technical principals of certificate deployments are necessary to understand. If
on your Clients or Servers an Internet Explorer Setting with a Proxy Server is activated, make sure you
have the correct design. The CRL (Certificate Revocation List) check is mostly HTTP based (in AD
Environments also possible via FILE or LDAP), if you have setup an internal Proxy, which cannot redirect
the request into your LAN, you will run into major issues!
I wrote another article in 2012 which maybe from interest for you too:
Forefront TMG – Directors, Front End and Standard Edition for Lync

3. © 2013 - Thomas Pött, Microsoft MVP LYNC
2 GENERAL
Lync Certificate Planning must be separated into three different areas:
1. INTERNAL Deployment
(all internally deployed Lync Servers, e.g. Frontend, Directors, Mediation,..)
- Including the internal NIC of the EDGE Server
2. EXTERNAL Deployment
2.1. Edge Server
2.2. Reverse Proxy
Indirectly there is a fourth area, this is if you have Pool Server configuration, due the Virtual Service
configured on the Load Balancer. But I will explain this in detail within another blog later.
All Lync Server have one requirement in common, this is the way how they accept authentication based
on TLS. Accepting the trust, Lync Server need a matching between the certificates common name and it
FQDN. The server or client, initiating the communication with the certificate holder use DNS lookup to
refer to this server FQDN. If this reference does not match the common name of the certificate, the
authentication will fail.
The common name, notated as CN in X.500 terminology, is what is referenced and must match the DNS
record for the server’s FQDN. For details about the specific format http://www.ietf.org/rfc/rfc3280.txt.
This explains why a dedicated wildcard certificate would not work in Lync Server, because the common
name must match exactly to the FQDN of the A record defined for the referenced server or pool. The
DNS A record and the certificate subject name/common name (SN/CN) is also referenced to the trusted
server list in Active Directory service Global or Configuration settings.
Reference: Microsoft Technet Certificate Guide
Important: You cannot use a wildcard CN/SN (for example, *.contoso.com) when you configure
certificates for Office Communications Server 2007 R2 and Office Communications Server 2007
(now Lync). If you do so, they will not operate as expected and the problem is very difficult to
diagnose. You can use wildcard entries in the subject alternative name, but the common name is
specific. Specific issues include the inability to start services because the trusted services in
Active Directory Domain Services (AD DS) and the SN and CN do not match, mutual
authentication fails, and so on.

4. © 2013 - Thomas Pött, Microsoft MVP LYNC
Note at last:
And, as mentioned earlier, public CAs and your internal CA can create wildcard SN/CN certificates, but
they are neither reliable nor supported. It is recommended that you do this right the first time and avoid
the potential for serious issues in the future by not trying to use a certificate that uses a wildcard SN/CN,
such as *.domain.com, to define the three Edge Server services.

5. © 2013 - Thomas Pött, Microsoft MVP LYNC
3 Server Components
(Certificates are requited)
3.1 INTERNAL Deployment:
Standard Edition Front End Pool Server
This server is the consolidated “all-in-one” Server and requires an internal certificate.
Enterprise Edition Front End Pools
This server is the High-Available Lync Core Component. Beside the local servers themselves, they also
provide the consolidated access names and are attached with a Load Balancer. The certificate must
contain the Pool and Server name. In certain circumstance it makes sense haven a generic certificate,
which contains all Pool Server Names and the Pool Name (SAN certificate).
Director Pools
This server is the “Authentication and Redirection” server. In lager deployment, with multiple site, you
need the Director to offload authentication traffic and redirect the user to the homed pool.
Mediation Pools
This server is responsible for Media Conversion
Persistent Chat Pools
This server handles the “Group Chats”
Trusted Application Server
All Server, which need to be trusted by Lync have to be publish that Lync is aware of them. If A
certificate is required if the trusted server will us TLS.
PSTN Gateway

6. © 2013 - Thomas Pött, Microsoft MVP LYNC
The PSTN Gateway object, might be a Lync Gateway, Gateway card or an SIP Trunk. With the PSTN
Gateway, this depends on how the setup must or can be done. If you make use of a TLS connection, e.g.
to an ISDN card, you will need a certificate stored on the PSTN gateway.
Office Web Apps Server
The WAC/ OWA server requires a certificate, this is OAuth ready.
NOTE:
As described in the section for Front End Pool Server, generally it has to be part of the planning how
certificates are requested if a Load Balancer is involved. A Load Balancer can be setup in different way
(in-band or out-band), this will discussed in a separate blog. But you need to remember, the Load
Balancer is the central point for the IP connection, therefor it needs the FQDN of the POOL in its
certificate presenting to the connecting client. Depending on how the Load Balancer is established, you
will than understand why the Pool Member Server needs beside the Pool FQDN also its local FQDN in its
local certificate!
3.2 EXTERNAL Deployment:
Edge Pools
The Edge Server is the main component used to communicate from and with outside of the
organization. (Responsible for PIC, XMPP, Federation, remote access and Web Conferencing)
Edge Pools have one specialty, for best practice and security reason, they make us of 2 NICs, an internal
and external.
Note:
Edge Server need to have 2x NIC with different subnet, need the primary internal DNS Suffix set, must not
be a domain member and will need to certificate, and internal CA issued certificate for the internal
directed interface and an official, public certificate (where I will take more later about). Additionally,
remember to set the default gateway on the external facing NIC and all internal subnet must be assigned
a static route based on the internal facing NIC.
Reverse Proxy
This optional component only needs an external certificate and it’s responsible for Web-Based Services,
e.g. Address Book or Dailin Conferencing page.

7. © 2013 - Thomas Pött, Microsoft MVP LYNC
4 Topologies
Topology represents your entire corporate Lync Server deployment and all involved Lync Systems, with
one exception, the Reverse Proxy. Since we want to define the necessary certificates, it is necessary to
fully understand the topology and server function which then represents the service making use of.
4.1 Internet facing Systems
Before we actually start with the topologies, we need a clarification what the external facing system will
do, what they are responsible for and what not.
Else which kind of usability scenarios do we have?
 Remote Users
 Federated User
 Public Instant Messaging Connectivity Users
 Mobile Users
And the type of communication:
 IM
 Presence
 Audio/ Video/ App Sharing
 Web Conferencing
 A/V Conferencing
4.1.1 Edge Server:
The Edge Server, the Internet facing system responsible for enabling users to communicate with
external partners, connect remotely and establish connectivity with Public IM Services, like Live or
Skype.
Also the Audio/ Video and App Sharing runs through the Edge server if a Meeting is in place.
One newer component, called XMPP (Extensible Messaging and Presence Protocol), is established in
Edge Server since Lync 2013, it is used for partner federation e.g. Google Talk.
Edge Server is not responsible for any other service as the described services in this section.
4.1.2 Reverse Proxy:
Reverse Proxy as an optional, not Lync Server Topology component, becomes responsible for several
areas and will publish internal resources.
It can be separated into two areas, the remote user connectivity and generally spoke “meeting’s”.

8. © 2013 - Thomas Pött, Microsoft MVP LYNC
Remote User:
Remote user need to connect to Lync server internal service, called “Web Service”, they are responsible
for Address Book Synchronization, Distribution List Expansion, Device Updates, Mobility Services.
Meetings:
Access to Meetings, Conference Join Locations (PSTN Dial-In Numbers), Access to personal Dial-In and
PIN information, Download Meeting Content.
4.2 Topology and certificate assignment
In sum we will have one primary and two secondary SIP Domains in our example topologies defined.
The third deployment would be a very complex scenario, where we have multiple geographically
deployed Edge Server/ Reverse Proxy scenario.
I’m not having a look into Enterprise Voice, it is not required since we want to understand the certificate
design.
Our deployed domains are:
Active Directory Domain: INTERNAL.AD
SIP PRIMARY DOMAIN: DOMAIN.COM
SIP Secondary Domain: DOMAIN-A.COM and DOMAIN-B.COM
In general, what we have to remember for Lync Topology designs and the related certificates is:
1. On Edge Server, Wildcard Certificates are not allowed
2. On Edge Server we need matching CN and 1st
SAN entry of access FQDN, e.g. SIP.DOMAIN.COM
3. On Edge Server we need SAN entries for AV and WebConferencing
4. On Reverse Proxy, we need a matching CN with the associated Director Pool external Web
Service FQDN
5. On Reverse Proxy, all external Web Service FQDN must be in SAN
6. On Reverse Proxy all other FQDN can be consolidated in a Wildcard entry

9. © 2013 - Thomas Pött, Microsoft MVP LYNC
4.2.1 SIMPLE TOPOLOGY
The “SIMPLE TOPOLOGY” is the most common deployment for smaller customers. High availability is
mostly not required by Lync due to virtualization. For those customers, VM Host availability and
snapshots are sufficient enough.
The simple deployment includes the full feature set of Lync in direction to the internet. This includes
login possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.
LAN DMZ INTERNET
Office Web Apps
PKI internal
Lync Front End
Lync Edge
Reverse Proxy
Public CA
Common Name:
edge.internal.ad
Common Name:
sip.internal.ad
SAN*:
fe01.internal.ad
sip.(alldomains)
lyncdiscoverinternal.(alld
omains)
dialin.domain.com
meet.domain.com
Common Name:
wac01.internal.ad
Common Name:
sip.domain.com
SAN:
sip.domain.com
sip.domain-a.com
sip.domain-b.com
webconf.domain.com
Common Name:
webext.domain.com
SAN:
webext.domain.com
*.domain.com
*.domain-a.com
*.domain-b.com
Listener01:
To Lync Front End
Listener02:
To OfficeWeb Apps
SIMPLE TOPOLOGY
*) if you what establish multiple domain based simple URL, all
of them must beincluded in the SAN.
You also have the opportunity creating the same wildcard+
SAN mixture certificate.

10. © 2013 - Thomas Pött, Microsoft MVP LYNC
4.2.2 COMPLEX TOPOLOGY
The “COMPLEX TOPOLOGY” is the most common deployment for lager, multi pool customers. High
availability is required for Lync and due to multi pool deployments, login traffic must be handled by
Director Servers.
This deployment includes the full feature set of Lync in direction to the internet. This includes login
possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.
LAN DMZ INTERNET
Office Web AppsPKI internal
Lync Front End
Pool02
Lync Edge Pool
Reverse Proxy
Public CA
Common Name:
edge.internal.ad
SAN:
edge.internal.ad
edge11.internal.ad
edge12.internal.ad
Common Name:
pool02.internal.ad
SAN*:
pool02.internal.ad
fe21.internal.ad
fe22.internal.ad
web02ext.domain.com
dialin.domain.com
meet.domain.com
Common Name:
wac01.internal.ad
Common Name:
sip.domain.com
SAN:
sip.domain.com
sip.domain-a.com
sip.domain-b.com
av.domain.com
webconf.domain.com
Common Name:
webext.domain.com
SAN:
webdirext.domain.com
web01ext.domain.com
web02ext.domain.com
*.domain.com
*.domain-a.com
*.domain-b.com
Listener01:
To Lync FE Pool01
Listener04:
To OfficeWeb Apps
COMPLEX TOPOLOGY
Lync Director
Pool
Lync Front End
Pool01
Common Name:
pool01.internal.ad
SAN*:
pool01.internal.ad
fe11.internal.ad
fe12.internal.ad
web01ext.domain.com
dialin.domain.com
meet.domain.com
Common Name:
sip.internal.ad
SAN*:
sip.domain.com
dir11.internal.ad
dir12.internal.ad
webdirext.domain.com
meet.domain.com
dialin.domain.com
lyncdiscoverinternal.(alld
omains)
Listener02:
To Lync FE Pool02
Listener03:
To Director Pool,
simple URL,
mobility and its
WebService
SIP.alldomains
+ Simple URL
+ Mobility
+ WebService
*) if you want to establish multiple domain based
simple URL, allof them must be included in the SAN.
You also have the opportunity creating the same
wildcard + SAN mixture certificate.
Wildcard is supported for simple URL only

11. © 2013 - Thomas Pött, Microsoft MVP LYNC
4.2.3 GEOGRAPHICALLY deployed COMPLEX TOPOLOGY
The “GEOGRPHICALLY COMPLEX TOPOLOGY” is the most complex deployment for international
customers. High availability is required for Lync this is also extended into a multi-region Edge Access
scenario.
This deployment includes the fully feature set of Lync in direction to the internet. This includes login
possibility for all Lync Clients, incl. App Store and Mobile clients. Federation is also handled.
The main component for geographically distributed deployments is the GEO-Load Balancer. It handles
the Internet based distribution for Edge Access.
Since I’m talking about Certificates, it is important to understand the Certificates distribution.

12. © 2013 - Thomas Pött, Microsoft MVP LYNC
DMZ
Lync Edge Pool
GERMANY
Reverse Proxy
GERMANY
Common Name:
sip.domain.com
SAN:
sip.domain.com
sip.domain-a.com
sip.domain-b.com
av.domain.com
webconf.domain.com
Listener01:
To Lync FE Pool01
Listener04:
To OfficeWeb Apps
Listener02:
To Lync FE Pool02
Listener03:
To Director Pool,
simple URL,
mobility and its
WebService
LAN DMZ INTERNET
Office Web Apps
PKI internal
Lync Edge Pool
USA
Reverse Proxy
USA
Public CA
Common Name:
wac01.internal.ad
Common Name:
sip.domain.com
SAN:
sip.domain.com
sip.domain-a.com
sip.domain-b.com
av.domain.com
webconf.domain.com
Common Name:
webdirUSext.domain.com
SAN:
webdirUSext.domain.com
webdirGERext.domain.com
web01ext.domain.com
web02ext.domain.com
*.domain.com
*.domain-a.com
*.domain-b.com
Listener01:
To Lync FE Pool01
Listener04:
To OfficeWeb Apps
GEORGRAPHICALLY deployed
COMPLEX TOPOLOGY
Lync Director
Pool USA
Lync Front End
Pool01
Common Name:
pool01.internal.ad
SAN*:
pool01.internal.ad
fe11.internal.ad
fe12.internal.ad
web01ext.domain.com
dialin.domain.com
meet.domain.com
Common Name:
sip.internal.ad
SAN*:
sip.domain.com
dir11.internal.ad
dir12.internal.ad
webdirUSext.domain.com
meet.domain.com
dialin.domain.com
lyncdiscoverinternal.(alldom
ains)
Listener02:
To Lync FE Pool02
Listener03:
To Director Pool,
simple URL,
mobility and its
WebService
SIP.alldomains
+ Simple URL
+ Mobility
+ WebService
*) if you want to establish multiple domain based
simple URL, allof them must be included in the SAN.
You also have the opportunity creating the same
wildcard + SAN mixture certificate.
Wildcard is supported for simple URL only
Lync Front End
Pool02
Common Name:
pool02.internal.ad
SAN*:
pool02.internal.ad
fe21.internal.ad
fe22.internal.ad
web02ext.domain.com
dialin.domain.com
meet.domain.com
Lync Director
Pool GERMANY
Common Name:
sip.internal.ad
SAN*:
sip.domain.com
dir11.internal.ad
dir12.internal.ad
webdirGERext.domain.com
meet.domain.com
dialin.domain.com
lyncdiscoverinternal.(alldom
ains)
SIP.alldomains
+ Simple URL
+ Mobility
+ WebService
Office Web Apps
Common Name:
wac01.internal.ad
Datacenter US
Datacenter GERMANY
Common Name:
webdirGERext.domain.com
SAN:
webdirUSext.domain.com
webdirGERext.domain.com
web01ext.domain.com
web02ext.domain.com
*.domain.com
*.domain-a.com
*.domain-b.com
e.g. KEMP GEO LOADMASTER
Deployed in three region, US, GERMANY and SINGAPORE.
DNS Queries will be redirected to any of this GEO LOAD
MASTER. Based on the Clients location, the nearest LYNC
EDGE Server Site will be chosen.
Internally, you have two choises:
1.) user two independen DNS Server
Zones
2.) usea GEO Load Balancer for
your internaldeployment
Common Name:
edgeUSA.internal.ad
SAN:
edgeUSA.internal.ad
edge11.internal.ad
edge12.internal.ad
Common Name:
edgeGER.internal.ad
SAN:
edgeGER.internal.ad
edge21.internal.ad
edge22.internal.ad

13. © 2013 - Thomas Pött, Microsoft MVP LYNC
5 Certificate Template Table
Making it easier for you, I prefilled in the Template with this configuration example:
We have 3 SIP domains in our deployment 1x Enterprise Pool, plus 1x Standard Edition Server in a
branch. I also have 1x Director installed.
5.1 EDGE SERVER
Type Configuration Comment
Common Name sip.domain.com Primary SIP domain
SAN sip.domain.com First SAN entry must repeat the
primary SIP domain
SAN wc.domain.com Web Conferencing only for the named
primary SIP domain needed
SAN xmpp.domain.com XMPP Federation (if installed) of
primary SIP domain
SAN sip.DOMAIN-A.com Second SIP domain
SAN sip.DOMAIN-B.com Third SIP domain
Table 1 Edge Server external Certificate
5.2 REVERSE PROXY SERVER
Type Configuration Comment
Common Name extweb01.domain.com Just a Common Name
SAN extdir01.domain.com External URL of Director Server. Must
be primary SIP domain
SAN extweb01.domain.com External URL of Enterprise Pool Server.
Must be primary SIP domain
SAN extweb02.domain.com External URL of Standard Server. Must
be primary SIP domain
SAN *.DOMAIN-A.com
SAN *.DOMAIN-B.com
Table 2 Reverse Proxy Server external Certificate
5.3 HYBRID CERTIFICATE (SUMMARY)
Type Configuration Comment
Common Name sip.domain.com Primary SIP domain

14. © 2013 - Thomas Pött, Microsoft MVP LYNC
SAN sip.domain.com
SAN wc.domain.com
SAN xmpp.domain.com
SAN sip.DOMAIN-A.com
SAN sip.DOMAIN-B.com
SAN extdir01.domain.com
SAN extweb01.domain.com
SAN extweb02.domain.com
SAN *.DOMAIN-A.com This is the Wildcard part for Revers
Proxy of DOMAIN-A.com
SAN *.DOMAIN-B.com This is the Wildcard part for Revers
Proxy of DOMAIN-B.com
Table 3 Consolidated, public Certificate
6 Certificate Request Generation
How do I request the Wildcard+SAN certificate?
The following demonstration explains hybrid certificate request in Lync. This has to be done on the Edge
Server itself. You have to login to the Edge Server and start the Bootstripper, than you chose the
“Request, Install and Assign Certificates”.
In this example, I’m using three domains:
PRIMAY SIP Domain: cie.acp.de
SECONDARY SIP Domains: domain.com and domain.com

15. © 2013 - Thomas Pött, Microsoft MVP LYNC
Since this will be our Hybrid Certificate, there is still one point we haven’t spoken about. How do we
request this certificate? If you for example initiate the request with DigiCert, you need to buy three (3)
wildcard certificates first, than you process with DigiCert manually via email.
So remember you might take one/ two days longer in placing the order.

16. © 2013 - Thomas Pött, Microsoft MVP LYNC
We need to prepare a CSR file for external, manual requests:

17. © 2013 - Thomas Pött, Microsoft MVP LYNC
The friendly name can is only for better identification of the certificate in the store:

18. © 2013 - Thomas Pött, Microsoft MVP LYNC
The first defined SN'S are provided by Lync automatically:
Next, you need to include the addressed SIP domains configured in Lync Topology builder:
As discussed, here we come to the point, where we need to add additional SAN entries as
explained and defined the table earlier:

19. © 2013 - Thomas Pött, Microsoft MVP LYNC
Verify the correct CN and SAN entries:

20. © 2013 - Thomas Pött, Microsoft MVP LYNC
Finally you defined the Certificate Request. This is your CSR file. Provide this information to
your Certificate supplier.
Note:
Remember, the Certificate File you will receive will NOT contain the PRIVATE KEY. The Private
Key will be generate once you apply this certificate on the Edge Server where you generated
the statement !

21. © 2013 - Thomas Pött, Microsoft MVP LYNC
Only after its process is fully done, you have the Private Key and the Certificate is ready to be
exported and imported on the other servers, e.g. Edge and Reverse Proxy

22. © 2013 - Thomas Pött, Microsoft MVP LYNC
7 Best Practice
Beside the certificate design and planning process, there are some more point to remember.
I have listed all important areas you must consider during your design and planning process.
 Network Interface Cards:
You have to use two NIC, one for internal and one for external communication. The default gateway has
to be set on the external facing NIC, while you must use “persistent static routes” to all you internal
networks. The DNS should be pointing to the internal DNS Server, if you are choosing an external DNS or
a DNS in a DMZ, make you can resolve the internal Lync Server, if you can’t, you need to provide a hosts
file.
 Edge Server and Reverse Proxy combination
As stated earlier, the full feature set in Lync is only available if you make user of Edge Server, Reverse
Proxy and all required external DNS entries (incl SRV Records). If the RevProxy is not deployed, you will
miss the following features, e.g. address book download, location information, device update, Lync Web
App and NON-DOMAIN Client login)
The non-domain client login requires an authenticated access the Certificate Provisioning Service.!
Also the App Store and Mobile Clients can’t login without the publish autodiscovery services.
This is the same with access to Exchange Web Services (EWS).
 Director Server Service
The Director Server is an optional component, responsible for offload user authentication and pool
redirection. IT also provide an additional layer of protection for external client connections.
 Revers Proxy Listener
Keep the Web Listener as limited as possible. Us only one (1) Listener per internal destination server
each. Make sure the Listener can work with the Hybrid Certificate to minimize costs.

23. © 2013 - Thomas Pött, Microsoft MVP LYNC
References:
Request and Configure a Certificate for Your Reverse HTTP Proxy (Technet)
Certificate Summary - Single Consolidated Edge with Private IP Addresses Using NAT (Technet)
Certificate Summary - Single Consolidated Edge with Public IP Addresses (Technet)
Certificate Summary - Scaled Consolidated Edge, DNS Load Balancing with Private IP Addresses Using
NAT (Technet)
Certificate Summary - Scaled Consolidated Edge, DNS Load Balancing with Public IP Addresses (Technet)
Certificate Summary - Scaled Consolidated Edge with Hardware Load Balancers (Technet)