With the introduction of new clients and services throughout Office 365, Lync Server 2013, and Office Web App Server there is now an even higher level of security enforced in relation to using SSL certificates.  In the past Office Communicator and Lync clients would not require availability of revocation status for a certificate that was presented during authentication or TLS connections with any servers.  But this has changed for some scenarios in Lync 2013 and it would be good guess that more clients will start enforcing this practice in future versions.

Currently the Windows Store App (aka RT or MX client) for Lync 2013 requires the ability to locate and access the Certificate Revocation List (CRL) for the Certificate Authority (CA) which issued the server certificate to the Lync server that it attempts to sign-in to.  If the client is unable to validate that the certificate issued to the authenticating server has not been revoked then the RT client will display a generic error that it is unable to contact the server.  Additionally if the standard Windows Lync 2013 client is installed on a workstation which is not a member of the same Windows domain as the Office Web App server then it will be unable to participate in PowerPoint sharing sessions.

This behavior was first reported by colleague Adam Jacobs in his article entitled Lync Online ADFS Sign-in Issues (server is unavailable) for non-domain joined client PCs and a Windows CA when initially testing connectivity leveraging Active Directory Federation Services utilized by Office 365.  Another article on TechNet discusses how to resolve the same issue related to Office Web App server connectivity.

Background

Before going into further details about the root cause and resolutions it is important to understand what a Certificate Revocation List is and what purpose it serves.

The CRL is not a new concept, but it may be new to many Lync administrators as with anything else in the product from a security standpoint, if it was not enforced or required before then no one really needed to learn about it.  But just as understanding the basic concept of SSL certificates became a necessity when Office Communications Server started using TLS for nearly all communications, security enhancements in Lync 2013 are doing this again for additional certificate capabilities.

Basically the CRL is exactly what is sounds like, a list of revoked certificates.  Note that this is different than certificate expiration which is self-enforced.  Since the beginning OCS and Lync has adhered to the expiration of a server certificate and when that date and time is reached services can stop running and clients will stop allowing connections to servers presenting an expired certificate.  But in the event that the certificate issued to the server was previously revoked by the CA that may have not prevented anything from working normally as that data was not leveraged.

In practice most administrators probably do not take the time to actually go back to a CA and revoke certificates, but it would be a good practice to start now.  For example in a deployment it might take two or three attempts at get a certificate formatted with all the names needed for an environment as it is not uncommon to spend some time running through different certificate requests until the proper one is found.  All of the previous certificates issued to that server are still valid even if they are not being used, so it would be recommended to go to the Certificate Authority and revoke the unused certificates.

This concept has a bigger impact on internal communications for reasons which will be explained later on, as public certificates issued by trusted third-party CAs all provide access to their CRLs by default.

Configuration

An SSL certificate includes a standard extension entitled CRL Distribution Points (CDP) that includes paths which clients can use to locate the CRL.  By default a Windows CA only provides an LDP URL to access this data, as shown in the following screenshot.

Another important parameter is the Authority Information Access (AIA) field which indicates how to access information like policy data or validation services related to the issuing CA.  The location of CRLs is specifically provided by the CDP mentioned above, but it is important that access to both services be made available.

Now an internal, domain-connected Windows workstation would be able to access these locations via LDAP, but what about non-domain connected workstations or external clients?  If those clients do not need to access CRL information, as was true in the past, then there is no problem.  But clearly now that some clients do need to locate the CRL then this is a problem.

The first issue is that LDAP access is not sufficient for provide connectivity for these other client scenarios, so a better form of access is needed.

• This article on NextHop by Rick Kingslan shows to modify the configuration on a Windows CA to add HTTP URLs to these parameters to start providing accessible paths to clients which are passed certificates issued by that CA.

But simply making these changes to the CA configuration is not enough, as that will only impact new certificate requests.  The CA cannot automatically update the configuration of any previously issued certificates, so the next step is to reissue new certificates for all the internal servers and replace the old certificates.

• After applying the configuration changes in Adam’s article to a Windows CA any newly issued certificates would now include an additional HTTP path to locate the CRL, as shown below.

• To view the CRL itself simply connect to the published URL using a web browser and then download the CRL file when prompted.

• Open the downloaded file in Windows and then navigate to the Revocation List tab to see any certificates which have been revoked by the CA.

To view the same information provided by a public CA simply locate the published CDP in any certificate issued by that CA and access the HTTP URL in a browser to download the associated CRL file.

• For example here is the published HTTP CDP for a GoDaddy certificate.

• The Revocation List on this CRL contains much more data than the earlier Windows CA example, literally thousands of entries identifiable only by their unique serial number.

Behavior in Lync 2013

This information above is exactly what the Lync 2013 RT client needs access to before it can successfully sign-in to a Lync Server.

The problem stems from the common use of a Windows Enterprise CA for issuing SSL certificates to all internal servers (e.g. Lync, Exchange, Office Web App).  As seen here the Windows CA does not include the necessary HTTP path by default and thus should be added manually prior to issuing SSL certificates to the Lync server components.  Additionally this also reduces the effectiveness of using a private internal certificate on an Edge server for testing as has been done in the past.  It is not enough to simply import the root CA certificate (and issuing CA certificate is applicable) into the client workstation to test Edge connectivity with the RT app as now the CRL would also need to be made available.  But if an internal certificate leverages internal namespaces then it may not technically be possible to publish the advertised HTTP URL anyways.

Thus when dealing with public certificates on Internet facing services like Edge and Reverse Proxy solutions there should be no problems getting these clients to connect, so these behavioral changes will really only impact internal connectivity.

So in summary it should now be considered a best practice to perform this additional CA configuration prior to deploying Lync Server to insure that clients can access CRL information from any location in which they may attempt signing in from.  In general it would have always been a recommended practice to provide access to certificate revocation information, but it was not a necessity in OCS or Lync.  In order to support the Windows RT client at minimum this configuration is no longer optional.