Disabling SSL 3.0 in Lync Server 2013 and Skype for Business Server 2015

If you recently tried to check on a certificate on DigiCert – SSL Certificate Checker (https://www.digicert.com/help/), you may have noticed the following warning:

 SSL3-01

DigiCert added this verification due to a vulnerability that was discovered a few days ago. For more information about this vulnerability, check the following articles:

Vulnerability Summary for CVE-2014-3566
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566

This POODLE bites: exploiting the SSL 3.0 fallback
http://googleonlinesecurity.blogspot.co.uk/2014/10/this-poodle-bites-exploiting-ssl-30.html

Microsoft also released a Security Advisory describing how to disable SSL 3.0 on the client and server side:

Microsoft Security Advisory 3009008
Vulnerability in SSL 3.0 Could Allow Information Disclosure
https://technet.microsoft.com/en-us/library/security/3009008.aspx

This Security Advisory mentions that, in order to disable it in the server, you need to add a key to the registry. To make things easier, here is the command to run on Command Prompt:

reg add “HKLMSystemCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server” /v Enabled /t REG_DWORD /d 0 /f

After changing this, a restart to the Lync Services will be enough to apply the new configuration:

Stop-CsWindowsService
Start-CsWindowsService

Note: If you use ARR for publishing Lync External Web Services, you can also disable SSL 3.0 in those servers with the same command and restart IIS (iisreset).

Finally, you can check it again using the DigiCert – SSL Certificate Checker (https://www.digicert.com/help/):

SSL3-02

In case you need to rollback, simply remove the key and restart the Lync Services:

reg delete “HKLMSystemCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server” /v Enabled

Lync Client 2013 Tab Shortcut Keys

Most users already use shortcut keys on daily basic tasks, such as working on documents/spreadsheet, browsing the Internet, etc., and these shortcuts are also heavily used for playing PC games (specially strategy games).

If you want to get familiar with all the available Lync Client 2013 shortcuts, check the following URL:

Keyboard shortcuts for Lync Client 2013
http://office.microsoft.com/en-gb/lync-help/keyboard-shortcuts-for-lync-HA102927994.aspx

In this post, we focus on Tab shortcut keys. In order to use them in Lync, hold Control (Ctrl) + Number (1 to 5) to quickly access a Lync Client Tab:

Ctrl + 1 = Contacts
Ctrl + 2 = Persistent Chat
Ctrl + 3 = Conversations
Ctrl + 4 = Phone
Ctrl + 5 = Meetings – this one is not listed in Keyboard Shortcuts for Lync Client 2013. The Meeting tab was added later on (New Features in Lync 2013 Client with July 2013 Security Update).

Even if we don’t deploy it, Lync Client 2013 allows you to use shortcuts and access the Persistent Chat Tab:

Lync2013Tab-01

There is an error when we try to do a search in Persistent Chat Tab. This is expected, since Persistent Chat is not deployed in this Lync environment:

Lync2013Tab-04

We can also click on the plus button:

Lync2013Tab-02

And access the Chat Room History search:

Lync2013Tab-03

We can also access Phone Tab (Ctrl + 4), which will be empty (this user is not enterprise enabled):

Lync2013Tab-06

And lastly, Meeting Tab (Ctrl + 5) with default information:

Lync2013Tab-07

At the time of this post, the Lync Client version is 15.0.4649.1000.

Lync2013Tab-05

Any Lync Client functionalities and/or features are not affected by this unexpected behaviour. This is something that will probably be patched in a future update.

Lync Server 2013: Event 32169 LS User Services and Event 36870 Schannel

Last Tuesday, a friend called us asking if we could help him check one Lync Environment, because on a Front End server the Lync service wouldn’t start. This particular environment was familiar to us since we were part of the team that deployed it, so we knew it has only two Front End Servers. Even though this topology isn’t recommended by Microsoft, it is supported:

Topologies and components for Front End Servers, instant messaging, and presence in Lync Server 2013
http://technet.microsoft.com/en-gb/library/gg412996.aspx

Additional checks reveal that this Front End with issues was automatically updated (on Windows Server and Lync Server) a month ago, but the issue only started after a reboot.

In the Event Viewer > Applications and Services Logs > Lync Server, we found nothing relevant; only warning messages, and the same message over and over:

LSUS-32169-01

Log Name:      Lync Server
Source:        LS User Services
Date:          07/10/2014 11:39:26
Event ID:      32169
Task Category: LS User Services
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      Joaquina.******
Description: Server startup is being delayed because fabric pool manager is initializing.
Cause: This is normal when Pool is bootstrapped and indicates that the Front-End is waiting for a quorum of other Front-Ends to be started.
Resolution:
If this event recurs persistently, ensure that 85% of the Front-Ends configured for this Pool are up and running. For 2 or 3 machine Pools, initial cold-start of the Pool requires all machines to be started. If multiple Front-Ends have been recently decommissioned, run Reset-CsPoolRegistrarState -ResetType QuorumLossRecovery to enable the Pool to recover from Quorum Loss and make progress.

The Reset-CsPoolRegistrarState cmdlet had already been tried, so we checked the certificates again and everything was OK: Root CA installed, valid certificate, all FQDN’s in the SAN, CRL.

Just when we were ready to give up and renew the certificates, we decided to have a look at the Event Viewer->System and there we found an error message:

LSUS-32169-02

Log Name: System
Source: Schannel
Date: 07/10/2014 11:59:55
Event ID: 36870
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: Joaquina.******
Description:
A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10003.

By checking again the certificates, we noticed that only Local Administrators had permission to access the certificate private Key. This means that the service account couldn’t read/access the Lync Certificate private key. In order to verify Private Key permissions in the certificate, you should open Certificate Console, right click on the certificate, and then select Manage Private Keys:

LSUS-32169-03

LSUS-32169-04

After adding private key permissions to the Network Service on the Lync certificate, we restarted the services and all Lync Front End services started:

LSUS-32169-05

Further checking revealed that the certificate had more permissions (not just the Network Service). Using Lync Deployment Wizard and reassigning the same certificate will give the necessary permissions for Lync Server related objects on that certificate. This is the preferable way to solve this issue, as you can see in the image below:

LSUS-32169-06

The other Front End was also updated and we got a healthy Lync pool again.

We couldn’t figure out why the permissions on the certificate were changed, but if we requested a new certificate it would also solve this issue.

Fun Fact: in the Standard Edition Pool, the warning message is the same:

If this event recurs persistently, ensure that 85% of the Front-Ends configured for this Pool are up and running…

Certificate re-key to change signature algorithm in Lync Server (SHA-1 to SHA-2)

Recently, I received an e-mail from GoDaddy asking to renew older certificates which were signed using SHA-1 algorithm because:

Google® is making a shift in their Chrome™ Web browser to phase out any SSL certificates which use an old encryption algorithm (SHA-1) and expire after Dec. 31, 2015
in Google Chrome phasing out SSL certs using SHA-1

By default, all new or recently renewed certificates should use SHA-2 algorithm:

SHA2-01

Regarding Lync environments, this change will only affect users that use Chrome to access Lync Web Services, such as join/schedule meeting and accessing DialIn conference settings. A good thing is that Lync Server supports both algorithms:

Lync Server 2013

All certificates must be signed using a signing algorithm supported by the operating system. Lync Server 2013 supports the SHA-1 and SHA-2 suite of digest sizes (224, 256, 384 and 512-bit)
in Certificate infrastructure requirements for Lync Server 2013

Lync Server 2010

Lync Server 2010 support includes support for SHA-256 certificates for connections from clients running the Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7 operating systems, in addition to Lync 2010 Phone Edition. To support external access using SHA-256, the external certificate is issued by a public CA using SHA-256.
in Configuring Certificates for Standard Edition Servers
Note: I only found reference to SHA-2 in Lync Server 2010 Standard Edition TechNet.

When the certificate is ready, GoDaddy allows you to download the certificate and the Intermediate CA certificates. The P7B file includes two Intermediate CA certificates:

SHA2-02

This doesn’t mean that Go Daddy Root Certificate Authority – G2 certificate isn’t valid any more, but that GoDaddy is using cross-signed certificates.

SHA2-03

SHA2-04

The difference between these two certification chains is that Go Daddy Class 2 Certification Authority uses SHA-1, while Go Daddy Root Certificate Authority – G2 uses SHA-2. We can check which algorithm was used to sign our certificate in the Certificate->Details tab:

Go Daddy Class 2 Certification Authority

SHA2-04a

Go Daddy Root Certificate Authority – G2

SHA2-03a

We can test this in a Lab environment – the first step is to install the Intermediate Go Daddy Root Certificate Authority – G2 certificate. Then we need to disable the Go Daddy Root Certificate Authority – G2 certificate, select the certificate, and then right click and open Properties:

SHA2-05

In the properties windows, select Disable all purposes for this certificate:

SHA2-06

After disabling the certificate, I recommend to reboot the server.

Finally, to check the chain, open the certificate and then select Certification Path:

SHA2-08

In case you only disabled the Go Daddy Root Certificate Authority – G2 certificate and didn’t install the Intermediate one, you will get a warning:

SHA2-07

For reference, here is the original chain:

SHA2-09

We can also use the DigiCert – SSL Certificate Checker (https://www.digicert.com/help/):

Go Daddy Class 2 Certification Authority as Root CA

SHA2-10

Go Daddy Root Certificate Authority – G2 as Root CA

SHA2-11