Microsoft Lync Server 2013 – Consolidated Edge Audio Issue

I was assisting a customer with the renewal of a Consolidated Edge external SSL certificate recently and upon applying the newly issued certificate to the server, audio calls with externally situated users or federated partners via the Consolidated Edge failed. Upon answering an audio call via the Lync Client, it immediately reported “Called Ended” and third party IP handsets would become stuck in a “Connecting” state once the call was answered by the remote party. While the latter error would have suggested perhaps an audio/video port issue at a firewall level, I was on the phone to the customer via a federated call when the certificate was assigned to the Consolidated Edge services, which in turn immediately caused the call to drop and as such I knew a firewall issue was not the root cause of this problem. On inspection of the Consolidated Edge servers event log, everything appeared to fine and all Consolidated Edge specific services were started, additionally all other functionality such as remote and federated instant messages were working as expected. However, upon a restart of the Consolidated Edge services the following event was logged:

The Access Edge Server failed to import a shared session key due to invalid signature.

In the past 1 minutes, the server rejected 1 shared session keys presented from the network due to an invalid signature. This suggests an incorrect certificate configuration. A large number of failures could indicate spoofed session key data sent by an attacker.

Cause: This is most likely to be a configuration problem in a server array.

Resolution: Ensure that all servers in an Access Edge Server Array have the same certificate configured for the external IP address on the Edge Interfaces tab. Inspect the serial number of each certificate. If the problem persists, use the Administrator Log to help identify the source of these messages.

Upon reading the error this immediately prompted me to inspect the certificate via the certificates MMC snap-in and upon reviewing the new SSL certificate everything appeared to be correct, the certificate chain was reporting as valid as was the private key. In this customers case a GoDaddy SSL certificate had been procured and while the certificate chain stated the implemented certificate was trusted, it transpired an intermediate GoDaddy certificate was missing. On adding the missing intermediate certificate into the Local Computer certificate store, which was also included in the downloaded certificates .zip file, the audio calling issue was resolved. In summary, always check intermediate SSL certificates for your chosen provider, specifically if you are not utilising one of the bigger SSL vendors such as VeriSign or Digicert. Hope this helps!

Microsoft Exchange 2010 – SSL Certificates

I recently installed my first third party certificate into an Microsoft Exchange 2010 environment. This process is almost identical to how it is performed in Exchange 2007, however the PowerShell commands differ very slightly. Microsoft Exchange 2010 does actually support certificate requests and installations directly through the Exchange Management Console, however I’m not much of a fan of this, it has a slightly clunky feeling to it much like the Small Business Server 2008 implementation of wizard driven certifcate requests and installations.

For this certificate installation I was using a Go Daddy UCC 5 Domain certificate, which is more than adequate for Exchange 2010. You may see Exchange certificates branded as UCC (Unified Communications) or SAN (Subject Alternative Name), these are essentially the same, just different vendors choose to brand them differently. As a rule of thumb, always go for at least a five domain Unified Communications certificate otherwise you will find yourself in a pickle when it comes to adding subject alternative names. The following section of this post details the steps required to generate your CSR and install your certificate into your Exchange 2010 environment.

1. The first step of this process is to generate the CSR that will be used to tell your SSL vendor all about your environment. To make life a little easier, DigiCert have created a web based tool that will compile the required CSR PowerShell command for you, which you can find here

Hopefully once you have filled out the required fields in the DigiCert tool, you should have something very similar to the below screenshot. Please pay attention to the Subject Alternative Names used and the order that they have been entered in.

DigiCert CSR 300x159 Microsoft Exchange 2010   SSL Certificates

Please note that where contoso.com is your public domain name, and where contoso.local is your local domain name. Mail.contoso.com would the public DNS A record that is pointed to your internet endpoint, for example the global IP address of your router or firewall.

2. Once you have filled out of the required fields, click the generate button and then copy the generated PowerShell command to your clipboard. Open the Exchange Management Shell (EMS) on your Exchange 2010 server and paste the copied PowerShell command into the EMS and press return. Once this has completed, navigate to the C:\ drive on your server and open the generated .csr file in notepad. The content of this notepad file is the information you need to submit to your SSL vendor when they request CSR information.

3. When your certificate has been generated, download it from your SSL vendors website onto the root of the Exchange 2010 servers C:\drive. Once this has been performed, we need to action a PowerShell command to both import the new certificate and append this certificate to all Exchange 2010 services.  The PowerShell command you need to run is the following:

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path c:\your_certificate.cer -Encoding byte -ReadCount 0)) | Enable-ExchangeCertificate -Services IIS,POP,IMAP,SMTP

In the above command, please edit the -Path attribute to read the file location of where you have stored your downloaded certificate.

4. To verify the certificate installation, browse to Outlook Web Access from an external source, so for example to https://mail.mydomain.com/owa and ensure that the correct certificate is being utilised by clicking the padlock icon in Internet Explorer or your preferred browser.