As much improved as the certificate request process has been in Lync 2010 Server from previous versions there are still various occasions where using the Lync wizard can prove to be more difficult then it needs to be.  And with the recent release of the new Lync Mobility service and mobile clients there will be a lot of new certificate requests performed in order to add the new Autodiscover name.

For simple requests the preferred approach is still to use the built-in Internet Information Services Manager as documented in this previous article.  But this approach is limited in what options can be modified so when dealing with Subject Alternative Name fields and third-party or offline Certificate Authorities there is an even easier way.

In certain scenarios, like the event that multiple SIP domains are defined in the topology, or when the certificate wizard is just being a general pain to deal with then it can be much less heartache to simply ditch the Lync wizard and request the certificate manually using a handy little free utility provided by DigiCert.  This tool makes it a snap to copy an existing certificate and quickly make a change to either name fields, organization fields, or the key size.  This tool works with any CA, private or public for standard SSL certificates with or without SAN entries.

Be aware that incorrectly populating the name fields on a Lync Server certificate can negatively impact the environment so this process is only intended for experienced administrators who understand which FQDNs are used by what Lync Server role.  The reason that the Lync Certificate Wizard is recommended as it ‘should’ properly populate the required names for the desired server role(s) as well as automatically proceed to assign the certificate to the services.

The Process

The following scenario will walk through the steps of replacing an existing Lync Front End server certificate issued by an internal Windows Enterprise CA for the purposes of adding the two new Mobility Autodiscover FQDNs.

Generate Certificate Request

Download the SSL Certificate Management & Troubleshooting Tool from DigiCert and save it to the Lync Server where the new certificate will be applied.

  • On the Lync Front End server download DigiCertUtil.exe and save the application anywhere on the server.  This package is the actual application and not an installation package so just drop it on the desktop for quick access.
  • Launch DigiCertUtil.exe which will open a single window application that lists the currently installed certificates on the Windows Server which are stored in the computer store’s personal certificates folder.


For comparison’s sake the Certificates management snap-in on the server can be opened and the Personal > Certificates folder in the Local Computer store should show the same certificates lists.  This step can help illustrate exactly what the DigiCert utility it displaying.


  • Back in the DigiCert utility highlight the current Lync Server Front End certificate and then click Create CSR.  Select Yes in the following pop-up window to copy the current attributes from the highlighted certificate.


The Renew Certificate window will appear with all of the configurable parameters prepopulated with the data from the copied certified.


  • At the end of the existing Subject Alternative Name data enter the desired new FQDNs and click Generate.


The generated certificate request will be shown in another new window in which the text hash can be copied or saved to a file.

  • Click Copy CSR to save the text hash to the clipboard.
  • Also click Save to A File and then choose a location and name to save the file for later retrieval in case the clipboard data is accidently overwritten before the submission is completed. (e.g. c:templync_schertz_local.txt)


This step is not required but for inquiring minds it is possible to see the contents of the request in plain text prior to the submission.  This is as another illustration to help understand what the hashed text actually means.

  • Using a web browser go to one of the many CSR and/or Certificate decoder web sites available online (e.g. and paste the text in and decode it.


The decoded hash will be listed in a a readable text format which verifies the attributes selected in the original request and shows the new values in the X509 version 3 SAN field.

Certificate Request:
        Version: 0 (0x0)
            countryName               = US
            stateOrProvinceName       = Illinois
            localityName              = Chicago
            organizationalUnitName    = Home
            organizationName          = Schertz Lab
            commonName                = lync.schertz.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                Exponent: 65537 (0x10001)
        Requested Extensions:
            X509v3 Subject Alternative Name:
      , DNS:lync.schertz.local,,,,,,
    Signature Algorithm: sha1WithRSAEncryption


Submit Certificate Request

Any Certificate Authority can be used to submit the CSR text to, but in this example a Windows Enterprise CA was used for the existing Lync Front End Server certificate and the same CA will be used it issue the new certificate.

  • To submit the request access the certificate request web interface for the desired certificate authority and paste or import the CSR text.  If a certificate template is request choose the Web Server template or whatever template is closest as possible, depending on the specific CA.


  • Download and save the issued certificate in Base 64 format to a local file on the same Lync Front End server (e.g. c:templync_schertz_local.cer)


As before this step is optional; open the .cer file in Notepad and copy the text hash and paste it into the same decoding page used in the previous section to view the decoded hash of the issued certificate file.

Import Certificate

Now that the issued certificate is saved to a file it must be imported into the server using the same method that it was requested so the private key which was generated during the initial request process can be properly attached to the issued certificate file.  It is important is understand that the initial request on the Lync server (using the DigiCert utility) created a unique private key that is temporarily stored on the server which is useless until it can be ‘married’ to the public key which the issuing CA will have created.  The .cer file includes this public key and by importing this file into the proper server it will be able to join the two files together to create a fully functioning X.509 certificate capable of both encrypting and decrypting data.

  • Back in the DigiCert utility click Import on the application’s main window.  In the Import Certificate Wizard window locate the certificate file which was provided by the issuing CA (e.g. lync_schertz_local.cer) and click Next.


  • Click View Certificate and then select the Details tab to verify the Common Name and Subject Alternative Name fields are correctly configured.


Also notice that on the General tab there is no indication that a private key is attached to the certificate, as the bottom section of the window where the private key status is typically displayed is blank.  This is expected as the import has not actually yet been performed which further illustrates that the certificate  file itself is useless until the import process is completed.


  • Close the certificate properties window and then enter a Friendly Name and click Finish in the import wizard.  A message reporting a successful import should be reported along with a reminder to assign the certificate to something.


  • Back at the main window click Refresh (if the window has not already automatically refreshed the contents) and the new certificate should be listed next to the existing certificates.


  • Click View on the new certificate to verify if the private key has been successfully attached to the certificate.  The Test Key button can also be used to test the validity of the new certificate.


Assign Certificate

The final step is to actually assign the new certificate to the Lync Server roles.  Before assigning the certificate it is important to first verify which roles on t he Lync server are using what certificate as various configuration scenarios are supported and there might actually be one or more certificates in use across different usages.  In this scenario all three usages (Default, WebServicesInternal, and WebServicesExternal) are assigned to the same SAN certificate

  • Using the Lync Server Management Shell on the same Lync Front End Server issue the Get-CsCertificate cmdlet to list the current server’s certificate configuration.  Notice that the same exact thumbprint value is listed for all three Use types.

PS C:> Get-CsCertificate

Issuer           : CN=Schertz-RootCA, DC=schertz, DC=local
NotAfter         : 12/9/2013 1:55:18 PM
NotBefore        : 12/10/2011 1:55:18 PM
SerialNumber     : 70F3C28300000000001F
Subject          : CN=lync.schertz.local, OU=Home, O=Schertz Lab, L=Chicago, S=
                   IL, C=US
AlternativeNames : {, lync.schertz.local,, meet
Thumbprint       : 4B15B685EAA2B1610C1F4494AB80D2B7AB37D151
Use              : Default

Issuer           : CN=Schertz-RootCA, DC=schertz, DC=local
NotAfter         : 12/9/2013 1:55:18 PM
NotBefore        : 12/10/2011 1:55:18 PM
SerialNumber     : 70F3C28300000000001F
Subject          : CN=lync.schertz.local, OU=Home, O=Schertz Lab, L=Chicago, S=
                   IL, C=US
AlternativeNames : {, lync.schertz.local,, meet
Thumbprint       : 4B15B685EAA2B1610C1F4494AB80D2B7AB37D151
Use              : WebServicesInternal

Issuer           : CN=Schertz-RootCA, DC=schertz, DC=local
NotAfter         : 12/9/2013 1:55:18 PM
NotBefore        : 12/10/2011 1:55:18 PM
SerialNumber     : 70F3C28300000000001F
Subject          : CN=lync.schertz.local, OU=Home, O=Schertz Lab, L=Chicago, S=
                   IL, C=US
AlternativeNames : {, lync.schertz.local,, meet
Thumbprint       : 4B15B685EAA2B1610C1F4494AB80D2B7AB37D151
Use              : WebServicesExternal

  • To retrieve the Thumbprint value from the new certificate view the Details tab on the properties of the new certificate (either from the DigiCert Utility or the Windows Certificates snap-in).


  • Copy the thumbprint value and use Notepad to remove the spaces; the Replace option with a single space will make short work of this.  Copy the edited string to the clipboard to be used in the next step.


  • From the Lync Server Management Shell on the same Lync Front End Server issue the following Set-CsCertificate cmdlet assign the new certificate to each Lync Front End server usage. (Be careful pasting the thumbprint value into the command shell as formatting characters can sometimes be included, like a leading ‘?’ may appear.)

Set-CsCertificate -Type Default,WebServicesInternal,WebServicesExternal
-Thumbprint 17be10e5911141069d513a552af7d9046764e754

To validate the change issue the following Get-CsCertificate cmdlet to quickly verify that the new thumbprint is listed on each usage.

PS C:> Get-CsCertificate | Select-Object Use,Thumbprint | fl

Use        : Default
Thumbprint : 17BE10E5911141069D513A552AF7D9046764E754

Use        : WebServicesInternal
Thumbprint : 17BE10E5911141069D513A552AF7D9046764E754

Use        : WebServicesExternal
Thumbprint : 17BE10E5911141069D513A552AF7D9046764E754

At minimum a restart of the associated services is recommended, but as is a general best practice anytime a certificate is replaced in the Lync environment a full reboot of the server sooner than later is also recommended for good measure.

Although this process does look like a lot of steps it is actually very simple and when understood it can be performed end-to-end in a matter of minutes if not less than.

Extra Credit

Note: This final section is completed unrelated to the basic certificate request described throughout this article and can be ignored.

A sharp eye might have caught the following warnings shown in the previous DigiCert utility screenshots.  This addresses the other handy part of this tool.


Windows Server will often be incorrectly configured to deal with certain DigiCert certificates; read the Background Information section at the end of this article for a complete description of the issue that this utility fixes.  This a recommended step on any Lync Edge server regardless of what CA was used to issue it’s own certificates as an unrepaired Edge server can experience communications issues with other federated Lync organizations which may be using certain DigiCert certificates.

  • Click the Repair button on the DigiCert utility to display the following configuration window prior to performing the fix on the local Windows Server.


  • Click the Yes, this is a server button to perform the fix.


By Jeff Schertz

Site Administrator

36 thoughts on “Simple Certificate Requests in Lync”
  1. Great article Jeff, easy to read and with a lot of good screenshots!

    Didn't know about those online CSR / Certificate decoders.
    And nice with extra bonus on the DigiCert "issue".

  2. I am having problems with my TMG 2010 reverse proxy deployment in my Lync 2010 environment. When I am accessing my simple URL's externally I received

    "500 Internal Server Error. The target principal name is incorrect"

    I have an internal domain and an external domain, so two(2) SIP domains.


    I have a Standard Edtion deployment with

    1 – Front End Server lync01.exmaple.local

    1 – Edge Server lync02.example.local (doamin suffix)

    1 – Reverse Proxy lync03

    Simple URL's (,

    Web Services (

    My question is this, how should my certificates be setup? Which one need to be pulic signed certificates? (ie. GoDaddy)

    Certificate #1 (Internal) – CN =

    Certificate #1 (Internal) – SAN =

    Certificate #2 (Edge) – CN =

    Certificate #2 (Edge) – SAN =

    Certificate #3 (TMG2010) – CN =

    Certificate #3 (TMG2010) – SAN =


  3. Hi Jeff,

    Phil here from Thanks for a great article. Thought you might be interested to know that besides our CSR & Cert Decoder, we also have an SSL Checker You can use it to carry out several checks on internet facing certificates. It will warn if the hostname doesn't match the CN or a SAN in the cert, check for weak keys, check for weak algorithms, check if trusted or not, etc. It will also fully decode the certificate to show all the details including any SANS.

  4. Hi Jeff,

    I too have a similar setup to "Brad Busch's" comments above and would love some assistance when it comes to public/self signed cert deployment.

    Any help with Brad's question would be much appreciated!



    1. The typical approach is to use private certificates on the internal servers (FE, Director) and public certificates on the Edge external interface(s) and TMG web listeners.

  5. Great article, but am I right that this tool does not allow to request a cert with a client EKU for AOL federation if used for requesting edge certs?

    1. Not that I can tell, to perform a more advanced request it is better to use the Advanced Operations &gt; Create Custom Certificate Request option in the Certificate MMC snap-in in Windows.

      1. Hi Jeff,
        yes, I tried that way also, but sometimes it wouldn't join the private key into the cert, when importing it back on the machine where the request was created (haven't done much troubleshooting on this).
        For me it works best to really run this command on the edge. As far as I know the public certificate issuers don't care about templates as you select the type of cert you want to have beforehand.

        Request-CsCertificate -New -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Output ".Edge Server External Cert Request.req" -ClientEku $true -Template "Web Server with Client EKU" -PrivateKeyExportable $true -friendlyname "Edge Server External Cert" – country “DE” -Organization "Company" -OU "IT" -city “Muenchen” -state “Bavaria”

        Maybe this helps someone out there.

  6. Hi Jeff,
    We presently do not have a Certificate Server in our organisation. I was wondering if I could just add all the names, internal and external, to the public certificate and use this? I believe it should work fine, but are there any hidden problems that you know of or other users have faced?
    Thanks. Regards,

    1. That is possible but some public CAs will not issue certificates containing internal namespaces which cannot be validated, also it's poor practice to advertise your internal namespace in public certificates.

  7. Hmm, headline says "Simple…."
    and then a 50 page long documentation follows.
    I would hate to read through a complex documentation I think.:)

    1. You are correct, it is 'Simple' by comparison. But to be fair it's only 8 page-down keystrokes on a 1920×1200 resolution screen and covers more than one scenario. 🙂

  8. Hi Jeff.

    stubbing at purpose of user’s credential issued by lync server.

    AFAIK, after the root cert chain was downloaded, a TLS based communication between server and client is available to work. Why lync server issue the user credential to client after credentials had been verified?

    I don’t think it is used for caching someting used for signing in, since if I remove it from the store, everything goes ok, no addtional information were required.

    Since the TLS has guarateed the authentication of the client, It might not used for that purpose.

    If that is for authentication of client, will the messages contains user’s certificate be intercepted by other pseudo client?

    Would you pls give some details about this?


  9. i have done my Lync server completely but i have 2 issues,
    in the Lync server control panel(topology) Application server is stop sign.

    When i login to Lync client prompt error message There is a problem verifying certificate from server"

    Please advice. Thank you.


  10. so, it is quite enough to buy ONLY ONE cert with let's say 10 SAN names and assign it to different servers like Edge, Revproxy and for example different IIS for small https website?
    Am I right?

    1. It's possible if the certificate format meets all of the requirements, but it's still a best practice to use certificates dedicated to each server. Also with some CAs it can sometimes be cheaper to get separate certificates then one cert with many SAN entries.

  11. Thanks Jeff! Saved my bacon when our Lync server certs expired. I used the MMC to request new certs, but the certificate replacement steps worked like a charm.

  12. Thanks Jeff for the great article, do you have any blog on renewing these certificates? I didn't see any info on the net on how to renew the cert.

    1. No I do not; that might be a good future topic, although there are probably already a number of other articles out there on other sites covering this.

  13. Jeff. Here's an interesting one. So, the Lync Cert wizard on 2013 capitalizes the "L" in the record CSR/REQ. There is a bug with Comodo that ERRORS out if the CSR that is submitted has any upper case letters in it … so, instead of manually handjamming the cert via powershell – you can use the Lync wizard to generate the CSR – then use this tool (exactly like you illustrated) and 'fix' the upper case letters. Submit the CSR to comodo and they don't choke on it. Thanks for the tip re: this app. Saved me some time!

    1. Thanks for the tip! FQDNs should not be case-sensitive so it sounds like Comodo needs to fix their certificate approval process

  14. Hi Jeff,

    Each time while I use set-cscertificate to assign a certificate, I get the error as below, do you have any ideas?

    Error: An error occurred: “System.InvalidOperationException” “The computer does not need a certificate for the usage type OAuthTokenIssuer. Check the services and components hosted on this computer.”

Leave a Reply

Your email address will not be published. Required fields are marked *