Depending on the form we have selected for the "simple URLs" used to publish Lync Front End web services (see the Infrastructure setup section in Chapter 1, Installing a Lync 2013 Enterprise Pool), the rewrite rules on the reverse proxy will change.

Lync installation creates rewrite rules inside the IIS site in the Front End Servers, so a little bit of testing is strongly advised. We have two sites (something we were able to see during the design of the Lync topology), an internal one and an external one (see the following screenshot):

The external site (that is, the one we will use to point to our reverse proxy) answers by default on two ports, 8080 and 4443. The internal website will be listening on the standard ports, 80 and 443. So, to summarize, we need to configure the rewrite rules so that users coming from the external network will call port 80 and 443 of the published server and be connected through the reverse proxy to the Lync Front End on port 8080 (if we plan to use HTTP) or 4443 (if we plan to use HTTPS).

Last but not least, if we are going to use HTTPS (which is the recommended solution) on the public interface of the reverse proxy, we have to apply an SSL digital certificate (these are small data files that digitally bind a cryptographic key to an organization's details, used to allow secure connections from a web server to a browser). The latter could be a wildcard certificate, because such a solution is supported for the simple URL. As a referral we can use the following TechNet article Wildcard Certificate Support (http://technet.microsoft.com/en-us/library/hh202161.aspx).

The decision is often related to the costs (that is, a wildcard certificate is really cheaper than a multiple SANs certificate).