Just to set a precedence up front I want to make it clear that I’m still completely against using wildcard certificates in any Lync deployments. Wildcard Certificate entries were never supported in OCS and clearly did not function. A quick search online of the terms ‘wildcard’ and ‘Exchange’’ will produce mountains of article and forum discussions on what pitfalls can be seen in Unified Messaging scenarios as well.
So now with Lync Server Microsoft does support the use of wildcard entries in certificates, but in limited use and only when configured in certain ways. On the surface the only mention of this huge shift in support policy within the official Lync TechNet documentation is a single statement on the Certificate Requirements for External Access page. It states that “you can use a wildcard certificate on the Edge internal”. Not a lot of detail there.
Lync Behavior
Before diving into wildcards it is appropriate to highlight some of the behavior of Lync Server and how some of the past pitfalls of OCS certificate configuration can be avoided simply by using the Lync wizards.
When using either the Lync Certificate Wizard or the Request-CsCertificate cmdlet Lync will automatically add additional entries to prevent creating improper certificates. (As the Certificate Wizard GUI simply executes cmdlets the behavior and results are the same regardless of which process is used.)
Throughout this article the proper term of Common Name (CN) is used to refer to what most people mistakenly call the Subject Name (SN). Technically the Subject Name in a certificate is the entire distinguished name (e.g. CN=”Common Name”,O=Organization,L=Location,S=State,C=Country) while the Common Name is only the first entry in the entire path and is a single FQDN.
§ When the Default Type is included in the request then the server/pool FQDN is automatically used as the Common Name. If any Subject Alternative Name (SAN Certificate) entries are defined then Lync automatically adds the certificate’s Common Name to the SAN field as well. This is similar to what the OCS certificate wizard did to resolve issues in some environments where systems could potentially ignore the SN field and only reads the SAN field.
§ When the WebServicesInternal Type is defined in the request then Lync automatically adds the Simple URLs to the SAN which were previously defined using the Topology Builder. Once again, because a SAN entry exists Lync will automatically duplicate the CN as another SAN entry. Notice that the admin URL is included to provide administrators easy access to the Lync Server Control Panel (LSCP) from internal hosts.
§ When the WebServicesExternal Type is defined then Lync automatically adds the external Simple URLS to the SAN which still include the same meet and dialin entries, in addition to the Reverse Proxy URL (external.mslync.net in this example). Additionally notice that the admin URL is omitted as one would never want to publish external access to the LSCP.
§ As an example here is what a basic server/pool certificate would look like as typically all three types (Default,WebServiceInternal, WebServciesExternal) would be assigned to the same certificate. The Lync Standard Edition Server FQDN is the CN and also duplicated in the SAN, while all Simple URLs are included in the SAN as well as thesip entry used for client Automatic Configuration.
Wildcard Support
It is pretty clear that Lync does everything it can to make sure the server/pool FQDN is populated in the proper fields. The following configuration requirements related to the use of wildcard certificates outline the importance of that behavior:
§ The Lync server/pool FQDN must be configured as the Common Name of the certificate.
§ The Lync server/pool FQDN must be populated as an additional SAN entry (when a SAN field is present). If no SAN is needed on the specific certificate then there is no requirement to create a SAN just to repeat the CN again.
§ Wildcard entries are not supported as the Common Name entry of a RapidSSL Wildcard.
§ Wildcards entries are supported only as a SAN entry, but only when the SAN field also includes the CN as well. (Sound familiar?)
After additional research and discussions with product and support personnel within Microsoft I have complied a list of various limitations and caveats. As the information came from multiple sources there will be some contradiction even within these items, so let us see what happens when a wildcard certificate steps up to the plate.
§ A wildcard entry can be used in the Subject Alternative Name (SAN) field on a certificate assigned to internal or external web services on Front-End, Director or Reverse Proxy for Simple URLs. Thus a single entry of *.contoso.com will cover the various Lync Web Services URLs like meet.contoso.com, dialin.contoso.com, etc. Now typically there are only four of these web service URLS and most third-party certificates authorities bundle the first few SAN entries into the price of a SAN/UCC certificate (usually between 4 and 10 entries) before adding additional cost per entry. And for certificates issued by internal Windows Enterprise CAs for internal Lync servers there is no cost associated with these. So this flexibility has limited real-world value for internal servers, but it can reduce the cost of certificates placed on reverse proxy servers to publish the various external Simple URLs.
§ A wildcard entry can be used as the Common Name for a certificate assigned to a Lync Front-End Server/Pool. But although this works in a pure Lync Server 2010 environment, since LCS/OCS does not support wildcards then any interop scenarios would not be supported.
Strike 1.
§ A wildcard entry can also technically be used on the external Edge certificate(s), but again only in a native Lync environment and until everyone else in the world migrates from LCS/OCS to Lync then the external interop scenarios like Federation are severely crippled.
Strike 2.
§ A wildcard entry can be used on the internal Edge certificates (noted in the TechNet article link above) but this really has very limited value as the internal Edge certificate should only include the Edge server’s FQDN and also is typically issued by an internal Windows Enterprise CA. So not only is there no SAN field used or required, even if there were (for load-balanced Edge arrays for example) then there is no cost associated with just adding the additional SAN entries one-by-one. Foul-tip, still Strike 2.
§ Wildcard Certificate entries are not supported by Lync Phone Edition clients. (More details in this blog article.) This means that in most environments additional SAN entries will be required to provide the exact FQDN used by Automatic Configuration DNS records. Only in a single-domain namespace deployment where the AD domain used on the Lync Server/Pool FQDN is the same as the SIP domain would Lync Phone Edition clients be able to sign-in. This scenario would allow the SRV records to point directly to the pool FQDN which matches the Common Name entry. Remember that the SRV record created in the SIP domain must point to a Host record in the same domain, it cannot point to a Host record in a different domain. Strike 3. You’re Out!
Summary
Now clearly there will be times when a wildcard certificate will be very attractive in terms of cost-savings but this really only applies to large organizations or hosting environments which may have tens to hundreds of domain names to support. But since wildcard SSL Certificate entries are not supported on the external Edge interfaces then there is very limited added-value to even attempting to go that route. As no-cost private certificates are used for internal services then there really is no compelling argument for using wildcard entries.
Overall it is great that wildcard certificate support is available in now Lync 2010, but the truth is that it will be many years before organizations can realistically take advantage of the simplified deployment and cost benefits due to massive interoperability.
Posts
