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.
Jeff,
The 1st paragraph on "Edge Server Certificate Revocation Check" ends abruptly ("with other federated partners and")
Regards,
Michel
Thanks Michel, I've finished the paragraph. Guess that is what I get for posting articles on holiday 🙂
command is test-csphonebootstrap not cs-testphonebootstrap
Rgds
Rick
Thanks, typo fixed 🙂
Lync MVP Article Roundup: December 2012…
Lync MVPs are a fountain of deep knowledge on Lync Server. But keeping up with the dozens of great articles…
Will this mean that LPE devices that are being provisioned from external network will also need port 80 opened through the reverse proxy server before they can sign in successfully? The external web services certificate chain and external edge server cert chain is from 3rd party issuer who is not in the phone’s pre-built certificate cache.
No, external devices cannot download a root certificate, this process is only for internal clients. Besides, external clients should already trust the certificate by default as a public 3rd party CA should be used to issue certs to the external services.
HI Jeff,
Thanks for brilliant article.
I am facing the same problem as "No response received for GetRootCertChains(). " for Lync IP Phones HP 4120.
I have Lync Server 2010 implementation. i have checked 80 ports is accessible from client subnet to Lync servers.
I am using F5 HLB for Front-ends. There we have configured it for 80 traffic as well.
We are using only Lycn 2013 clients, and is working fine. I have tried to bypass F5, still faced the same problem.
Any help in this regards please.
Farrukh
Hi Jeff. A question regarding public CRL revocation. Can´t you just have the port 80 open to the internal network for browsing and distribution? The server is not connected to AD so the internal certificate need also CRL list from http. If you can browser both the CRL list ins´t it OK? Or is is the request hard connected to what the network interface can reach?
You can open the port if you like, although a proper reverse proxy would be preferred (and required in the event that the internal namespace is unique).
Jeff, I wanted to ask a question and I think this is the best place to reply. My company has a catchall dns record (ie *.contoso.com). This is causing issues with A/V from both mobile clients and desktop clients when they are external to the infrastructure. I believe the issue is as the client tries to connect to its first dns target (lyncdiscoverinternal.contoso.com) it resolves because of the catchall dns record.
The clients will connect and can IM both internal and external clients, but I have not been able to get the A/V to work and believe the catchall DNS record is the culprit. So, is there a way to get around this?
Thanks.
Thank you Jeff for clarification
Also note that an additional usage of TCP 80 for Lync Phone Edition devices is that internally registered phones will download firmware updates from the Front End servers via an http:// URL. (Externally registered phones will access the packages using a secure https:// URL over TCP 443.)
Isn’t obtaining the trusted root certificate(s) via HTTP a gaping security hole that effectively reduces the trustworthiness of the HTTPS connection to the trustworthiness of the HTTP connection, thus defeating the whole point of even bothering to use HTTPS at all?
What’s to stop a man-in-the-middle from intercepting the HTTP and providing his own root certificate(s), thus allowing him to intercept the HTTPS?
This process is only used on internal, trusted networks and the clients are pointed directly to the server via information provided in Active Directory and/or DHCP. If those sources are compromised then you have much bigger problems then some clients connecting to a spoofed server.
We have replaced our 2k8 PKI infrastructure with 2k12 and are ready to update the internal certificates on all the SfB 2015 servers. We have approx 3500 Polycom CX500 & 600 phones. I am concerned that TLS is going to break for these phones until they somehow acquire the new server root cert chain. The servers currently have both chains in their stores but are still using the older 2k8 internal certs.
How do we get the phones to load the new trust chain ?
The only way to get Lync Phone Edition devices to update the certificate chain is to sign-out and back in to each phone. LPE does not update this information automatically.