Demystify Lync 2013 Server internal certificate requirements

Demystify Lync 2013 Server internal certificate requirements
© 27.08.2014, Thomas Pött, Microsoft MVP Lync and PLSL 3rd
level
Support certified.
Version 1.7
Introduction............................................................................................................................................. 2
Client requiring an internal certificate ............................................................................................................... 3
Servers requiring an internal certificate............................................................................................................. 4
Service components requiring a certificate................................................................................................... 4
Certificate Authorities ........................................................................................................................................ 4
Components in a certificate .......................................................................................................................... 5
Wildcard certificates...................................................................................................................................... 5
Internal Server Certificate planning ........................................................................................................ 6
Certificate requirements (infrastructure)........................................................................................................... 6
Cryptographic Algorithms and hash .............................................................................................................. 6
Certificate for Internal Servers, planning and design......................................................................................... 7
Open Authentication Protocol....................................................................................................................... 8
Server and service certificate requirements: .............................................................................................. 10
How to request certificates................................................................................................................... 19
Manually with the Request-CsCertificate ps-command................................................................................... 19
Using the Lync 2013 Server Wizard.................................................................................................................. 19
Staging AV and OAuth certificate with automated activation ......................................................................... 20
Requesting the special certificate for OAuth (Open Authentication) .............................................................. 21
Requesting the Server Default Certificate........................................................................................................ 23
Requesting the Web Services internal certificate ....................................................................................... 26
Requesting the Web Services external certificate....................................................................................... 29
Consider Public Certificates for internal Deployment........................................................................... 30
Reference .............................................................................................................................................. 31
The technical level of this document is 400.
This article requires knowledge about certificate authorities, TLS encryption and identity authorization.
Lync relay on several external components, as network or certificate authority, especially the CA is an
important component for TLS encryption. We need to understand how Lync make use of certificates for
authentication, identity authorization and encryption. It also makes differences between Lync service and its
related web service, which are even segregated into internal and external site.
Note:
This document is neither a sizing nor a configuration guide. You should use this document only for your
environment planning’s purposes and security considerations. In lager environments you should spend some
time to evaluate the optimal path of your certificate deployment.

Introduction
Within one of my last blogs I wrote about the external, or Edge server certificate requirements. In this article
mentioned, the Revers Proxy server certificate requirements where discussed too.
For few, especially those who are new to Lync and mostly haven’t have any experiences regarding certificate
deployments, it’s mostly difficult to understand what and moreover, why Lync has those requirements.
Well coming back to the IP communication within the Lync environment. Most and that’s one of the Best
Practices, Lync 2013 is used for internal communication. This communication needs to be secured too. In our
Lync case, we talk about TLS encryption. TLS stands for Transport Layer Security. Meaning, we need to secure
the entire IP traffic, SIP (TLS) and Web (SSL) based. That’s while we call those transmission SIP over TLS and
HTTPS.
Another point where certificates are used, the AV authentication service in Lync, here, based on the assigned
certificate and its attributes, tokens are generated and distributed to the communication partner (client or
application).
We still have the opportunity to change how this communication could behave. The entire SIP traffic can be run
over the IP channel 5060 and the web traffic can run over port 80/8080. But this is only halve of the story.
There is also Server-to-Server communication and this traffic cannot be changed. Therefor Lync need the
certificates at least to authenticate and secure this traffic. And, truly if we are aware of this, why not running
the entire traffic secure. So much to this point of view.
But whatever decision we make, there is, since we understood the need of certificates right now, one part
which always is unencrypted. Within the certificates, a link is provide to the internal or external CRL (Certificate
Revocation List) and that always clear text. (Beside, have a look into a certificate and you will find this link. If
you now use a browser connecting to, you will receive this CRL over port 80.
(Picture: CRL Distribution Point)

Client requiring an internal certificate
Lync clients also make use of certificate, as well Lync Phone Edition. While we are taking here about
the certificates issued by an internal or external certificate authority, those certificate are issued by
Lync server.
There is one issue I quickly highlight here again.
English:
Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?
German:
Lync kann nicht überprüfen, ob der Server für Ihre Anmeldeadresse vertrauenswürdig ist. Trotzdem
verbinden?
What’s happened here is, as said, Lync is really designed to act secure. Therefor if you have different
DNS domains for Lync communication and Active Directory, as also in the server certificate
explanation later in this article, Lync client will not automatically trust the internal Lync Server
Default Certificate. This is because the Lync Server ending part of its FQDN is AD.INT and the user SIP
address end with @sipdom01.com. This both domains are not matching, so Lync issues a warning,
which can safely be ignored or you make this via GPO trusted.
Reference:
http://lyncuc.blogspot.de/2013/06/lync-client-certificate-authentication.html
At the end, this is a normal and expected behaviour where you don’t need to worry or assume you
made a wrong deployment.

Servers requiring an internal certificate
Let’s first have a look into the different server requiring a certificate.
Simply said, all, including the Office Web application server (well if you only configure the WAC for http, is
doesn’t need it).
However, this are:
 Director Server
 Standard Edition Server
 Frontend Server
 Mediation Server
 Persistent Chat Server
 Edge (Internal Interface) Server
 SBA/ SBS
 Gateways
Service components requiring a certificate
On all servers, we have several components running. We can differentiate them into Lync and IIS related
components. All the certificates must be assigned with the Set-CsCertificate command, or with the
Deployment Wizard.
Note:
Never use any other method, e.g. IIS Management console. If you try so, it is unsupported and the certificate
will mostly not being recognized by Lync.
The web component side of Lync is once more divided into two sub categories, the internal web service and the
external web services. This are requirement in Lync for high security purposes. You can simply run the same
certificate on all components, but this is not recommended by Microsoft.
One other type of certificates is for the new Open Authentication protocol, OAuth. OAuth is required to have as
server-to-server communication on behave of a user who initiate a request to other services running on
another server, e.g. the Unified Contact Store (UCS).
Certificate Authorities
As we have understood now, where certificates are placed, we step into the next question: “Where we could
request those?”.
Generally we have only two options, either we operate an internal Certificate Authority (CA) or we make use of
an external, public CA.
Note:
If you assign public certificates, due to the need of requesting the CRL, all server must have http access to the
internet.
Next question could be, if are allowed to mix, meaning of use a hybrid approach. Sure we can. As an common
example, some customer want to make use of their internal CA for all internal services, e.g. Lync and internal
web service, but will assign an external/ public certificate to the external web service of Lync.

If this scenario makes sense or not, is fully up to you.
Even if you ask me personally, I would not do so, simply because of costs and complexity. Other, you need to
request/ renew certificates with your external partner and this is a different business process compared to an
internal setup.
Components in a certificate
Every certificate is subject to different attributes, the most common and important once I have listed and
explained in a rudimentary way.
Subject Name (SN)/ Common Name (CN)::
The SN is the first identity of a certificate for any of its intent purposes and also the core component for all of
its intent purposes. It can be a FQDN or even a users email address.
If a Windows based wizard is used creating a certificate request, the AD objects CN is used to create the SN.
Subject Alternative Name (SAN):
The SAN is identically with the SN, beside it contains additional, alternative SN, which are used for the
certificates intent.
Friendly Name:
A simple ASCII name give the certificate for better identifying and addressing the certificate in e.g. Set-
CsCertificate commands.
Serial Number:
A biunique hex number given by the CA-
Thumbprint:
A hex check sum, which makes the identity of the certificate unique.
Key Usage:
The purpose of this certificate is valid for, e.g. client/ server authentication, encryption or signing.
Wildcard certificates
A wildcard certificate if a certificate which contains a ‘*’. The star symbolize a regular expression generalizing
all charades at this place holder. Meaning, whatever characters are placed they are considered valid.
Example:
https://wildcard.contoso.com and https://website.contoso.com can be both configured with the same and
identical certificate if the Subject Name and the Subject Alternative Name is *.contoso.com
Wildcard certificates can have different forms, e.g.
only SN, SN + repeated SAN, different SN + SAN wildcard or SN + repeated SAN + additional SAN
If the wildcard certificate is mixed with other SAN names, we call this a hybrid certificate.

Internal Server Certificate planning
First some generic words about the Lync specific certificate requirements and afterwards the planning process.
Beside, just be informed, if you are using Load Balancers, as I blog about before (based on the KEMP Best
Practice) you need to consider all the infrastructure logical design too (see 1-amred vs. 2-armed LB
deployment)
Certificate requirements (infrastructure)
The certificate requirements are very clearly defined in Microsoft Technet:
I reflect only certain important requirements here again to make the next section more clear, where we are
designing the certificate and its request.
Mainly and an easy way is, if you are using Microsoft CA, using the Webserver template. It includes all
necessary requirement for the Lync certificates. Which are:
 Server EKU – Server Authorization
 CDP- http access to the CRL distribution point (with in the internal deployment, the ldap base, AD
integrated solution is supported too. But I recommend the http based distribution, so you are able
checking the CRL in support cases more easy.
 Signing algorithm must SHA-1, SHA-2 or SHA-256 with digest size of (224, 256, 384 and 512 bits)
http://go.microsoft.com/fwlink/?LinkId=287002
 Auto-enrolment is supported internally on all DOMAIN JOINT Servers (not Edge).
But it would require, you configure your CA according this requirement.
 Encryption Key of 1024, 2048 and 4096
Do not user 4096 in Lync environment, if you size a huger amount of and concurrently active users, it
has an massive impact on your CPU utilization. (and if so, make use of an ASIC for the IIS service!)
 Default hash signing is RAS, which his sufficient.
Cryptographic Algorithms and hash
Depending with OS is used, where the Lync clients are running on and additionally, which system Lync must
communicate with (e.g. OCS 2007) we need to care internally, as externally about the cryptographic hash, the
algorithm and also with cryptographic hash the CA is using.
Older OS, before server 2012 and Windows 8, can also be signed by a SHA-256 cryptographic hash, even if it’s
not required.
On the external Edge server the issuing CA must also support SHA-256.
Elliptic curve and others
The most secure algorism available for CA’s are supported with Lync 2013. The ECDH_P256, ECDH_P384, and
ECDH_P521 algorithms. Also here, remember the impact you generate on Server and Client loads.

Certificate for Internal Servers, planning and design
We will discuss the planning and requesting process for all internal server, based on Microsoft Technet article:
Warning:
The Technet article will totally differ from the Lync Deployment Wizard. Therefore the here describe
requirements and planning’s are correct and based on the Deployment Wizard.
If you consult the Technet, care if you might use a manual process for certificate request designs.
In a lager Lab environment, this description here is fully tested, validated and in accordance with the Microsoft
supportability guidelines. Which I have to follow exactly as a certified PLSP Partner Support Engineer.
A general design decision I made for myself is, if I deploy a Standard Edition Server, I will us a consolidated
Certificate, but for all other server deployments if have decided to go with individual certificates, for each
component. This makes the supportability simpler and give a better understanding to customers why a special
SAN is used for this particular component.
Remember:
if you are planning a Pool, which requires HLB, you need to enable the “OVERRIDE” internal web service FQDN.
Now is shall be time stepping into the design process.
First plan your entire Lync topology as usual, meaning do not directly care about certificates. You need to
match the customer’s requirement as best as possible. One its done, you have to core infrastructure read,
which will now directly leads you into the certificate designing process.
Please follow this step and sequence quit strick.
1. Design the OAuth path with all involved server and also the future servers you will build. Mainly its
your Office Servers (Exchange, SharePoint and Lync, but also integrated externs platforms e.g. Live or
Google, this comes into place if you design e.g. Social Media interactivities with your Lync
environment)
2. Design than the certificates for the server components.
This mostly involve all Server also, those without the IIS component.
3. Make your decision about the external access and how this impacts the Reverse Proxy solution.
Meaning how the external access enables your users connecting to the RevProxy or the other paths
which are mainly NOT within your AD infrastructure.
Note:
This is required, if you use a private CA, you must be able to deploy the Trusted Root Authority
Certificate to your clients and trusted servers
4. Make the decision if you are going to use a consolidated certificate for internal and external web
services (IIS components in Lync)
a. Planning the external web services certificate (based on your defined SIP Domains and
deployed DNS infrastructure)
b. Planning the internal web services certificate (identically in certain namespaces as the
external naming and also your internal DNS)
Note:
If you have, which is not recommended, neither necessary with Lync 2013, using SSL offloading. Your go back to
step 4 and plan the certificates along with your HLB requirements. If you are going to use a 2-armed solution,
see what impact on your load balancer is, since you enforce the entire IP traffic forth and back through the LB.

As mentioned earlier, I personally recommend you are always separate all certificate as much as possible. You
don’t have any cost impacts, if your have an internal private CA and support is more straight forward as if you
consolidate al SAN into a single one.
Other to this is, you are care about Microsoft’s statement of :”Lync is secure by design”. Which truly I believe
and if so, I care not bypassing security by simply sharing certificates with its private key. Sure the requirements
for the OAuth certificate. See the next section, where I step into the main requirement if you deploy pools
Open Authentication Protocol
All Microsoft newer applications like Office 2013 server, e.g. Lync, Exchange and SharePoint support this actual
protocol.
Reference:
http://tools.ietf.org/html/rfc6749
If you are running a pool, it is required for all pool member server sharing the same certificate. This is due to
the shared usage of the private key used to run across the entire platforms if a user request is made on behave.
During the certificate request, the wizard will remind you and will also set the Export Private Key option
automatically. So if you design those certificate manually, do not forget about this option to be enabled.
Note:
With the Technet article Microsoft states, you can make use of the FE default certificate. But this will require
you share this certificate between all FE’s within your pool. And this is not a valid security design, rather than a
valid supported scenario.
Special configuration for the OAuth protocol you can define with the Set-CsOAuthConfiguration like
setting up special other Kerberos Realms.
You will within the wizard see, you do not need any server FQDN for OAuth certificate. The CN of the
certificate, or the SN is you Default SIP Domain. This means the SN will be your first SAN entry if you have more
than one SIP domains.

Therefore the requirement is:
Certificate Attribute Value
Common Name/ Subject Name Default SIP Domain
SAN Note:
If only a single SIP Domain is used no SAN is needed
SAN Default SIP domain
SAN Any additional SIP domain
If you are aware, you need to add more SIP domains later, you can added them earlier, manually into the
certificate, so you don’t need to reissue a certificate later.
Certificate Common Name is the SIP Domain certificate.

Server and service certificate requirements:
In our examples I’m using the following definition:
Active Directory Domain: AD.INT
First SIP Domain: SIPDOM01.COM
Second SIP Domain: SIPDOM02.DE
I will not discuss the Wildcard certificate option here again, so if you are going to make use of wildcard, simple
keep in mind you should only use “*” for simple URLs.
Standard Server
A Standard server can have two different approaches. One is, if it is a smaller Deployment with single server
only. If this is the case, you can simply use a full consolidated certificate. But I urge you only doing so if this the
case. The consolidated certificate is simple the combination of all tables below, where just the SN must be the
server FQDN.
If you Standard Server is part of an enterprise deployment, e.g. as backup registrar or a single site server,
please start here separating the certificates as mentioned above.
Therefore the requirement are:
Default Certificate
If this server is your auto-logon server, the server where the SIP.<sipdomain> will point too, you must
include the SAN’s too
Common
/Subject Name
SAN Comment Example
Server FQDN All SIP Domains
Server FQDN
You can use this
certificate for OAuth too,
but add the <sip-domain>
FQDN in manually
If it is your server
connection point for SIP
auto-logon add the sip.
<sip-domain> FQDN
SN=STDSRV01.AD.INT
SAN=STDSRV01.AD.INT
(+auto-logon domain)
SAN=SIP.SIPDOM01.COM
SAN=SIP.SIPDOM02.DE
(+ OAuth) not recommended
SAN=SIPDOM01.COM
SAN=SIPDOM02.DE
Web Service Internal
Within a simple deployment you might not have to change the internal web service FQDN.
Common
/Subject Name
SAN Comment Example
Server internal
FQDN
Server FQDN
Web Service
internal FQDN
MEET ULR
DIALIN URL
Mostly the internal
web service FQDN is
not overwritten.
All internal simple
URLs
SN=STDSRV01.AD.INT
SAN=STDSRV01.AD.INT
SAN=MEET.SIPDOM01.COM
SAN=MEET.SIPDOM02.DE

Internal MOBILE
Client URL
ADMIN URL
The admin URL is
optional and not
required.
Make sure one a
single DIALIN URL is in
the certificate
SAN=DIALIN.SIPDOM01.COM
SAN=LyncDiscoverInternal.SIPDOM01.COM
SAN=LyncDiscoverInternal.SIPDOM02.DE
(optional)
SAN=ADMIN.AD.INT
Web Service External
Within a simple deployment you might include the external FQDNs within your internal web service
certificate, meaning, setup a consolidated certificate for both internal and external web services.
Common
/Subject Name
SAN Comment Example
Server internal
FQDN
Server FQDN
Web Service
external FQDN
MEET ULR
DIALIN URL
External MOBILE
Client URL
All external simple URLs
The admin URL is
optional and not
required. (I would not
recommend
administering your Lync
environment from
outsite your
organization)
Make sure only one a
the certificate
SN=STDSRV01.AD.INT
SAN=STDSRV01.AD.INT
SAN=LyncDiscover.SIPDOM01.COM
SAN=LyncDiscover.SIPDOM02.DE
SAN=WEBEXT.SIPDOM01.COM
Director Server
In environments where you have either higher security requirements or more than one pool, it might be
necessary deploying a Director / Pool. A Frontend Pool is also able acting as a Director, as a authentication
proxy redirecting the user to their homed pool.
Default Certificate
This server is your auto-logon server, the server where the SIP.<sipdomain> will point too. A Director
can only authenticate user and redirect all request to the hosting pools, eg. user and web service
requests.
Common
/Subject Name
SAN Comment Example
Director Pool
FQDN
Director Pool FQDN
Server FQDN
All SIP Domains
SN=DIR-POOL01.AD.INT
SAN=DIR-POOL01.AD.INT
SAN=DIR01.AD.INT
SAN=SIP.SIPDOM02.DE

Just remember, if you are using DNS+HLB for your Pool setup, you must always change the internal
web service FQDN.
You can also make use of Wildcard certificates, but it only allowed using the Wildcard option within
the SAN attributes of the certificate. The SN is here also used for server authorization.
Common
/Subject Name
SAN Comment Example
internal POOL
FQDN
Web Service
internal FQDN
Server FQDN
MEET ULR
DIALIN URL
Internal MOBILE
Client URL
ADMIN URL
All internal simple
URLs
The admin URL is
optional and not
required.
Make sure one a
the certificate
SN=DIR-POOL01-WEBINT.AD.INT
SAN=DIR-POOL01-WEBINT.AD.INT
SAN=DIRSRV01.AD.INT (each server)
(optional)
SAN=ADMIN.AD.INT
Option:
use wildcard, e.g.
*.SIPDOM01.COM
*.SIPDOM2.DE
Common
/Subject Name
SAN Comment Example
internal Pool
FQDN
Internal Pool FQDN
Web Service
external FQDN
MEET ULR
DIALIN URL
External MOBILE
Client URL
The admin URL is
optional and not
recommend
environment from
outside your
organization)
the certificate
SN=DIR-POOL01.AD.INT
SAN=WEBEXT- DIR-
POOL01.SIPDOM01.COM
Option:
use wildcard, e.g.
*.SIPDOM01.COM
*.SIPDOM2.DE

Enterprise Server (Frontend)
In this example, I declare the Frontend Pool NOT as a connection point for auto-logon. This means, if
you are using auto-logon, please add the SIP FQDNs as well.
Default Certificate
This server is NOT your auto-logon server, the server where the SIP.<sipdomain> will point too.
(Note: the picture include a SIP entry, because of in the Lab, where the screenshot where taken, no
Director Pool was deployed)
Common
/Subject Name
SAN Comment Example
Frontend Pool
FQDN
Frontend Pool
FQDN
Server FQDN
All SIP Domains
SN=FE-POOL01.AD.INT
SAN=FE-POOL01.AD.INT
SAN=FE01.AD.INT
SAN=SIP.SIPDOM02.DE

Just remember, if you are using DNS+HLB for your Pool setup, you must always change the internal
web service FQDN different from the Pool FQDN.
You can also make use of Wildcard certificates, but it only allowed using the Wildcard option within
the SAN attributes of the certificate.
The SN (Subject Name) in the Internal Web Service Certificate is here also used for server
authorization and validation for Web Ticket processing.
WARNING:
Until today, the Technet documentation/ help file and the Lync WIZARD has a BUG. If you are using
the Lync Wizard and request an Internal Web Service certificate, the wizard sets the SN to the “Web
Service internal FQDN”. If this certificate is used, the Lync Application related to the Web Ticketing
system cannot validate the assigned certificate due to the certificate validation process. An Error 401
unauthorized will be generated each time a Web Ticket is generate.
Common
/Subject Name
SAN Comment Example
internal POOL
FQDN
Web Service
internal FQDN
Server FQDN
MEET ULR
DIALIN URL
Internal MOBILE
Client URL
ADMIN URL
All internal simple
URLs
The admin URL is
optional and not
required.
Make sure one a
the certificate
SN=FE-POOL01.AD.INT
SAN=FE-POOL01-WEBINT.AD.INT
SAN=FE01.AD.INT
(optional)
SAN=ADMIN.AD.INT
Option:
use wildcard, e.g.
*.SIPDOM01.COM
*.SIPDOM2.DE
If you are going to create this certificate, you must either generate this certificate manually or you
request this certificate as “Lync Default” Certificate, set the friendly name to e.g. WebServiceInternal
and ensure the SIP Domain is not included. The Web Service FQDN must be part of the SAN.
Therefore carefully plan this certificate and ensure twice you used the “Lync Default” certificate
request process correctly.

While you assign this certificate, Warning will be raised. This warning must be ignored.

Common
/Subject Name
SAN Comment Example
internal Pool
FQDN
Internal Pool FQDN
Web Service
external FQDN
MEET ULR
DIALIN URL
External MOBILE
Client URL
The admin URL is
optional and not
recommend
environment from
outside your
organization)
the certificate
SN=FE-POOL01.AD.INT
SAN=FE-POOL01.AD.INT
SAN=WEBEXT- FE-
POOL01.SIPDOM01.COM
Option:
use wildcard, e.g.
*.SIPDOM01.COM
*.SIPDOM2.DE

Mediation Server (standalone)
The Mediation server pool, can be isolated from the Frontend server pool. Mostly this is happened, if you have
e.g. Load Balancers in between of your Mediation to Gateway configuration or the Mediation server need to be
placed in another subnet closer to the gateways. This could be happened, say some requirements are defined
for media-bypass.
If you are not separating the Mediation server from the Frontend servers, you do not need to consider this
section of the document.
Common
/Subject Name
SAN Comment Example
internal Pool
FQDN
Internal Pool FQDN
Server FQDN
SN=ME-POOL01.AD.INT
SAN=ME-POOL01.AD.INT
SAN=ME01.AD.INT
Gateways
Depending on who you are deploying the mediation to gateway trunk, either with TLS or TCP, you will require a
certificate.
Common
/Subject Name
SAN Comment Example
internal gateway
FQDN
 Internal gateway
FQDN
SN=GW01.AD.INT
SAN=GW01.AD.INT
SBA/ SBS
A SBA/ SBS meaning is Survivable Branch Appliance/ Server. You are using this component of Lync at branch
site of your Lync environment, where you want to deploy a solution, making voice and other internal service
available even if the connection to central pool is broken, this could be due to network outage.
Therefor you configured in DNS and also in DHCP this segment of your network as a central REGISTRAR, this
requires the SBA/ SBS acting with the SIP auto-logon FQDN too.
Common
/Subject Name
SAN Comment Example
SBA/ SBS FQDN SBA/ SBS FQDN
All SIP Domains
In this case, SIP domain
include only those SIP
domain for auto-logon,
where this registrar is
responsible for.
SN=SBA01.AD.INT
SAN=SBA01.AD.INT
Optional:
SAN=SIP.DIPDOM02.DE
If this domain is configured for
users who are homed with this
SBA

pChat Server
The pChat server has similar requirements as all other components in Lync, beside of they can be configured in
a pool.
Common
/Subject Name
SAN Comment Example
pChat Pool FQDN pChat Pool FQDN
Server FQDN
SN=PC-POOL01.AD.INT
SAN=PC-POOL01.AD.INT
SAN=PC01.AD.INT

How to request certificates
Manually with the Request-CsCertificate ps-command
If you want or you don’t have a Web Enrolment page setup with your CA, you and also write scripts
requesting certificates manually. The command used for doing so is Request-CsCertificate.
You should refer back to the Lync 2013 help file for the entire command reference.
In case I want to provide you with an example of the three commands necessary requesting the
Director Pool certificate, mentioned earlier in this article
Request-CsCertificate -New -Type Default -ComputerFqdn
"DIR01.AD.INT" -CA "CA01.AD.INTyourca" -FriendlyName "DIR POOL
Default" -Template WebServer -DomainName "DIR-POOL01.AD.INT " -
AllSIPDomains
Using the Lync 2013 Server Wizard
The Lync Server Deployment Wizard comes with an excellent tool for requesting and assigning
certificates with in Lync 2013.
As we can see and figure out, a typical Lync Enterprise Pool Server requires in Best-Practice 4 (four)
certificates
Note:
You can optimize the deployment for certificates based on the descriptions give in the earlier
certificate definition/ requirements. But as I mentioned, I would do the individual certificate
deployment because it make the maintenance and support processes easier.
As the upper picture illustrates, those certificate where prior requested with the Wizard.

Staging AV and OAuth certificate with automated activation
AV is the core component in Lync, all feature, like application sharing and audio/ video conferencing
rely on the certificate deployed on A/V Edge service for authentication. Just for support cases, you
will experience Errors logged on Frontend services, if the Edge service is not up and running.
Due to the importance of this service, you can reenrol a certificate earlier then is effective date, with
the –ROLL parameter, you are then enabled to activate those certificates on the –EffectiveDate in
the said command.

Requesting the special certificate for OAuth (Open Authentication)
The picture on the last page also refers to where you start the requesting process for this certificate.
Just also I will have a look into the OAuth certificate:
Next step is the request which was generated with the Wizard based on the servers need:

As visualized here, you will also see additional SubSIPDomains.com. Meaning is, if you have more
than the default SIP domain, the wizard will add those domains into the OAuth certificate.
They are needed to act for User-Server on behalf authentication for services like Exchange IM or
SharePoint integration.
Note:
You will notice, the “Mark the certificate’s private key as exportable” is ticked. The OAuth certificate
on Pool Servers MUST be the SAME on each SERVER

Requesting the Server Default Certificate
Next step, even if this is on top of the wizard, I continued with the Default Certificates. Simply
because I like the ranking ;)
Note:
Please be aware, you need to DESELECT the service for which you will not request the certificate
within this step.
Therefor you only active the Server default certificate option and will start the Wizard by clicking
“Request”. Follow the sequence as you planed and maybe have written down in a table simply as
provided by my article.

Next you will notice a Subject Name/ SAN information page. Here you find the exact must have
definition of the certificate. If will be a little different as described in the Microsoft Technet articles.
But don’t mind, this here is the only correct way as you need to request it.
You need to define all SIP Domains now, which are in used. Meaning for example you would have to
change the Default SIP Domain (which is not supported to be deleted) you could simple not ticking
the check-box for this or other domains and make you certificate smaller through this.

Other required SAN names, even the Wildcard certificate could now be generated with the SAN page
for additional entries. So please also here be aware you could add other Pool Members if you need a
shared certificate between all Pool Servers (and remember, you would have to tick the checkbox for
private key to be exported).
Welcome, you finished your task successfully ;)

Requesting the Web Services internal certificate
Coming now to the Web services certificates, first for the internal ISS web services running on Port
80/ 443. Here you need again said keep in mind you are needing port 80 due to the client (phones)
certificates.
If you are using a 2-armed HLB solution, which also may require a SSL off-load, the “Mark the
certificate’s private key as exportable” must be checked. It than can be used on all Frontend servers.

This might be lager, depending on your topology. As a certificate is limited to 4k bytes for SN and SAN
names. You also seek for consolidation e.g. with wildcard options.

Requesting the Web Services external certificate
Similar with the external web services, you have the same consideration here.
Since the internal and external certificate for web services has certain names overlapping, you are
entitled to combine both certificates into a single one.

Consider Public Certificates for internal Deployment
If you are planning for public certificates within your internal Lync server deployment. There are
several thing you have keep in mind.
First, your internal DNS is related with your Active Directory naming’s. The Lync server require the SN
within its certificates for authorization. Therefore it is necessary that your internal DNS domain can
be validate and confirmed with your public CA provider. This is only possible if you are using an
official DNS name, e.g. company.com, but if you chose, say you decided to go with e.g. company.int
this name is not official recognized and will not be confirmed with your provider. This is also valid if
you are choosing to buy an official CA signing certificate. It will be usable for any other names than
the certificates domain is assigned too.
If you are going without this recommendation, the Lync server certificates are not supported and will
also not work for server authorization.
Note:
Consider your planning’s accordingly with the given requirements and design recommendations. This
will ensure a working and supported Lync environment.

Reference
Microsoft Technet: http://technet.microsoft.com/en-us/library/gg398094.aspx
http://technet.microsoft.com/en-us/library/gg398066.aspx
Lyncuc Blog: http://lyncuc.blogspot.com/2013/06/lync-certificate-planning-and.html

Demystify Lync 2013 Server internal certificate requirements

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Demystify Lync 2013 Server internal certificate requirements

Similar to Demystify Lync 2013 Server internal certificate requirements (20)

More from Thomas Poett

More from Thomas Poett (6)

Recently uploaded

Recently uploaded (20)

Demystify Lync 2013 Server internal certificate requirements