Certificates
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:
• Internal Edge Service
• Access Edge Service
• Web Conferencing Edge Service
• A/V Edge Authentication Service
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.
• Reverse Proxy—The subject name should match the published name of the external web services. The subject alternative name should contain any simple URLs for dial-in and hosted meetings.
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 27.8 outlines what type of certificate is recommended for each service on an Edge Server.
Table 27.8 External Access Server Certificates
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.