Provisioning certificates for Edge Servers was
another sore subject in prior versions of Lync Server. This has been
greatly simplified by the new certificate wizard, which automatically
populates the required names and attributes based on the published
topology. This section discusses the certificate requirements and
considerations for organizations deciding between public certificates
and privately issued certificates.
An Edge Server requires certificates for four different services:
A common misconception is that all of these
certificates should be purchased from a public certificate authority,
which is only partly true. Only the Access Edge and Web Conferencing
Edge certificates are presented to external clients, so those are the
only services which require a certificate that should be purchased from a
public certificate authority. Both the Edge Server internal certificate
and A/V Edge Authentication Service certificate can be issued from an internal, private certificate authority that is trusted by internal clients.
Note
Probably the most confusing part of previous version
Edge Server deployments was centered around the A/V Edge and A/V
Authentication Edge services. The A/V Edge service actually doesn’t use a
certificate, even though port 443 is involved. The A/V Authentication
service, however, does require a certificate. Because the A/V
Authentication service runs on the internal-facing adapter, this
certificate can actually be issued by a private certificate authority.
This split is a bit more hidden in Lync Server 2010 because the A/V
authentication certificate automatically uses the certificate assigned
to the internal Edge service.
Another common misconception is that subject
alternative name (SAN) certificates are an absolute requirement, but
there are only a few cases where a subject alternative name is required.
First, only the Access Edge certificate needs a subject alternative
name. Every other certificate can use a standard, single name SSL
certificate. Furthermore, a subject alternative name certificate is
required only when an organization is using multiple SIP domains or if
the public name of the Access Edge service does not match the primary
SIP domain.
The specific requirements for subject names and subject alternative names for Edge Servers are outlined in the following:
Access Edge—
The subject name should match the published name of the Access Service
in public DNS. If a hardware load balancer is used, this is the name
clients resolve to the virtual IP address. The subject alternative name
field should contain any supported SIP domains in the sip.<SIP
Domain> format.
Web Conferencing Edge—
The subject name should match the published name of the Web
Conferencing Edge in public DNS. If a hardware load balancer is used,
this is the name clients resolve to the virtual IP address. No subject
alternative names are required.
A/V Edge—
This service has no certificate associated, but is included here to
provide the distinction from the A/V Edge Authentication service.
A/V Edge Authentication—
The subject name has no specific name requirement, but generally
matches the internal Edge Server interface name. No subject alternative
names are required.
Internal Edge—
The subject name should match the published name of the Edge Server
internal pool. If a hardware load balancer is used, this is the name
that resolves to the internal virtual IP address. No subject alternative
names are required.
The last certificate required is not actually bound to the Edge Servers and is required for the reverse proxy.
Tip
Many times, administrators think of subject
alternative names as the “in addition to” field to the certificate
subject name. As a best practice, follow an “either, or” mentality,
meaning clients read either the subject name or the subject alternative
name field, but not both. To accommodate this, always include the
subject name as one of the subject alternative names and usually as the
first entry.
As an example, assume Company ABC deploys a single Edge Server, the only supported SIP domain is companyabc.com, and sip.companyabc.com is the Access Edge Server public name. In this case, only a single name SSL certificate with the subject name sip.companyabc.com
is required for the Access Edge service. Company ABC also needs to
purchase a second single name certificate for the Web Conferencing Edge
service. In this scenario, only two publicly issued certificates are
required: both with only a single name.
If Company ABC also supports another domain such as companyxyz.com, a subject alternative name certificate is required for the Access Edge Service. The subject name would be sip.companyabc.com, and the subject alternative names would be sip.companyabc.com and sip.companyxyz.com.
Company ABC would not need to purchase a second single name certificate
for the Web Conferencing Edge service. In this scenario, only two
publicly issued certificates are required: one with subject alternative
names and one without.
Table 1 outlines what type of certificate is recommended for each service on an Edge Server.
Table 1. External Access Server Certificates
| Service | Certificate Authority | Subject Alternative Names |
|---|
| Access Edge | Public | Additional SIP domains |
| Web Conferencing Edge | Public | No |
| A/V Edge | None | No |
| A/V Edge Authentication | Private | No |
| Internal Edge | Private | No |
| Reverse Proxy | Public | Simple URLs |
When using multiple Edge Servers, the certificates
must be installed on each Edge Server that is being load-balanced
together. Depending on the certificate, vendor certificates can be
licensed for one or more severs, but generally the same public
certificate can be placed on each of the Edge Servers in the pool.
Note
If Public IM Connectivity to AOL is used, the
certificate for the Access Edge Service must have Client Enhanced Key
Usage (EKU) enabled.
Organizations should decide on a certificate vendor
prior to the Lync Server deployment. Microsoft has partnered with a few
certificate vendors to ensure that the X.509 certificates work with Lync
Server. Those vendors are listed here:
Entrust
Comodo
Digicert
GoDaddy
Certificates from other vendors also work if all
clients trust the certificate, but Microsoft has not verified those
vendors. The vendors listed previously have the best compatibility
between different server, desktop, and device platforms.
Tip
Be sure to use the same advice here when planning for
a reverse proxy server and install any internal certificate chains on
the reverse proxy. To complete an SSL bridging scenario, the reverse
proxy needs to trust the certificates presented by the internal pool
member servers.
Using Single Subject Alternative Name Certificates
A newly supported scenario in Lync Server is the
capability to use a single certificate that contains many subject
alternative names. This certificate can then be exported and used on
both Edge Servers and reverse proxy servers. Although this simplifies
the number of certificates required, it might not actually be any less
expensive than using a few single name certificates. This may vary
depending on the number of SIP domains and simple URLs configured. The
advantage to this approach is names for the simple URLs for meetings or
dial-in conferencing can be added to the same certificate and used on
the reverse proxy server.
Following is an example of what a certificate like
this looks like that would then be placed on each Edge Server and
reverse proxy server. Each Edge Server still requires a separate,
internally issued certificate for the internal-facing interface. In this
scenario, a single subject alternative name certificate can be placed
on all Edge Servers and reverse proxy servers.
Subject name: sip.companyabc.com
Subject alternative names: sip.companyabc.com, webconf.companyabc.com, av.companyabc.com, lyncpoolweb.companyabc.com, dialin.companyabc.com, and meet.companyabc.com
Wildcard Certificates
Wildcard certificates in the format of
*.<domain> have become increasingly popular because they provide a
way to secure a large number of websites at a low cost by using only a
single certificate. Unfortunately, many functions in Lync Server simply
don’t work well or at all if a wildcard certificate is used. Even if it
does appear to work for some clients or features, it can produce some
odd behavior which makes troubleshooting very difficult. At this time,
the recommendation is to avoid using a wildcard certificate for any Lync
Server roles.
Caution
Because the reverse proxy functionality is basic, it
is acceptable to use a wildcard certificate for the external web
services or meeting pages. Just avoid using it on an Edge Server.
