Certificate Infrastructure
Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Office Communications Server 2007 now requires a public key infrastructure to support TLS and MTLS connections. Office Communications Server uses certificates for the following purposes:
TLS connections between client and server
MTLS connections between servers
Federation using automatic DNS discovery of partners
Remote user access for instant messaging
External user access to A/V sessions and Web conferencing
For Office Communications Server 2007, the following common requirements apply:
All server certificates must support server authorization (Server EKU).
All server certificates must contain a CRL Distribution Point (CDP).
Auto-enrollment is supported for internal Office Communications Server servers, including an array of Standard Edition Servers configured as Director.
Auto-enrollment is not supported for Office Communications Server edge servers.
Certificate Requirements for Internal Servers
Internal Communications Servers include Standard Edition Server, Enterprise Edition Front End Server, Web Conferencing Server, A/V Conferencing Server, Director, and Web components. The following table shows high-level certificate requirements for internal Office Communications Server servers. For edge servers certificate requirements, see Certificate Requirements for Edge Servers. Although an internal Enterprise CA is recommended for internal servers, you may also use a public CA. For a list of public certificate authorities that provide certificates that comply with specific requirements for Unified Communications certificates and have partnered with Microsoft to ensure they work with the Office Communications Server Certificate Wizard, see the Microsoft Web site at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=SupportedCAs.
Certificate Requirements by Server Role
The following tables show certificate requirements by server role.
Standard Edition Server Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
All server roles (which are collocated) |
Enterprise CA |
FQDN of the Standard Edition Server |
If you have multiple SIP domains and have enabled automatic client configuration, the certificate wizard detects and adds each supported SIP domain FQDNs. (The wizard detects any SIP domains you specified during setup and automatically adds them to the SAN) |
Additionally, you must use the IIS administrative snap-in to assign the certificate used by the Web Component Server. |
Enterprise pool: Consolidated Server Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
All server roles (which are collocated) |
Enterprise CA |
FQDN of the pool For the Web Components Server role, the certificate must have the URL of the internal Web farm in the SN or SAN. |
If you have multiple SIP domains and have enabled automatic client configuration, the wizard detects the SIP domains, adds them to the SAN, and then adds each supported SIP domain FQDN. (The wizard detects any SIP domains you specified during setup and automatically adds them to the SAN) For the Web Components Server role, the certificate must have the URL of the internal Web farm in the SAN (if the FQDN is different from the pool FQDN). |
Certificate must be installed on each server in the pool. Additionally, you must use the IIS administrative snap-in to assign the certificate used by the Web Component Server. |
Enterprise pool: Expanded Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
Front End |
Enterprise CA |
FQDN of the pool |
If you have multiple SIP domains and have enabled automatic client configuration, add each supported SIP domain FQDN. (The wizard detects any SIP domains you specified during setup and automatically adds them to the SAN) |
Certificate must be installed on each server in the pool. |
Web Conferencing |
Enterprise CA |
FQDN of the pool |
Certificate must be installed on each server in the pool. |
|
A/V Conferencing |
Enterprise CA |
FQDN of the pool |
Certificate must be installed on each server in the pool. |
|
Web Components |
Enterprise CA |
FQDN of the VIP (virtual IP) of the load balancer used by the Web Components Server |
SAN must contain the URL of the internal Web farm in the SAN (if the FQDN is different from the pool FQDN) |
A certificate has to be configured in IIS on the all servers that are running the Web Component Services |
Director, Standard Edition Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
Director |
Enterprise CA |
FQDN of Standard Edition Server |
If you have multiple SIP domains and have enabled automatic client configuration and all clients use this Director for logon, add each supported SIP domain FQDN. (The wizard detects any SIP domains you specified during setup and automatically adds them to the SAN) |
Director, Enterprise pool Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
Director |
Enterprise CA |
FQDN of the pool |
If you have multiple SIP domains and have enabled automatic client configuration and all clients use this Director for logon, add each supported SIP domain FQDN. |
Array of Standard Edition Directors Topology
| Server Role | Recommended CA | Subject Name/ Common Name | SAN | Comments |
|---|---|---|---|---|
Director |
Enterprise CA |
FQDN of the Director Server |
FQDN of Director Server and the FQDN of the virtual IP (VIP) used by the array If you have multiple SIP domains and have enabled automatic client configuration and all clients use this Director for logon, add each supported SIP domain FQDNs. |
FQDN of the server is in the SUBJECT field FQDN of the Director VIP and the FQDN of the server must be in the SUBJECT_ALT_NAME as DNS values |
Certificate Requirements for Edge Servers
The following sections summarize the certificate requirements for edge servers on the internal and external interfaces of these servers. For topology specific requirements, refer to the Step 6. Plan for External User Access section of this document.
Internal Interface
The following summarizes the certificate requirements for the internal interface of your edge servers:
Each edge server in the perimeter network of the data center requires a certificate for the internal interface.
- If you are deploying a load balancer with multiple collocated Access Edge Servers and Web Conferencing Edge Servers, use a single certificate with a subject name that matches the FQDN for the virtual IP address used by the Access Edge Servers on the internal load balancer of the servers, for example, Certificate SN = accessedge_array.contoso.com.
For Web Conferencing Edge Servers (collocated on the computer with the Access Edge Server), by default, this certificate is shared by the Web Conferencing Edge Server. If an A/V Edge Server is also collocated on the server, it also shares this certificate by default. If the servers are not collocated, you must use separate certificates for each server role.
The A/V Edge Server in the perimeter network requires a certificate for the internal interface if it is running on a separate computer than the Access Edge Server. If you are deploying multiple A/V Edge Servers (with a load balancer), use a single certificate with a subject name that matches the FQDN for the virtual IP address used by the A/V Edge Server on the internal load balancer, for example: Certificate SN = avedge_array.contoso.com.
The Web Conferencing Edge Server in each remote site of a multiple-site edge topology requires a certificate on the internal interface with a subject name that matches the FQDN published on the internal interface of the firewall in the data center, and mapping to the Web Conferencing Edge Server in the remote site.
External Interface
The certificate requirements for the external interface include the following:
For each unique IP address on the external interface that you use for the Access Edge Server and Web Conferencing Edge Server, you will need a separate certificate. We recommend that you use a separate external IP addresses for each server role, even if all servers are collocated. An external certificate is not required on the A/V Edge Server. A separate A/V authentication certificate is required for the A/V Edge Server, but this certificate is not interface dependent.
For the scaled single site edge topology, we recommend that each server role use a separate VIP address on the external load balancer. A separate certificate matching the FQDN of each VIP address used by each Access Edge and Web Conferencing Edge server role must be installed on that server. For example, the Web Conferencing Edge Servers must have a certificate that matches the VIP (virtual IP) address used by the Web Conferencing Edge Servers on the external load balancer. The certificate must be marked as exportable on the first physical computer where you configure the certificate and then imported into each additional computer in the array. An external certificate is not required for the A/V Edge Server array on the external interface. A single, identical A/V authentication certificate is required for each A/V Edge Server in a load balanced array, but this certificate is not interface dependent.
If you are deploying a multiple-site topology, the Web Conferencing Edge Server in the perimeter network of each remote site requires a certificate with a subject name that matches the external FQDN of the Web Conferencing Edge Server in the remote site. A certificate is not required for the external interface of the A/V Edge Server.
If you are supporting public IM connectivity with AOL, AOL requires a certificate that is configured for both client and server authentication. For Yahoo! and MSN, a Web Server certificate will suffice. Public CAs that have partnered with Microsoft to comply with Office Communications Server 2007 will have client authentication configured for their Office Communications Server certificates. See https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=SupportedCAs to locate these CAs.
Public certificates are required for public IM connectivity, and they are highly recommended for federation. The public certificate installed on the server must be from a public CA that is on the default list of trusted root CAs installed on the client. For a list of public certificate authorities that provide certificates that comply with specific requirements for Unified Communications certificates and have partnered with Microsoft to ensure they work with the Office Communications Server Certificate Wizard, see the Microsoft Web site at https://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=SupportedCAs.
Note
Although not recommended, it is possible to use your Enterprise subordinate CA for federation if your federated partners agree to trust the CA.
For a detailed description of supported edge server topologies and server roles, see Plan for External User Access.
A/V Authentication Certificate
For the A/V Edge Server, an additional certificate is required for audio/video authentication. The private key of the A/V authentication certificate is used to generate authentication credentials. As a security precaution, you should not use the same certificate for A/V authentication that you use for the internal interface of the A/V Edge Server (covered earlier in this guide). We recommend that you issue this certificate from an internal CA, but you can also use a certificate from a public CA.
The same A/V authentication certificate must be installed on each A/V Edge Server if multiple servers are deployed in a load balanced array. This means that the certificate must be from the same issuer and use the same private key. Refer to the Step 6. Plan for External User Access section later in this guide and the Microsoft Office Communications Server 2007 Edge Server Deployment Guide for more information.