Checks to do in the Lync/Skype for Business Server Certificate Store

The checks described in this article are the result of what we normally check during troubleshooting. Some of these already have specific error events, but the objective here is to try to avoid that these events occur.

We plan to keep the post updated and add more checks that we identify as useful. Also, we kindly ask you to add a comment with a test you think that could make a good addition to the list.

Check #1 – Misplaced certificates in Trusted Root CA

Some of us already experienced issues related to having misplaced certificates in Trusted Root CA. In Windows Server 2012, it started to check misplaced certificates and it affected Lync Server 2013:

Lync Server 2013 Front-End service cannot start in Windows Server 2012
https://support.microsoft.com/en-us/kb/2795828

In order to check this, we can use the PowerShell cmdlet mentioned in the above article or this one instead:

Get-Childitem cert:\LocalMachine\root -Recurse | Where-Object {$_.Issuer -ne $_.Subject} | Select Issuer, Subject, Thumbprint | fl

To solve this we need to move the certificate to the proper Store. In this case, we should move it to the Intermediate Certification Authority.

Check #2 – Duplicates in Trusted Root CA

Although this should affect Lync/Skype4B, it is better to check and delete the duplicates:

Get-Childitem cert:\LocalMachine\root | Group-Object -Property Thumbprint | Where-Object {$_.Count -gt 1} | Select-Object -ExpandProperty Group | Select FriendlyName, Issuer, Subject, Thumbprint | fl

Check #3 – More than 100 certificates in Trusted Root CA

This is really important, as it may cause sign-in issues for users. Most of the time, we have less than 50 certificates.

Get-Childitem cert:\LocalMachine\root | Measure

To solve this we have to keep just the certificates that we need. In a Front End, this is actually an easy task, but in a Edge Server we need to be more careful, since the federation with other Lync/Skype4B environments might get broken if we delete the wrong certificate.

Check #4 – Root CA certificates in Personal Store

Just to have things nice and tidy, we should move these certificates to the Trusted Root CA. But before that, it's recommended to check whether they are already there, otherwise we might end up with duplicates.

Get-Childitem cert:\LocalMachine\my -Recurse | Where-Object {$_.Issuer -eq $_.Subject} | Select FriendlyName, Issuer, Subject, Thumbprint | fl

Check #5 – Duplicated Friendly Name

Usually, we add different Friendly Names so it gets easier to assign the certificate. In this case, however, it actually gets to be a requirement:

Note: Each certificate Friendly Name must be unique in the computer store.

Certificate requirements for internal servers in Lync Server 2013
https://technet.microsoft.com/en-us/library/gg398094(v=ocs.15).aspx

Again, a simple PowerShell cmdlet:

Get-Childitem cert:\LocalMachine\my | Group-Object -Property FriendlyName | Where-Object {$_.Count -gt 1} | Select-Object -ExpandProperty Group | Select FriendlyName, Issuer, Subject, Thumbprint | fl

Check #6 – Misplaced Root CA certificates in Intermediate CA store (Suggested in the comments)

Get-ChildItem Cert:\localmachine\CA | Where-Object {$_.Issuer -eq $_.Subject} | Select Issuer, Subject, Thumbprint | fl

Comments

• Anonymous
  June 21, 2015
  You might want to add the ability to clean the intermediate store as well. I have seen people have root certificates in the intermediate certificate store.
  Get-ChildItem Cert:localmachineCA | Where-Object {$.Issuer -eq $.Subject} | Select Issuer, Subject, Thumbprint | fl
• Anonymous
  June 23, 2015
  Thanks, I will add that check too.
• Anonymous
  June 26, 2015
  While troubleshooting the issue described in Checking for "ms-RTC-SIP-TrustedServer" multiple
• Anonymous
  July 21, 2015
  In a previous post, we published the checks/validations that we should do in the Certificate Store in
• Anonymous
  July 23, 2015
  The comment has been removed
• Anonymous
  August 04, 2015
  Thanks for the suggestion. Yes the check #1 doesn't check for certificates pushed by GPO. I will research on that and add it here.