demystify internal certificates requirements for lync server

31
Demystify Lync 2013 Server internal certificate requirements © 27.08.2014, Thomas Pött, Microsoft MVP Lync and PLSL 3 rd 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.

Upload: thomas-poett

Post on 11-Jan-2015

2.422 views

Category:

Technology


7 download

DESCRIPTION

Understand which types of certificates are required for Lync Server 2013 internal deployment. See how you can manage internal certificate. Learn how to plan and do consulting for Lync related certificates. (17. April 2014, Update to Document Version 1.5) (27. August 2014, Update to Document Version 1.7) - Bug in Lync Certificate Deployment Wizard. Here I described how to work around.

TRANSCRIPT

Page 1: Demystify internal certificates requirements for lync server

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.

Page 2: Demystify internal certificates requirements for lync server

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)

Page 3: Demystify internal certificates requirements for lync server

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.

Page 4: Demystify internal certificates requirements for lync server

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.

Page 5: Demystify internal certificates requirements for lync server

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.

Page 6: Demystify internal certificates requirements for lync server

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.

Page 7: Demystify internal certificates requirements for lync server

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.

Page 8: Demystify internal certificates requirements for lync server

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.

Page 9: Demystify internal certificates requirements for lync server

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.

Page 10: Demystify internal certificates requirements for lync server

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

Page 11: Demystify internal certificates requirements for lync server

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 single DIALIN URL is in the certificate

SN=STDSRV01.AD.INT SAN=STDSRV01.AD.INT SAN=MEET.SIPDOM01.COM SAN=MEET.SIPDOM02.DE SAN=DIALIN.SIPDOM01.COM 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 (+auto-logon domain) SAN=SIP.SIPDOM01.COM SAN=SIP.SIPDOM02.DE

Page 12: Demystify internal certificates requirements for lync server

Web Service Internal

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 single DIALIN URL is in the certificate

SN=DIR-POOL01-WEBINT.AD.INT SAN=DIR-POOL01-WEBINT.AD.INT SAN=DIR-POOL01.AD.INT SAN=DIRSRV01.AD.INT (each server) SAN=MEET.SIPDOM01.COM SAN=MEET.SIPDOM02.DE SAN=DIALIN.SIPDOM01.COM SAN=LyncDiscoverInternal.SIPDOM01.COM SAN=LyncDiscoverInternal.SIPDOM02.DE (optional) SAN=ADMIN.AD.INT

Option: use wildcard, e.g. *.SIPDOM01.COM *.SIPDOM2.DE

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

internal Pool FQDN

Internal Pool 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 outside your organization) Make sure only one a single DIALIN URL is in the certificate

SN=DIR-POOL01.AD.INT SAN=DIR-POOL01.AD.INT SAN=MEET.SIPDOM01.COM SAN=MEET.SIPDOM02.DE SAN=DIALIN.SIPDOM01.COM SAN=LyncDiscover.SIPDOM01.COM SAN=LyncDiscover.SIPDOM02.DE SAN=WEBEXT- DIR-POOL01.SIPDOM01.COM

Option: use wildcard, e.g. *.SIPDOM01.COM *.SIPDOM2.DE

Page 13: Demystify internal certificates requirements for lync server

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

(+auto-logon domain) SAN=SIP.SIPDOM01.COM SAN=SIP.SIPDOM02.DE

Page 14: Demystify internal certificates requirements for lync server

Web Service Internal

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 single DIALIN URL is in the certificate

SN=FE-POOL01.AD.INT SAN=FE-POOL01-WEBINT.AD.INT SAN=FE01.AD.INT SAN=MEET.SIPDOM01.COM SAN=MEET.SIPDOM02.DE SAN=DIALIN.SIPDOM01.COM SAN=LyncDiscoverInternal.SIPDOM01.COM SAN=LyncDiscoverInternal.SIPDOM02.DE (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.

Page 15: Demystify internal certificates requirements for lync server

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

Page 16: Demystify internal certificates requirements for lync server

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

internal Pool FQDN

Internal Pool 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 outside your organization) Make sure only one a single DIALIN URL is in the certificate

SN=FE-POOL01.AD.INT SAN=FE-POOL01.AD.INT SAN=MEET.SIPDOM01.COM SAN=MEET.SIPDOM02.DE SAN=DIALIN.SIPDOM01.COM SAN=LyncDiscover.SIPDOM01.COM SAN=LyncDiscover.SIPDOM02.DE SAN=WEBEXT- FE-POOL01.SIPDOM01.COM

Option: use wildcard, e.g. *.SIPDOM01.COM *.SIPDOM2.DE

Page 17: Demystify internal certificates requirements for lync server

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 SAN=SIP.SIPDOM01.COM

Optional: SAN=SIP.DIPDOM02.DE If this domain is configured for users who are homed with this SBA

Page 18: Demystify internal certificates requirements for lync server

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

Page 19: Demystify internal certificates requirements for lync server

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.INT\yourca" -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.

Page 20: Demystify internal certificates requirements for lync server

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.

Page 21: Demystify internal certificates requirements for lync server

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:

Page 22: Demystify internal certificates requirements for lync server

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

Page 23: Demystify internal certificates requirements for lync 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.

Page 24: Demystify internal certificates requirements for lync server

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.

Page 25: Demystify internal certificates requirements for lync server

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 ;)

Page 26: Demystify internal certificates requirements for lync server

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.

Page 27: Demystify internal certificates requirements for lync server

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.

Page 28: Demystify internal certificates requirements for lync server
Page 29: Demystify internal certificates requirements for lync server

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.

Page 30: Demystify internal certificates requirements for lync server

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.

Page 31: Demystify internal certificates requirements for lync server

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