Internal Certificate Deployment in Lync 2013 - How to and planning

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

. 2

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.
Script for internal certificate request and assignment: Certificate requirements for internal servers

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 behavior 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 strict.

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 Internal MOBILE Client URL ADMIN URL	Mostly the internal web service FQDN is not overwritten. All internal simple URLs The admin URL is optional and not required. Make sure 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=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

 

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.AD.INT SAN=DIR-POOL01.AD.INT SAN=DIR-POOL01-WEBINT.AD.INT SAN=DIR-SERVER01.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

 

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

 

 

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

 

 

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.AD.INT SAN=FE-POOL01-WEBINT.AD.INT SAN=FE-SERVER01.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.

 

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

   

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

 

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

 

 

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.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.

 

 

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.

 

 

 

Now you need to assign the certificate:

 

 

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

 

 

Author: Thomas Poett MVP, Managing Consultant Microsoft Unified Communication