Because Office Communications Server 2007 R2 leverages certificates to enforce the strong authentication of servers, it is important for administrators to understand how Office Communications Server uses certificates. Certificates are digital equivalents to a driver’s license or a passport. Their purpose is to authoritatively identify an entity—in this case, a server. Similar to a driver’s license and passport, which identify your height, weight, hair and eye color, and so on, the digital certificate provides specific properties that identify the server.
Every certificate is tied to a public key. Any information encrypted with this public key can be decrypted only by the holder of the corresponding private key. This is a public and private key pair and is unique. If you have a public key, it’s important to know who the holder of the private key is, thus uniquely identifying the certificate owner. To determine whether I hold the private key, you generate a random piece of information that only you know (that is, the secret), encrypt it with the public key, and send it to me. If I am able to send back the plain text (that is, the secret) by decrypting the message you sent, you know that I hold the private key to the certificate.
Knowing that I hold the private key proves only that much: that I hold the private key to the certificate. The certificate could claim that I am Kim Akers, in the same way that a fake driver’s license could identify me as Kim Akers. How then do you determine whether the information contained in the certificate can be trusted? Because you cannot trust me to tell the truth, you must find a more reliable source to validate that the information contained in the certificate is legal. In the case of a U.S. driver’s license or passport, this source of authority is the government of the United States. In the case of digital certificates, the federal government is not in the business of issuing certificates to private businesses and citizens. So you must rely on a trusted public CA—such as VeriSign or eTrust—to issue certificates that other organizations are likely to trust. Certificates for Edge Servers must be requested and issued from public CAs. To reduce costs, certificates for internal Office Communications Servers that interact only with other servers and clients within your organizations can be issued from a private CA trusted within your organization.
Understanding how Office Communications Server uses the different properties of a certificate goes a long way toward helping you avoid pitfalls in configuring your servers. For more information about certificates, see the TechNet article "Certificates" at http://go.microsoft.com/fwlink/?LinkID=133667.
The CN of a certificate, also known as the subject name (SN) in the case of an Office Communications Server, identifies the server’s FQDN, as defined in Active Directory. In the case of a front-end server member of an Enterprise pool, the CN must match the pool’s FQDN. For a Standard Edition Server, the CN should match the computer’s FQDN. You can find the CN of a certificate in the Subject field (on the Details tab) when viewing the properties of a certificate, as shown in Figure 4-18.
Although an organization’s internal DNS service is considered to be trustworthy, it is possible for a rogue server to do DNS cache poisoning and take over another server’s FQDN. To prevent such possible attacks, the CN is used to authoritatively tie Office Communications Server to its FQDN. Office Communications Servers locate other Office Communications Servers through their FQDNs. After resolving the FQDN to an IP address, they validate that the server they reached is not a rogue server by verifying that the CN of the server’s certificate lists the right FQDN. This enables any connecting server to authenticate the Office Communications Server. To verify that the server is an authorized Office Communications Server within your organization, the connecting server checks that the server’s FQDN is listed on the Trusted Server list in Active Directory.
The Subject Alternative Name (SAN) can be used to expose multiple SIP domains. An organization can have multiple SIP domains that it wants to publish to the public (that is, the Internet). Each SIP domain can represent a different business unit’s brand of the organization. For example, the company Litware, Inc. has three brands: Datum, Fabrikam, and Litwareinc. It would be confusing for customers, partners, and vendors who are unaware of this brand’s parent structure to reach Datum employees with a SIP URI of [email protected]. It would be more intuitive for those employees to have a SIP URI of [email protected]. Such an organization can expose multiple SIP domains to the Internet.
The certificate of an Access Edge Server can certify multiple SIP domains by placing additional SIP domains in the SAN field. If a SAN field is present, the SAN should contain the CN of the certificate (that is, the FQDN of the Access Edge Server or the FQDN of the HLB in the case of a bank of Access Edge Servers) as the first entry in the SAN to bind the original name into the SAN, followed by the complete list of SIP domains for which your organization is authoritative. The use of SAN allows a single Access Edge Server to be authoritative for multiple SIP domains. Without this approach, you could expose only one SIP domain per Access Edge Server. This limitation would require deploying multiple Access Edge Servers when an organization needs to expose multiple SIP domains, as in the case of Litware, Inc. Figure 4-19 illustrates an example of a certificate with a populated SAN.
Using a SAN can also be beneficial for your internal deployment of Office Communications Server, particularly when you do not want to deploy a Director. If the DNS Service Record Locator (SRV) record for Litware Inc., _sipinternaltls._tcp.Litwareinc.com, points to the A record, sip.Litwareinc.com, and if every home server’s certificate contains sip.Litwareinc.com in the SAN field, then clients configured for automatic configuration will successfully authenticate these home servers. Because the A record, sip.Litwareinc.com, matches the server’s certificate SAN field, users are able to sign in.
The certificate distribution point (CDP) is a field used to publish the distribution point or points from where you can download certificate revocation lists (CRLs). The CRL is used to verify that the certificate has not been revoked since the time it was issued. You can download CRLs through a variety of methods indicated in the CDP. The most common CDPs are Hypertext Transfer Protocol (HTTP) and Lightweight Directory Access Protocol (LDAP) URLs. Edge Servers should be configured to download CRLs. Figure 4-20 illustrates an example of a CDP.
The Enhanced Key Usage (EKU) field identifies the intended purpose of the certificate. If no EKU field is present in the certificate, the certificate is valid for all uses; however, the intended purpose of the certificate can be limited based on the EKU listed in the certificate of the CA’s part of the certificate path. (Not having an EKU provides no limitations.) The EKU restrictions are inherited from the issuing parent CAs.
The two EKUs that Office Communications Server uses are:
Server Authentication
Client Authentication
Figure 4-21 illustrates these two EKUs.
This EKU must be present to grant the certificate the right to act as a server. This EKU is required for the host to be treated as a server when using MTLS.
This EKU must be present to initiate outbound MTLS connections with the following server types:
Live Communications Server 2003
Live Communications Server 2005
Public IM Connectivity (PIC) to AOL
Office Communications Server 2007 R2 removes the need for servers to have a client EKU when initiating outbound MTLS connections. However, AOL still requires this client EKU to be present in the certificate used by the Access Edge Server connecting to AOL through PIC.
The certificate must be issued from a CA that your organization trusts. The CA represents the reliable source that can vouch for the trustworthiness of the certificate. To view the certificate chain leading to its root certificate, select the Certification Path tab when viewing the certificate, as illustrated in Figure 4-22. If the root certificate or any of its subordinate certificates are not trusted or have been revoked, the certificate will not be trusted. This is especially useful when validating properties of the issuing CAs to make sure that EKU usage rights of interest have been inherited, as well as granted locally.
