Nearly all communications between Lync clients and the Lync Server web services are maintained over port 443, yet there are a few instances when HTTP traffic over Port 80 is utilized.  Thus depending on the scenario if any traffic over this port is not allowed to or from the server then some functionality may be limited.

Internal Servers

The Ports and Protocols for Internal Servers documentation lists Port 80 as a requirement in two places: Front End Servers and Directors, with a description including when HTTPS is not used. OK, but when is HTTPS not used? And why?

Lync Phone Edition Certificate Download

Traditionally all internal Lync servers would be issued an SSL certificate from a Windows Enterprise Certificate Authority which automatically embedded the root and any issuing subordinate CA certificates into Active Directory.  Thus all domain connected Windows workstations would transitively trust the private certificate authority, and the Lync client running on those computers would be able to connect to the Lync servers over TLS without issue.  In the event that a trusted third party public certificate was issued to the internal Lync servers then the Windows client would typically trust those by default assuming that the CA is one of the pre-installed trusts in the Windows operating system certificate store.

But what about Lync Phone Edition devices?  These are not domain-joined and although they do support a host of pre-installed public certificates which would allow them to connect to Edge or internal servers utilizing public certificates, how do they function in an internal scenario with private certificates?

Since the introduction of the Phone Edition client with the original Tanjay device the client has been able to automatically download the complete root certificate chain directly from a Front-End or Director Server (OCS or Lync).  This download is actually facilitated over HTTP (port 80 by default) as until the root certificate is downloaded the client cannot establish a secure connection over HTTPS (port 443 by default) with the server.

Also be aware that this behavior is not limited to Lync Phone Edition devices are other Lync Qualified devices (e.g. Polycom VVX Phones) can use this same solution to automatically download the CA certificates.

The following network trace shows a Lync Phone Edition device (192.168.1.117) connecting to the Certificate Provisioning service on the Lync Server (192.168.1.23) over port 80 and receiving a response from the server (HTTP/1.1 200 OK) which includes the root certificate data.

If a device which supports PIN Authentication in Lync is unable to connect to the Lync Web Services initially over HTTP to download the certificate then it will not be able to successfully complete the authentication process as TLS communications over HTTPS is unavailable without the certificate trust in place.

• In the event that port 80 is not reachable on the internal Lync Server the Test-CsPhoneBootstrap cmdlet will return the following error message:

TargetUri  : https://lync.schertz.local:443/CertProv/CertProvisioningService.svc
TargetFqdn : lync.schertz.local
Result     : Failure
Latency    : 00:00:01.0291919
Error      : No response received for GetRootCertChains().
Diagnosis  :

• Earlier in the cmdlet output the failure to connect to initially connect to the web services over HTTP is clearly reported.

Connecting to web service : http://lync.schertz.local/CertProv/CertProvisioningService.svc
        Using anonymous authentication
        Successfully created connection proxy and website bindings
        Attempting to download certificate root chain
        request created
        ERROR communicating with GetRootCertChains() service System.ServiceModel.EndpointNotFoundException: Could not connect to http://lync.schertz.local/CertProv/CertProvisioningService.svc/anon. TCP error code 10061: No connection could be made because the target machine actively refused it 192.168.1.23:80.  —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 192.168.1.23:80

This situation is more common with internal firewalls or hardware load balanced scenarios as the Lync Server will allow connections to both ports 80 and 443 by default.  But if any traffic-filtering devices or routing misconfiguration prevent requests over TCP 80 to the server, yet still allow TCP 443, then Windows Lync clients will continue to work fine but Lync Phone Edition devices may not be able to connect, USB tethered or not.

Thus make sure that both port 80 and 443 are reachable on all internal Front end and Director servers from any subnet where Lync clients may reside internally, and also do not forgot to configure any hardware load balancers to handle HTTP requests as well as HTTPS.

Autodiscover

The Lync autodiscover web service first introduced in a cumulative update for Lync 2010, which is now embedded in Lync 2013, can also utilize HTTP.  Previous articles Deploying the Lync 2010 Mobility Service and Lync 2013 Client Autodiscover already discuss this topic in detail, but the key point is that clients which support this service will simultaneously attempt connections to both HTTP/80 and HTTPS/443 to the server name resolved by either lyncdiscoverinternal.<sipdomain> or lyncdiscover.<sipdomain>.  Whichever response is received first is what the client will utilize, but in the event of most internal communications the clients should typically have access to both ports.  Since both ports are assigned to the same web services then if a client does receive answers from both port connection attempt the reply will still contain the same results.  Only the initial Autodiscover request can be handled over HTTP, all other communications afterward are secured over 443.

External Servers

As depicted in the Port Summary documentation for the single Edge and Reverse Proxy server reference architecture Port 80 can be used for two different types of requests, one for outbound traffic from an Edge Server to the Internet and another for inbound requests from clients on the Internet to the Reverse Proxy server.

Edge Server Certificate Revocation Check

The Edge Server’s Access Edge Service will utilize port 80 for outbound requests so that the Edge Server can perform basic certificate revocation checks. This is more of a Windows Server related behavior than the Lync Access Edge service itself, but is important to support TLS communications with other federated partners.  By default the Edge server will periodically query a CA’s Certificate Revocation List (CRL) for certificates presented during Edge to Edge federated communications and will need to make outbound connections over port 80 to download the CRL via HTTP.

Often this is not a port which requires manual configuration on firewalls as it is common practice to allow outbound connections over any port or protocol from a more trusted network (e.g. a Perimeter or DMZ network) to a less trusted network (e.g. the Internet).  In the event that all outbound requests through an external firewall from the Edge Server need to be specifically defined in a policy then Port 80 must be allowed.  Alternatively (although not recommended) this behavior can be disabled on the Edge Server by defining the KeepCrlsUpToDateForPeers parameter with the Set-CsAccessEdgeConfiguration cmdlet.

Reverse Proxy Redirection

This is a completely optional usage of Port 80 designed to allow inbound client requests over HTTP (TCP80), which are then automatically redirected to HTTPS (TCP443) by a Reverse Proxy rule.

Prior to the addition of the Autodiscover service this rule was almost never deployed, but there is one scenario where it can be advantageous.

The client autodiscover behavior is the same regardless of where the client is located, but external autodiscover is typically configured differently.  Where most often internal clients can connect to the autodiscover web service over either 80 or 443 when dealing with externally published web services it is more common (and reflected as best practices in the production documentation) to only allow connections from the Internet over HTTPS/443.

In normal scenarios clients would only receive a response from connections to 443 while connections to 80 would be refused at the reverse proxy.  But by adding this rule and allowing HTTP/80 requests to reach the internal web services then the reverse proxy listener does not need to include the lyncdiscover.<sipdomain> FQDN.  This feature has more importance back when the services was newly added to Lync Server 2010 and provided for simpler (and sometimes even cheaper) deployments of the Mobility service in existing Lync environments.  But for Lync Server 2013 deployments it is recommended to include the lyncdiscover FQDNs (or a Simple URL wildcard entry) in the certificate SAN fields.