Deploying Certificates in Office
Communications Server 2007 and
Office Communications Server 2007 R2
Author: Rick Kingslan
Technical reviewers: Thomas Binder, Thomas Laciano, Nick Smith, Mitch
Duncan, Rui Maximo
Publication date: August 2009
Summary
In this document, you will learn about the properties and attributes of certificates when working
with Office Communications Server 2007 and Office Communications Server 2007 R2. This
document contains a walkthrough of most of the common, and some optional, tasks that you need
to perform to realize the full value of the system. All roles that require certificates for deployment
and operation are discussed. The properties are presented along with information to describe what
they are and how they are used. This document shows you how to request the right certificate with
the right parameters to make sure that you are delivering value to your users, rather than just
troubleshooting problems.
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Copyright
The information contained in this document represents the current view of Microsoft Corporation on the
issues discussed as of the date of publication. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED
OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or
for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement
from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks,
copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses,
logos, people, places and events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, email address, logo, person, place or event is intended or should be
inferred.
2009 Microsoft Corporation. All rights reserved.
Microsoft, SQL Server, Windows, Windows Server, and Windows Vista are trademarks of the Microsoft group
of companies.
All other trademarks are property of their respective owners.
Microsoft Corporation
2
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Contents
Introduction .................................................................................................................................................. 6
Terminology .................................................................................................................................................. 6
Subject Name ...................................................................................................................................................................... 7
Offline versus Online Certificate Requests ......................................................................................................................... 7
Requesting a Certificate from Another Machine ................................................................................................................ 8
Certificate Revocation List and CRL Distribution Point ....................................................................................................... 9
Reference Architecture and Phases of Deployment ................................................................................... 10
Certificate Deployment Phases ................................................................................................................... 12
Phase 1 – SQL Server Backend and Enterprise Pool or Standard Server .................................................... 12
Defining Certificates and Issuing Requests to the Certification Authority ....................................................................... 14
Using the Office Communications Server Certificate Wizard ........................................................................................... 14
Friendly Name ................................................................................................................................................................... 16
Encryption Key Bit Length ................................................................................................................................................. 16
Mark Certificate as Exportable ......................................................................................................................................... 16
Specifying Certificate Properties....................................................................................................................................... 17
Subject Alternative Name ................................................................................................................................................. 18
Submit and Assign Certificate ........................................................................................................................................... 22
Certificate Details .............................................................................................................................................................. 23
Web Components Process for Consolidated Topology .................................................................................................... 27
Web Components Request Process in an Expanded Topology ........................................................................................ 28
Server 2003 IIS 6 Manager Process ............................................................................................................................... 28
Server 2008 IIS 7 Manager Process ............................................................................................................................... 31
Using the LcsCmd Command-line Tool ......................................................................................................................... 32
Certreq – Custom Template Certificate Requests ........................................................................................................ 35
Phase 1 Summary.............................................................................................................................................................. 43
Phase 2 – Director ....................................................................................................................................... 44
Using the Certificate Wizard ............................................................................................................................................. 44
LcsCmd .............................................................................................................................................................................. 45
Certreq .............................................................................................................................................................................. 46
Phase 2 Summary.............................................................................................................................................................. 48
Microsoft Corporation
3
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Phase 3 – External Access with Edge Server Roles ..................................................................................... 48
Access Edge Server, Web Conferencing Edge Server, and Audio/Video Edge Server Roles ............................................. 48
Using the Certificate Wizard ............................................................................................................................................. 50
Edge Server Certificate Requests .................................................................................................................................. 50
Access Edge Server............................................................................................................................................................ 51
Certificate Wizard – Access Edge Server ....................................................................................................................... 51
LcsCmd – Access Edge Server........................................................................................................................................ 52
Certreq – Access Edge Server........................................................................................................................................ 53
Web Conferencing Edge Server ........................................................................................................................................ 53
Certificate Wizard – Web Conferencing Edge Server ................................................................................................... 53
LcsCmd – Web Conferencing Edge Server .................................................................................................................... 53
Certreq – Web Conferencing Edge Server .................................................................................................................... 54
Audio/Video Authentication Edge Server ......................................................................................................................... 54
Certificate Wizard – A/V Authentication Edge Server .................................................................................................. 55
LcsCmd – A/V Authentication Edge Server ................................................................................................................... 55
Certreq – A/V Authentication Edge Server ................................................................................................................... 56
Edge Server Internal Edge ................................................................................................................................................. 56
Using the Certificate Wizard – Edge Server Internal Edge ............................................................................................ 56
LcsCmd – Edge Server Internal Edge ............................................................................................................................. 57
Certreq – Edge Server Internal Edge ............................................................................................................................. 57
Reverse Proxy Server ........................................................................................................................................................ 58
Configure a Reverse Proxy ............................................................................................................................................ 58
LcsCmd – Reverse Proxy................................................................................................................................................ 58
Certreq – Reverse Proxy................................................................................................................................................ 59
Phase 3 Summary – External Access with Edge Server Roles ........................................................................................... 64
Phase 4 – Voice Services ............................................................................................................................. 64
Exchange Unified Messaging ............................................................................................................................................ 64
Mediation Server .............................................................................................................................................................. 65
LcsCmd – Mediation Server .......................................................................................................................................... 66
Certreq – Mediation Server .......................................................................................................................................... 66
Media Gateways ........................................................................................................................................................... 67
Hybrid Media Gateways ................................................................................................................................................ 67
IP-PBX ............................................................................................................................................................................ 68
Microsoft Corporation
4
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Phase 4 Summary – Voice Services ................................................................................................................................... 68
Phase 5 – Group Chat Server ...................................................................................................................... 68
LcsCmd – Group Chat Server............................................................................................................................................. 68
Certreq – Group Chat Server............................................................................................................................................. 69
Phase 5 Summary – Group Chat Server ............................................................................................................................ 70
Phase 6 – Communicator Web Access ........................................................................................................ 71
Creating and Requesting the Certificates ......................................................................................................................... 73
CA Certificate Chain ...................................................................................................................................................... 73
LcsCmd – Communicator Web Access for Reverse Proxy ............................................................................................. 74
LcsCmd – Communicator Web Access for MTLS/TLS .................................................................................................... 75
Certreq – Communicator Web Access for Reverse Proxy ............................................................................................. 75
Certreq – Communicator Web Access for MTLS/TLS .................................................................................................... 76
Phase 6 Summary – Communicator Web Access.............................................................................................................. 77
Hardware Load Balancer Configurations .................................................................................................... 78
Hardware Load Balancer and Connected Server Certificate Requirements ..................................................................... 78
Pool / Front End Servers ................................................................................................................................................... 79
Director ............................................................................................................................................................................. 84
Edge Servers ...................................................................................................................................................................... 86
Client Requirements and Client Communication.............................................................................................................. 87
Validation and Troubleshooting........................................................................................................................................ 87
Services Are not Starting and Event Log Shows Numerous Errors ............................................................................... 88
No Certificate Chain for the Certificate That You Are Attempting to Trust .................................................................. 89
Service Not Started, Not Configured, or Recognized .................................................................................................... 90
Failure [0xC3Ec79E6] Service failed to start as requested ............................................................................................ 90
Communicator Web Access error – “Your session was ended… Error code:0-0-18100-2-0” ....................................... 91
CRL and CDP Troubleshooting....................................................................................................................................... 91
Frequently Asked Questions ....................................................................................................................... 92
Additional Resources .................................................................................................................................. 94
Acknowledgements..................................................................................................................................... 95
Microsoft Corporation
5
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Introduction
Certificates and public key infrastructure (PKI) systems can be very complex and are often misunderstood. Typically, a
dedicated team of security experts in a corporation plan, configure, and operate these systems. For Office
Communications Server, the properties that you apply to a certificate for a specific task or role must be correct, or else
the servers will not authenticate, causing failure in validation or activation of services. In Office Communications Server
2007 and Office Communications Server 2007 R2, certificates encrypt traffic by using Transport Layer Security (TLS),
which is the successor to Secure Sockets Layer (SSL), and provide strong authentication by using mutual TLS (MTLS).
In this document, you will learn about the properties and attributes of certificates when working with Office
Communications Server 2007 and Office Communications Server 2007 R2. This document contains a walkthrough of
most of the common, and some optional, tasks that you need to perform to realize the full value of the system. All roles
that require certificates for deployment and operation are discussed. The properties are presented along with
information to describe what they are and how they are used. This document shows you how to request the right
certificate with the right parameters to make sure that you are delivering value to your users, rather than just
troubleshooting problems.
The scope of this document is to discuss the certificate deployment process only, not the deployment process for
servers and their configuration. In some cases, role configuration is discussed at a high level because it is necessary to
the certificate process. For details about planning and deployment, see the following:


Office Communications Server 2007 R2 documentation at http://go.microsoft.com/fwlink/?LinkId=132106.
Office Communications Server 2007 documentation at http://go.microsoft.com/fwlink/?LinkId=162674.
Terminology
To ensure a complete understanding of certificates and the requirements for certificates in Office Communications
Server, it is necessary to define terms that are commonly used when discussing certificates and PKI. The following links
provide terminology definitions and conceptual information:

Windows Server 2003 Deployment Guide “Basic PKI Concepts” at
http://go.microsoft.com/fwlink/?LinkId=161396.

Ask the Directory Services Team blog “Certificate Concepts” at
http://go.microsoft.com/fwlink/?LinkId=161397.

Internet X.509v3 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile at
http://www.ietf.org/rfc/rfc3280.txt.
Note Microsoft works with public certification authority (CA) partners to help ensure that there is
correctly formed subject name and subject alternative names, resulting in approved certificates for roles
that require a public certification authority. It is important to know that you can use public CA
certificates for your entire Office Communications Server configuration, but only a few are required.
Microsoft Corporation
6
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2

Knowledge Base article 929395, “Unified Communications Certificate Partners for Exchange 2007 and for
Communications Server 2007,” at http://go.microsoft.com/fwlink/?LinkId=140898.
Subject Name
The following information is very important and requires your close attention. A certificate contains a vitally important
piece of information that is called the subject name. The subject name (SN) clearly identifies the Domain Name System
(DNS) name of the server or load balancer virtual IP that the certificate is assigned to. The SN is referenced by the calling
server or client, and the connecting end point expects to find the SN and DNS to be exactly the same. If they are not, the
server or client will refuse to communicate with the server with the incorrect SN. This is a vital part of the security
structure in Office Communications Server that prevents spoofing, hijacking, or “man-in-the-middle” attacks.
The SN is populated with a lot of information that most certification authorities need (that is, by specification it is
defined as MAY CONTAIN), but this information is not necessarily required by Office Communications Server 2007 or
Office Communications Server 2007 R2. The portion of the SN that is absolutely critical for the proper operation of
certificates in Office Communications Server is the common name (CN) portion of the full SN. Over the years, the
distinction between the subject name and common name has become blurred.
To fully understand the difference, a certificate’s SN follows this format:
CN=pool01.contoso.com, OU=IT, O=Contoso, L=Redmond, S=Washington, C=US
The CN is just the pool01.contoso.com portion of the entire SN string. Microsoft adheres to the certificate standard
X.509v3, which are the conventions used in Office Communications Server.
A subject name can be a fully qualified domain name (FQDN), a Lightweight Directory Access Protocol (LDAP) path, or an
e-mail address. Though the line is blurred as to what is a subject name and what is a common name because the terms
are used interchangeably in the IT community at large, by remembering this information your certificate complexity will
drop dramatically.
Offline versus Online Certificate Requests
Because of common security practices and the nature of firewalls, you will likely encounter situations in which you will
have to make offline certificate requests (that is, situations where you cannot connect to the CA directly over the
network). An offline certificate request typically involves saving a request to a file and then submitting the file to a CA by
transporting the request file by means of a thumb drive or some other means. After the certificate request is processed,
the completed certificate file is transported back to the target server for import and further request acceptance
processing to complete the binding of the keys to the certificate.
An offline request is the typical situation you encounter when dealing with a public CA. You do not submit your request
directly to the CA, but you use e-mail or some other means (that is, a web site or other tool supplied by the CA vendor)
to request the certificate.
Microsoft Corporation
7
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Requesting a Certificate from Another Machine
There are a number of certificates in the Office Communications Server infrastructure, and not all of these can be
requested from the machine that they are intended for. This may be caused by security requirements (that is, you
cannot install LcsCmd or the Office Communications Server tools, firewall prevents sending out, or so on) or difficulty
accessing the system to generate a certificate.
Another reason why you may want to request the certificates from a computer that is not running Office
Communications Server is that it is easier to document the process from your workstation.
The main tasks that you need to consider when generating all of the certificates on a workstation or other server is that
the private and public key generated on the workstation that is not running Office Communications Server must be
exported off of the machine on which the certificate was requested, and then imported and assigned to the proper
server and role on the server running Office Communications Server.
This process raises the question of how can you request a certificate for another system that you are not currently
logged onto. You may wonder why this does not break the implied trust that certificates are supposed to help manage.
This process combines the following three elements:
 Private Key (must mark as Exportable when you create it)
 Public Key
 Signed certificate from a trusted CA
If you have all three of these elements in the proper key material store (for example, the Personal store for User or
Machine) and bound properly with a root certificate or chain from the issuing authority, it is a trusted and valid
certificate. The reason that this works is that it is not easy to get all three elements requested, received, exported,
imported and bound. You need to be an administrator or a role with equivalent permissions on the target system to
accomplish all of this. Trust stays intact because you are acting as the administrator or equivalent, and you have full
permission on the machine.
The Microsoft Active Directory team has written blogs specifically about this topic. For details about how to request and
retrieve the certificate, see the following:

Directory Services Team blog “Custom Certificate Request in Windows Vista® (and Server 2008)” at
http://go.microsoft.com/fwlink/?LinkId=161855.
 LCSKid: LCS and OCS Product Information blog “Creating Certificates for LCS (Guidance for Server 2003)” at
http://go.microsoft.com/fwlink/?LinkId=161856.
After you have accomplished the certificate request, you need to export the certificate, public key, and the private key
so that you can move them to the target machine. Remember that the keys are machine key sets, so ensure that you
have the focus on the Local Machine stores. Finally, you copy the resulting PKCS#12 format (that is, the designation for a
certificate with private key and typically a .pfx file) file to removable media so that you can take it to the destination
server and import it into that machine’s store. For details, see the following:


For Windows Vista and Windows Server 2008, see “Import or export certificates and private keys” at
http://go.microsoft.com/fwlink/?LinkId=161857.
For Windows XP and Windows Server 2003, see “To export a certificate with the private key” at
http://go.microsoft.com/fwlink/?LinkId=161858.
Microsoft Corporation
8
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The common name, notated as CN in X.500 terminology, is what is referenced and must match the DNS record for the
server’s FQDN. For details about the specific format that should be in ASN.1 notation, see RFC 3280 “Appendix A” at
http://www.ietf.org/rfc/rfc3280.txt. In addition, other servers and clients that communicate with the certificate holder
use DNS lookups to refer to this server FQDN. If the reference to the server does not match the common name of the
certificate, the certificate presented by the server will fail authentication. This explains why a wildcard certificate will not
work as intended in Office Communications Server – namely, because the common name must match exactly to the
FQDN of the A record defined for the referenced server or pool. The DNS A record and the certificate subject
name/common name (SN/CN) is also referenced to the trusted server list in Active Directory® directory service Global or
Configuration settings.
To accomplish strong authentication by matching the FQDN of the server (that is, as represented in DNS) to
the SN/CN in the certificate returned by the referenced server.
Certificate Revocation List and CRL Distribution Point
The certificate revocation list (CRL) and the CRL distribution point are mechanisms managed and maintained by the CA
for keeping a list of certificates that have been revoked (they contain more than just revoked certificates – for details,
see IETF RFC3280) for a number reasons, often related to a compromised certificate, a wrongly issued certificate, and
the so on. Expired certificates do not appear in the CRL, because the expiration date on the certificate manages the
lifetime and the CRL is not needed for this purpose. In specific terms, the CRL is populated with certificate information
(for example, serial number) for a certificate that was removed as a valid certificate before the expiration lifetime. As
the size of the base CRL can grow rather large over a period of time, especially when dealing with public CAs, CRLs are
managed in two ways. The base CRL is a list of the primary collection of revoked certificates. From that point on, a delta
(difference) CRL is published. At defined intervals, the delta CRL is published with only changed certificate status. Then,
at another defined interval, the delta CRL is merged into the base CRL, ensuring that new clients get the full list of all
certificates considered no longer valid on the issuing CA.
The CRL distribution point is the location on the CA/PKI from which a client, server, or device can retrieve the revocation
list. The CRL distribution point lists up to three of the following ways for a machine to access the CRL:
1. A fully qualified LDAP path
2. A fully formed HTTP URL
3. A file path
To test and confirm that the HTTP CRL path is working properly, you can use a Web browser. Simply type or paste the
URL into the browser address bar to confirm that you can download the revocation list.
Though the CRL is a vital part of certificate health, Office Communications Server and security measures might make it
difficult in some scenarios to retrieve a CRL. To address this issue, Office Communications Server works with CRLs in an
offline cached mode. It is a best effort mechanism to retrieve CRLs from the published CRL distribution points. And,
because of firewall rules to internal systems, the Audio/Video authentication role may have a difficult time retrieving a
CRL. The best way to address this is to allow HTTP traffic from the Edge Servers to the CA. As long as the CA can offer a
CRL by using a published HTTP CDP path and the client can retrieve, this should present a negligible security risk.
Another way to mitigate the risk is to deliver CRLs by using removable media on a scheduled basis.
Microsoft Corporation
9
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Reference Architecture and Phases of
Deployment
The following figure represents an example of a possible rollout performed in phases. Use this diagram to understand
which phase contains a certificate discussion that pertains to your situation.
Microsoft Corporation
10
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Unified Communications
Endpoints
HTTP Reverse Proxy
(Internet Security and
Acceleration Server or
similar)
Public IP
Phase 6
Load Balancer
Phase 3
Attendant
Console
CWA Servers
Communicator
Mobile
OC Phone
Edition
Enterprise Pool
Load Balancer
Phase 2
Load Balancer
Consolidated
Edge Servers
Load Balancer
Load Balancer
MSN
AOL
Yahoo!
Federated
Networks
Live
Meeting
Communicator
Director(s)
Consolidated
Front End Servers
Phase 1
Back End
SQL Server
Phase 4
PSTN
IP-PSTN
Gateway(s)
Mediation
Server(s)
PBX
Phone
External
Perimeter Network
IP-PBX
FAX
Internal
Monitoring SQL Server
(CDR & QoE)
Archiving
Phase 5
Group Chat SQL Server
Server
Media Traffic
PSTN Traffic
SIP Traffic
HTTPS Traffic
Figure 1 Overview of phased rollout
Microsoft Corporation
11
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Certificate Deployment Phases
Most Enterprise deployments are carefully planned and thought out in advance. The installation
of the required and optional elements of Office Communications Server 2007 and Office
Communications Server 2007 R2 is no exception. In fact, the complexity of Office
Communications Server requires careful advance planning to ensure success.
The following deployment phases are not intended to be a recommendation on the order of
deployment for any given project. These phases and their order do follow a logical procession of
installing the basic required elements first and then adding to the deployment to provide
significant overall value to the typical Enterprise.
The main thought to remember is that you should carefully plan for your deployment and
consider the required certificates as you choose your deployment path.
Phase 1 – SQL Server Backend and
Enterprise Pool or Standard Server
During the process of installing and configuring a pool, you are required to request and install
certificates for the front end. For Standard Edition servers that are collocated with SQL Server
on the same server, you can safely assume that references to a pool or Front end, unless
otherwise noted, apply to the Standard Edition server too. The steps in Phase 1 are quite a bit
more involved and the properties needed for your certificates are more detailed. Because the
same basic process applies to all certificates in Office Communications Server, you can refer to
the Phase 1 information during later phases.
Note Office Communications Server uses Message Queuing (also known as MSMQ)
services on the Front End, Group Chat, Archiving, and Monitoring servers which
eliminates the need for managed (that is, manually requested and applied) certificates
to protect the data in transit from server to SQL Server database. The Message Queuing
domain integration component is needed because the keys for the encryption are
stored in the directory services. As a result, you do not need to request and manage
certificates for database communication where Message Queuing is implemented. For
details, see the Windows Server TechCenter “Encryption for Message Queuing Windows Server 2003” at http://go.microsoft.com/fwlink/?LinkId=161859 and Windows
Server TechCenter “Appendix D: Message Queuing and Internet Communication in
Windows Server 2008” at http://go.microsoft.com/fwlink/?LinkId=161860.
Microsoft Corporation
12
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
You can request a certificate for the Front End or Standard Edition server by using any of the
following tools:
 Installation Wizard (Office Communications Server R2 Deployment Wizard)
 LcsCmd command line tool
 CertReq (Windows® operating system command-line tool)
This document explains how to use the Installation Wizard and the LcsCmd tool. There are other
tools that you can use to request certificates, but the tools in Office Communications Server are
recommended. Another tool that can request, assign, and work with certificates is Certreq, a
tool that is delivered with the default Windows Server® operating system installation from
Windows Server 2000 to Windows Server 2008. This document covers a specific use of the tool
to allow you to request certificates when the default Web Server certificate template has been
disabled and a custom template has been created for specific security purposes. For details
about the Certreq tool’s syntax and the parameters for the optional .inf file, see the following:


Windows Server Command-line Reference “Certreq” at
http://go.microsoft.com/fwlink/?LinkId=161861.
Advanced Certificate Enrollment and Management “Appendix 3: Certreq.exe Syntax” at
http://go.microsoft.com/fwlink/?LinkId=161862.
Note It is important that you understand what the Certreq tool can do before you
proceed to the discussion about the syntax. It is a more complex tool than the LcsCmd
tool and the installation wizard.
Neither the Certificate Wizard nor the LcsCmd tool provides a means to define a custom
template. However, the custom template does need to provide the same basic structures that
you find in the Web server template and allow for the inclusion of the Server Enhanced Key
Usage (EKU) and a properly formatted subject alternative name. A custom template is typically
found in environments where the security requirements demand something specific above what
the general Web Server template provides. It is possible that your organization’s security team
has defined specific levels of encryption or authentication. In this case, the CA administrator
needs to make a copy of the Web Server template, which is performed from within the CA
management tools, make the required changes, and then save the template with a new name.
By doing this, the Web Server template is then disabled so that it cannot be used.
Office Communications Server can use a stand-alone CA, an Enterprise CA, or an issuing CA in a
PKI hierarchy. As long as the CA meets the requirements for providing the attributes necessary
to authenticate servers, encrypt traffic, and sign traffic, Office Communications Server can use
any Windows CA configuration.
Finally, if you are using Certreq, you need to make sure that the certificates are installed in the
Computer or Machine certificate store. You can instruct Certreq to do this during the
acceptance of the issued certificate by using the –Machine command-line option.
Microsoft Corporation
13
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Defining Certificates and Issuing Requests to the
Certification Authority
There is one certificate that you need to request for the Front End Server, which is used for two
purposes. Phase 1 covers the SIP signaling traffic and the configuration of IIS for conferencing
and the Web components. Installation and configuration of IIS certificates for TLS/SSL is
covered. The installation wizard does not do the IIS assignment for you, but the wizard provides
guidance on what you need to do. In the second part of Phase 1, you are guided through the IIS
assignment process and learn how to enable SSL.
In each case, you need to have either a certification authority (CA) available on the network, use
an offline request process for issuing through established processes with the CA administrator,
or request certificates from a public CA.
In the case of an on-site CA, you can use the automatic request process or the offline request
process. Be aware, that by default, you may not have the permission to actually submit the
request and retrieve the signed certificate. In this case, your PKI Manager should know what is
required.
Using the Office Communications Server Certificate
Wizard
The Office Communications Server Certificate Wizard accomplishes the following tasks:
 Creates a request.
 Submits the request to a CA.
 Retrieves the certificate from the CA
 Assigns the certificate to the proper role.
For the complete steps on pool and Standard Server deployment, see Office Communications
Server 2007 R2 “Deploying Office Communications Server 2007 R2 for Internal User
Access” at http://go.microsoft.com/fwlink/?LinkId=161863.
You configure the certificates for the pool after you have created the pool. You request the
certificate in step 2 of pool configuration. When you click Run, the Office Communications
Server Certificate Wizard opens.
Note The process in this section is similar to what you do in a Standard Edition
deployment, but for illustrative purposes this paper uses an Enterprise pool for the
reference examples and topology in this section.
When you click Next on the Office Communications Server Certificate Wizard, you are presented
with six options: three that enable you to define how you are going to request the certificate
and three that enable you to define how to import a resulting request type.
Microsoft Corporation
14
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
On the Available Certificate Tasks page, there are three bullets available. Each bullet represents
a stage in the certificate process. The first option enables you to create a new certificate, the
second option enables you to process an offline request and then import the certificate into the
proper store, and the third option enables you to assign certificates that have already been
requested and imported onto the system. To demonstrate the different options, this document
uses each of these options as you go through the steps for acquiring and assigning certificates.
On the Available Certificate Tasks page, select Create a new certificate, and then select either
Send the request to an online certification authority or Prepare the request now, but send it
later (Offline certificate request).
Figure 2 Create a new certificate
The two choices define whether the request that you are making is to be sent to a CA that is
currently online and accessible in real-time, or saved to a certificate signing request (CSR) file. In
enterprises that have a PKI, you should be able to send this request to an issuing CA, but this is
not always the case due to varying security policies and procedures. When this document
discusses other roles (that is, Edge Servers specifically), an online request is rarely an option due
to the segregation of the perimeter networks from the internal networks.
Note A CSR is the encoded file that is output from the Certificate Wizard, LcsCmd, or
Certreq. The CSR is a “blob” of text that is meaningful to a CA, but is not meant to be
readable. The CSR is the actual information that was input, such as the common name,
the subject name, subject alternative name (SAN) entries, and so on. The CSR, along
with the encoded public key, is sent to create the signed certificate.
By selecting Send the request immediately to an online certification authority, you begin the
process of configuring the parameters for a certificate to be sent over the network to a CA.
Microsoft Corporation
15
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Friendly Name
The page asks you for a name for the certificate. This is the friendly name that allows you to
define a name that will allow you to easily identify the certificate. This should not be confused
with either the common name (CN) or the subject name (SN) of the server that the certificate is
being created for. You use this name to easily identify what the certificate is, and what server
and role it was requested for. By providing a friendly name in the form of <hostname> <role>
(for example, Contoso-FE Front End SIP), you can more clearly document your certificates.
Encryption Key Bit Length
The encryption key bit length determines how many bits comprise the key. Using a longer key
length is a security best practice, but the downside is that performance may suffer due to the
greater amount of intensive math that is required for the processor to perform. For most
purposes, unless otherwise defined by policy, 1024-bit key is the recommended length.
However, you should always check other devices (for example, media gateways, phones, and so
on) that are used in your environment to assure that certificate encryption key length and digest
type (for example, SHA1, RSA, SHA1RSA, and so on) is supported. Microsoft has tested root
certificates that have key lengths of 2048 and 4096 bits (with SHA1RSA being the signature
algorithm), and Server certificates with a key length of 1024 bits. In terms of signature
algorithms, SHA256 and MD5 are currently not supported for use with Office Communications
Server 2007 R2, but they are being evaluated for future releases. You also need to verify that
root and intermediate CA certificates in more complex PKI are supported. If a root or
intermediate CA has a longer key, the certificate chain may cause a problem, not the actual
certificate requested.
A longer key (for example, 2048, 4096) is preferable because of the much higher degree of
difficulty in breaking the key. To determine what length key you should use, you need to
consider the level of risk, and whether or not 1024-bit length keys meet the risk that you have
identified.
Mark Certificate as Exportable
At this stage in the wizard, you are presented with the Mark cert as exportable option and the
Include client EKU in the certificate request option. Select the Mark cert as exportable option if
you need to export the private key (for example, in cases such as backup, or creating the
certificate and key pair on a machine other than the intended host), but be sure to re-import the
certificate and set it to not allow export to protect the keys in use. The only role that requires
you to have the keys exportable is for load balancing of the audio/video authentication service,
where you use the exported key to create duplicate certificates.
Microsoft Corporation
16
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
By selecting the Include client EKU in the certificate request check box, you can include the
client extended key use (EKU) on the certificate. Currently in Office Communications Server
2007 R2, the only time that a client EKU is necessary is when you are setting up and configuring
public instant messaging (IM) connectivity with AOL. Otherwise, a client EKU is not needed. That
being said, the certificate will work if the client EKU is included. Keep this in mind if you decide
not to use public IM connectivity at the present time, but may use it in the future. By requesting
the client EKU, you avoid having to acquire a replacement public CA certificate later and having
to repurchase it to allow AOL instant messaging (IM) through public IM connectivity.
Specifying Certificate Properties
In the next portion of the configuration, you provide information that is required to populate
the X.500 subject name properties. The first two parameters define the organization (O) and the
organizational unit (OU). Fill these in these fields as is appropriate for your organization and
then click Next.
Figure 3 Specify the organization and subject name information
In the next wizard page, you provide the subject name (SN) and the subject alternative names.
The SN uniquely identifies the server by using the server’s fully qualified domain name (FQDN).
During your Front End Server deployment, you created a DNS A record for the pool. The DNS A
record may be different than the host name. In the Subject name field, you specify the FQDN of
the DNS A record for the pool in DNS. In the case of a load balancer, the subject name is the DNS
name of the virtual IP addressed interface associated with the load balancers. For details about
the importance of the common name portion of the subject name, see the “Subject Name”
section earlier in this document.
Note The subject alternative name and subject alternate name are synonymous. The
term subject alternative name is the RFC-compliant term, but subject alternate name is
often used.
Microsoft Corporation
17
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Important You cannot use a wildcard CN/SN (for example, *.contoso.com) when you
configure certificates for Office Communications Server 2007 R2 and Office
Communications Server 2007. If you do so, they will not operate as expected and the
problem is very difficult to diagnose. You can use wildcard entries in the subject
alternative name, but the common name is specific. Specific issues include the inability
to start services because the trusted services in Active Directory Domain Services
(AD DS) and the SN and CN do not match, mutual authentication fails, and so on.
Important Some public CA vendors do allow you to issue a wildcard certificate for the
SN/CN. Simply because you can do this does not mean that it is a good practice. And,
because it appears to work does not indicate that it is reliable or supported. Also, verify
the SAN entries. If you request a SAN of sip.contoso.com, some public CA vendors may
append sip.contoso.com with ”www”, making your SAN www.sip.contoso.com. You
should note that the SAN as appended with “www” is not the same as what you
requested and it will not work.
Note Load balancers and certificate requirements are addressed in detail later in this
document.
Subject Alternative Name
In the subject alternative name section, you can enter one or more subject alternative names
that you want to include on the certificate. There is a limit on the number of subject alternative
name entries that you can include. The number of entries is limited by the number of characters
in the subject alternative name field, and may vary from CA to CA, especially if you are using
public CAs. A public CA implementation can be as little as 40 entries (that is, 200 characters or
less). Windows CAs have a field that allows for roughly 150 25-character subject alternative
names. Subject alternative name entries can include a leading wildcard that will match multiple
entries. Note that an entry of *.contoso.com will match domains and devices that use the suffix
contoso.com to one level For example, this entry would match prod.contoso.com or
corp.contoso.com, but not sales.prod.contoso.com.
The certificate must include the FQDN of the server that this certificate is responsible for
identifying in the SN/CN. Subject alternative name entries that are meant to provide wide
matching for the certificate will not work. The process of authentication by another server or a
client requires that the SN have the FQDN of the server as represented in DNS.
There is a choice that you can use to automatically add the local machine name to the subject
alternative name. This is typically considered a good idea because the FQDN of the host machine
in the subject alternative name is actually an X.509 requirement. If there is no subject
alternative name defined, a subject alternative name is not enforced and the requirements are
still met. For consistency and good practice in defining subject alternative names and SN/CN,
make it a part of your procedure to always include the SN/CN on the subject alternative name of
Microsoft Corporation
18
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
the certificate, unless you have a good reason not to do it. There are exceptions to this situation,
such as Internet Security and Acceleration (ISA) Server releases prior to the ISA Server 2006
Service Pack 1 release. For details about this problem and how ISA Server 2006 SP1 fixes this
issue, see the Forefront TMG (ISA Server) Product Team Blog article “Certificates with Multiple
SAN Entries May Break ISA Server Web Publishing” at
http://go.microsoft.com/fwlink/?LinkId=161864.
Note Details specific to load balancers and certificate requirements are discussed later
in this document.
As a best practice that you can follow when subject alternative names are configured on a
certificate, do the following: If a subject alternative name exists, ignore the subject name and
refer only to the subject alternative name.
The subject alternative names that are included on the certificate have an impact on automatic
configuration of the Office Communicator client. You can deploy Office Communicator without
configuring how the client connects to the Office Communications Server infrastructure. It
requires that the SRV DNS records are defined properly and that the DNS A records are defined
for each SIP domain that you plan to host.
The SRV records for the internal client take the following form:
_sipinternaltls._tcp.<SIP domain name> over TCP 5061
_sipinternal._tcp.<SIP domain name> (Assuming that TCP only connections are allowed)
There is an associated DNS A record that defines the IP address for the pool server that hosts
the SIP domain. The DNS A record takes the following form:
<pool name>.<SIP domain name> over TCP 5061
The certificate that is requested for the pool must include each of the A record entries for
supported SIP domains. If your pool is supporting five SIP domains, you need five SRV entries,
five DNS entries, and five subject alternative name entries in the certificate. Consistency and
parity of the DNS records and certificate configuration is important.
For clients that are external to the enterprise, there are required SRV records, too. The SRV
records, and the associated DNS A records, are defined on the perimeter or external DNS server.
The SRV records take the following form:
_sip._tls.<SIP domain name> over TCP 443
The associated DNS A records must point to the Access Edge Server. The certificate, which is
detailed in the “Phase 3 – External Access with Edge Server Roles” section of this document,
configured on the Access Edge Server must have a subject alternative name consistent with the
DNS A records configured for resolving SIP domains that the Access Edge Server services.
Microsoft Corporation
19
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Federation partners require a different SRV record. The record configured for automatic
discovery for federated partners takes the following form:
_sipfederation._tls.<SIP domain name> over TCP 5061
The associated DNS A record must be externally resolvable to your Access Edge Server. Like
automatic configuration for external clients, the certificate must contain subject alternative
names for each SIP domain that the Access Edge services for federated partners.
On the Geographical Information page, you provide information about the country/region (C),
the state (STATE), and city or locality (L).
Figure 4 Define geographical information and specify certification authority (CA)
The Choose a Certification Authority page appears if you chose to submit your request to an
online CA. If you select the first option, you can select a CA from a list of certificates that are
detected on your network.
If one is not detected or if the CA is not a Windows-based CA, you select the next option and
provide the FQDN and the CA instance. The CA instance is the name of the CA service that is
running on the indicated server. For example, in the scenario for this document the server and
instance name would appear as follows:
Contoso-DC.contoso.com\contoso-CONTOSO-DC-CA.
Where Contoso-DC.contoso.com is the fully qualified CA server and contoso-CONTOSO-DC-CA is
the CA service instance hosted on that server.
You can get this information by using the Certification Authority snap-in under Administrative
Tools on the CA server, or by using Certutil (that is, a tool provided with server and client
Microsoft Corporation
20
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Windows systems). To get a list of known Windows CAs, type the following command at a
command prompt on a certification authority:
certutil –V
Figure 5 Certification authority information with server FQDN and certification instance name
To query your certification authority for the templates that are available, use the command at a
command prompt on the certification authority:
certutil –CATemplates
Figure 6 Available templates on certification authority with template name and display name
Microsoft Corporation
21
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
This command shows what templates are available for use on each CA, which can be very
helpful.
If you are just looking for a list of the known Windows CAs in your Enterprise, you can run
LcsCmd. LcsCmd outputs to the same XML-based file format that the validation reports output
to. To run LcsCmd, type the following command at a command prompt, defining /L for the log
file path and name you want, and /XML if you want XML output or not for the log file:
LCSCmd.exe /Cert /Action:ListCA [/L:<log file path>] [/XML[:{TRUE|FALSE}]]
The Request Summary page of the wizard presents all of the options that you just configured.
Double check this list to confirm that everything is correct. If you need to edit something, click
the Back button to return to the section that you need to change.
Figure 7 Review summary information
After you have completed your summary review, click Next.
Submit and Assign Certificate
Provided that everything is correct in the wizard, the following page appears:
Microsoft Corporation
22
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 8 Submit and assign certificate
Note If you encounter a problem with the CSR submission, see the “Validation and
Troubleshooting” section later in this document.
This page indicates that the certificate request was successful, and that the certificate is now on
the Front End Server where you ran the wizard.
You have two choices at this point: you can assign the certificate now, or you can choose to
assign it later.
Certificate Details
At this point in the process, you can view the certificate that you just received. If you click View,
you can view general information, details, or the certification path of the certificate.
Microsoft Corporation
23
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 9 Review certificate details in Windows Server 2003 (left) and Windows Server 2008
(right)
On the General tab of the certificate, you can see that the purpose of the certificate is to Ensure
the identity of a remote computer. The certificate was issued to a pool server in the domain
contoso.com and it is valid for two years. The certificate also states what CA issued the
certificate. It also notes that the server has a private key that corresponds to this certificate,
confirming that this server has a valid key pair, verified and trusted by the issuing CA. This
indicates is that the system that this certificate is installed on has the private key and that the
certificate is bound to it. In essence, you have a valid public/private key pair, which is required
for the certificate to operate as needed in Office Communications Server. If the private key and
certificate have not been properly bound, the certificate does not appear as a certificate that
can be assigned in the Certificate Wizard assignment options.
Microsoft Corporation
24
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 10 Review subject name associated with a specific certificate
The Details tab shows the full subject name (SN) associated with this certificate. However,
Office Communications Server uses the portion listed as common name (CN). The CN is the
FQDN for the server that the certificate was issued to provide trust and identity. In the case of a
pool server, this is the referenced DNS A record that defines an entire pool, and is typically not
the FQDN of the actual individual pool member servers. On this page, you can see that the
public key is 1024 bits in length.
Microsoft Corporation
25
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 11 Review certificate template information
If you scroll down a little farther into the details of this certificate, you can see that the template
that this certificate is based on is a Web Server template. Because TLS and MTLS are both the
next version of SSL, the Web Server template is appropriate for this type of certificate.
The Enhanced Key Usage section shows that this certificate was issued for the purposes of
authenticating the identity of servers, and because of this EKU you can accomplish mutual
authentication. In contrast to SSL, which is synonymous with the original SSL specifications,
MTLS uses a Server EKU that challenges a requesting server to identify itself. MTLS generally
enforces that each server must authenticate with the other server before communication can
begin.
The subject alternative name is listed in the details section as well. In this case, you can see that
the wildcard entry is available, as well as the FQDN of the server. This was added to the subject
alternative name automatically, so you do not have to request it. This is a normal entry into the
subject alternative name.
Microsoft Corporation
26
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 12 View the friendly name
The last section of the details is the entry for the Friendly Name. The purpose of this section is to
make the identification and use of the certificate easier for the administrator.
The Certification Path tab shows whether the certificate is valid and trusted by the issuing CA.
The certificate status indicates that This certificate is OK, but validation requires more than just
having the certificate. It might seem odd to think that the server does not trust the CA that
issued the certificate. By default, other than this digital construct and implied trust, there is
nothing provided to the server to assure the identity of the CA or CAs that issued the certificate.
That is why you send a request to the CA for a certificate that you can use to further trust the
CA. You request a root CA certificate (that is, if there is only one CA in the PKI hierarchy) or a
certificate chain (that is, if there is a more complex PKI with a root at the top of the hierarchy
and then intermediate CAs, and issuing CAs below them). After you have the CA certificate or
the certificate chain, you know that you can trust the CA and that the CA can trust you.
Note It is very important that the certificate is imported into the Computer Certificates
Personal store. It will not work if it is in the User stores. You can check to see if the
certificates have been imported into the proper store by using the certutil –store MY
command. This command lists all certificates that are located in the Computer
Certificates Personal store.
Web Components Process for Consolidated Topology
For the more common topology (that is the consolidated configuration), you can use the same
certificate that you requested for the pool MTLS for TLS/SSL on the Web components. In this
Microsoft Corporation
27
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
process, you assign the same certificate and bind it to the binding for SSL. This is a less
complicated process than requesting and using a new certificate for the Web components.
For details and the procedure for Office Communications Server 2007 and Office
Communications Server 2007 R2, see:

Office Communications Server 2007 “3.7 Configure the Web Components Server IIS
Certificate” at http://go.microsoft.com/fwlink/?LinkId=161865.
 Office Communications Server 2007 R2 “Configure the Web Components Server IIS
Certificate” at http://go.microsoft.com/fwlink/?LinkId=161866.
Make sure that you assign the same certificate that you used for the Office Communications
Server pool, and that this certificate is being used for TLS/SSL purposes only (that is, because it
can be used for both MTLS and TLS/SSL). Unless you have made multiple certificate requests,
you should have only one certificate (that is, the pool certificate that you already assigned to the
pool) in the certificate store. Your goal in IIS is to associate the certificate with the Web server
and bind (by default, TCP/443) to the IIS server.
Web Components Request Process in an Expanded
Topology
If you want a separate certificate for the Web components or if you are deploying in an
expanded topology, this step is required to assign a certificate to the IIS Web sites created for
conferencing, address book service and all other services offered by the Web components on
the Front End Server. In a consolidated topology, you can select the same certificate that you
used for the pool. All of these services were deployed for you in IIS 6.0 (on Windows Server
2003) or IIS 7.0 (on Windows Server 2008).
Note The screen shots in the following section were taken on Windows Server 2008, so
it looks different from Windows Server 2003. However, the steps are similar.
Server 2003 IIS 6 Manager Process
If you have not worked with IIS very much, you may find that the request and processing of a
certificate is not as intuitive as it is in the certificate wizard. This section outlines how to request,
assign, and confirm that your certificate is in place for the Web components. The installation
wizard indicates that this is a manual process.
First, open the IIS Administrative tool, IIS Manager by clicking Start, Administrative Tools, and
then clicking IIS Manager.
Microsoft Corporation
28
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 13 Open IIS Manager and view server certificate properties
After you open IIS Manager, right-click the server name node and then click Properties. In the
Properties dialog box, click Server Certificate. On the Welcome to the Web Server Certificate
Wizard page, click Next.
What you do next will depend on whether you choose to deploy a consolidated or expanded
topology and if you have named the Internal Web Farm FQDN the same as your pool. If you
have chosen a consolidated topology and your internal Web FQDN is the same as the pool, click
Assign an existing certificate.
Figure 14 Assign an existing certificate
When you choose to assign a certificate, the Available Certificates page appears containing a list
of all applicable certificates. Choose the certificate that you requested and assigned to the pool
previously.
If, you are deploying an expanded topology or your internal Web FQDN is different from your
pool, click Create a new certificate.
Microsoft Corporation
29
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 15 Create a new server certificate
On the Delayed or Immediate Request page, select the option to use an offline (delayed)
request or the option to use an online CA. After you make your selection, you need to provide
typical information that is included on the certificate.
Figure 16 Specify certificate server name and settings
First, you provide the Friendly Name and then the key length. You are also given the option to
select a cryptographic service provider. If you choose not to select a provider, the default is the
most applicable provider for the certificate type that you are creating. The types that you can
choose are Microsoft DH SChannel Cryptographic Provider and Microsoft RSA SChannel
Cryptographic Provider. The difference between these two is that one (that is, DH) is based on
the Diffie-Hellman public key standards, while the other (that is, RSA) is based on the
Rivest/Shamir/Adleman public key standards. Unless you have a very specific reason for wanting
to change CSPs, stay with the default and do not select the Select cryptographic service
provider (CSP) for this certificate check box.
Type the required information in the appropriate fields. On the page that requests the common
name (CN), rather than the subject name, the common name is the same as the subject name
for our purposes. This is what the server is referred to in DNS. This is the most critical entry, and
naming this attribute incorrectly will render the certificate useless and the Web components
non-functional.
Microsoft Corporation
30
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 17 Select a certification authority (CA)
Finally, you need to select the online authority that you want to create the certificate. If you
have more than one online CA that can respond to this request, all of the available CAs will
appear in a drop-down list. Click the CA in the list, and then click Next. The next page tells you
that the certificate was created and installed on the server, which means that it has been
assigned to the proper purpose in IIS. After you close the page, you redirected to the properties
page for the Web site. To verify the certificate data, click View Certificate. You should have a
private key associated with this certificate.
Server 2008 IIS 7 Manager Process
For Server 2008, the difference between Create Certificate Request and Create Domain
Certificate is the same as the choice you made with the Front End Server certificate. If you have
a PKI in your Active Directory environment, Create Domain Certificate is a much easier process
and is the same as the online CA option. Create Certificate Request enables you to create the
CSR and then send it to an offline CA for processing.
In the wizard, you provide information about how you want to configure the certificate. Unlike
the Front End Server Certificate Request wizard, you need to provide the common name instead
of the subject name. For common name in the IIS Distinguished Name Properties, type the
FQDN of the server that you want your internal Web conference server to be known as. In the
example scenario, you use the name webfarm.contoso.com because you are using a
consolidated topology and you want a different certificate for the Web components.
Fill in the remainder of the fields with information similar to what you filled in the first request.
This information is part of the whole subject name (SN) in X.500 format.
If you are performing a Create Certificate Request, which is an offline request, and you click
Next, you select the cryptographic service provider and bit length. RSA is the default, so leave
this as is (that is, unless you have a good reason to change it). The bit length for the key is also
provided here, which you can change, if needed, but remember the caveats regarding key
length mentioned earlier in this document. Select the online CA that you intend to use for the
Microsoft Corporation
31
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
request. Otherwise, click Select to view the known and discovered online CAs in your network
and then click the appropriate CA. Finally, you can assign a Friendly Name to this certificate.
Remember that the Friendly Name is your chance to identify the purpose of this certificate in an
easy to remember and read format. To submit the certificate request, click Finish.
By default, only port 80 HTTP traffic is enabled. You need to create a new binding for port 443
HTTPS traffic. To do this, navigate to the Default Web Site, right-click the Default Web Site, and
then click Bindings or Edit Site\Bindings… in the context pane on the right. To create a new
binding for this site, click Add.
In the menu, click https, click All Unassigned (or the defined address if you know what it is
currently, which is a best practice) for IP address (this can be changed later if needed), and the
Port setting is set to 443 by default. Finally, you need to select the certificate that you just
created for use with the https binding. In SSL Certificate, click the same certificate that you
requested for the pool services or Web farm by the friendly name that you created in the
previous section, and then click OK to complete the binding. Click OK to close the dialog box and
then close IIS Manager.
Using the LcsCmd Command-line Tool
LcsCmd is installed by default as a part of the installation process on the Enterprise Front End or
the Standard server. It is part of the OCSCore.msi. There is a 32-bit set of tools that can you can
install on 32-bit clients and servers. This is important in situations where you need to request a
certificate or do other tasks, but you only have a 32-bit operating system available. The 32-bit
OCSCore.msi and supporting elements are located in <drive>:\ Support\i386 folder. You can
install these tools onto the target 32-bit server or workstation.
Digicert, a public CA vendor, has created a Web-based tool that you can use to input
information for your certificate, output the information from the tool, and then paste the
information into the command line for LcsCmd. Though this tool in not supported by Microsoft,
it is a simple method that you can use to ensure that your LcsCmd syntax and parameters are
correct, without having to wade through the myriad of options available to LcsCmd. The
following screen shot lists Office Communications Server 2007, but Digicert works just as well
for Office Communications Server 2007 R2. Notice that Digicert puts the SN/CN directly into the
subject alternative name as a first entry.
Microsoft Corporation
32
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 18 Use DigitCert to create syntax for LcsCmd
To use the Digicert tool, see “DigiCert's LCSCmd CSR Tool for OCS 2007” at
https://www.digicert.com/easy-csr/ocs2007.htm.
Instead of a wizard that prompts you for information, such as the CN/SN parameters, the CA to
use, or certificate assignment options, LcsCmd uses parameters that you input on the command
line.
If you prefer command line tools, you are interested in scripting much of your install, or if you
need to document the installation process by outputting logs of all installation actions, LcsCmd
is recommended. If you do not want to use the Installation Wizard, LcsCmd can perform all of
the same actions that you can perform by using the wizard. In this section, the focus is on how
to request and assign certificates for Office Communications Server 2007 and Office
Communications Server 2007 R2. For details about how to use LcsCmd to perform other
deployment and management tasks, see the following:

Office Communications Server 2007 R2 “Command Line Reference” at
http://go.microsoft.com/fwlink/?LinkId=161867.
 Office Communications Server 2007 R2 “Importing a CA Chain (Command Line)” at
http://go.microsoft.com/fwlink/?LinkId=161868.
To get help for LcsCmd, type the following at the command line: LcsCmd /?
LcsCmd help provides a list of all of the actions LcsCmd can control and manage. However, in
this scenario, certificate management is the focus, so the help syntax is: LcsCmd /cert /? This
Microsoft Corporation
33
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
command generates the command-line options for certificate management. For details about
the command-line options, see the following:


Office Communications Server 2007 “Managing Certificates for Office Communications
Server” at http://go.microsoft.com/fwlink/?LinkId=161869.
Office Communications Server 2007 R2 “Managing Certificate for Office
Communications Server 2007 R2 (Command Line)” at
http://go.microsoft.com/fwlink/?LinkId=161870.
Note The syntax examples used in this document apply to Office Communications
Server 2007 R2. The /assign: command-line option and /component: command-line
option do not exist in the Office Communications Server 2007 version of the tool.
As referenced in the Office Communications Server 2007 R2 Command Line Reference, the
Request parameter is the parameter that you need to create a certificate request. For LcsCmd,
you need to perform an Action. This means that you use the parameter /Action with the type
Request. The /assign command-line option is only available in Office Communications Server
2007 R2. By using the command line reference as a guide, you can request and assign a
certificate by using the following syntax:
LcsCmd /Cert /Action:request /online:true /assign:true /ca: ContosoDC.contoso.com\contoso-CONTOSO-DC-CA /caAccount:contoso\CAAdmin
/caPassword:P@ssword1 /friendlyname:“Contoso-FE Front End SIP” /sn:pool01.contoso.com
/OU: IT /org:Contoso /city:Redmond /state:Washington /country:US /san:*.contoso.com /L
To understand this command, see the following:








Lcscmd /Cert Specifies that LcsCmd work with certificate functions for Office
Communications Server.
/Action:request Specifies that LcsCmd create a key pair, and then create a certificate
request.
/online:true Specifies that LcsCmd use an online CA.
/Assign:true Specifies that LcsCmd assign the certificate after it receives the completed
request (this assumes that the CA is configured to automatically issue the certificate).
This is not available in the Office Communications Server 2007 version of the tool, and
TRUE is the default value.
/ca: Contoso-DC.contoso.com\contoso-CONTOSO-DC-CA Specifies that the certificate
request be issued to the named CA, in the format of machine name\CA instance name.
/caAccount Specifies that LcsCmd use the named account, in the form of
<CADomain\CAUser>, otherwise integrated authentication will be used.
/caPassword Specifies that LcsCmd use the stated password in conjunction with
caAccount (ignored if caAccount is not specified. You are not prompted for the account
and password if it is not specified. The request will fail if you do not have permissions).
/friendlyname:”Contoso-FE Front End SIP” Specifies that the user recognizable name
be assigned to the certificate (not used for the actual identity portion of certificate).
Microsoft Corporation
34
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2








/sn:pool01.contoso.com Specifies the subject name of the certificate. This should
match the FQDN of the machine or pool that the certificate is intended for as defined by
the A record in DNS.
/OU:IT Specifies the Organizational Unit for X.500 part of subject name.
/org:Contoso Specifies the Organization for X.500 part of subject name.
/city:Redmond Specifies the Location for X.500 part of subject name.
/state:Washington Specifies the State for X.500 part of subject name.
/country:US Specifies the Country/Region for X.500 part of subject name.
/san:*.contoso.com Specifies the subject alternative names for the certificate.
Multiple entries are comma separated. SN/CN is automatically added as the last entry in
the subject alternative name, unless /autoAppendSNtoSAN:FALSE is specified.
/L Creates a log file. Use this log to determine why something failed, or to confirm
success. By default, the log file is <tempFolder>\<ActionName>\[<Date>][<Time>].html.
Note By using the help system in LcsCmd, you can use LcsCmd /Cert /Action:request
/? to get a list of all parameters available in the certificate actions context.
Certreq – Custom Template Certificate Requests
The Certificate Wizard and LcsCmd are tools that you can use to ensure that you are getting
certificates properly for use with Office Communications Server. Because they are designed
specifically for Office Communications Server, they are able to hide some of the details from
you.
Certreq is different. This tool, provided by default with the Windows server and client operating
systems, is a general purpose tool and it does not hide anything. Certreq is neither easier to use
for Office Communications Server, nor is it best suited for most scenarios for deployments.
However, it is a great tool if you intend to script your deployments and require elements of
certificates that LcsCmd and the Wizard cannot provide, such as calling a custom template.
Neither the Certificate Wizard nor LcsCmd enable you to specify a specific template. They both
expect to find the default Web Server template on the CA.
Certreq is driven by command line parameters and an .inf file that passes information into the
tool. If you use an example of a company that has created a custom CA template called
“Contoso Secure Web Template” with a template name of “ContosoSecureWeb”, you can define
the .inf file and the command to generate the request, and then issue the next request to
retrieve the certificate from the CA and bind it to the private key that was created in the first
request.
Note By default, a Windows CA ignores requests for subject alternative name entries,
and does not indicate an error or failure to include the subject alternative name. It
simply ignores the entries. You need to enable subject alternative name entries by using
the following command, and then to stopping and restarting the CA services. You must
run this command for each issuing Windows Server CA.
Microsoft Corporation
35
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
certutil –setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
net stop certsvc && net start certsvc
You can verify that the settings have been applied by typing the following command at the
command line:
certutil –getreg policy\EditFlags
You are looking to verify that the flags are set properly, as in the following:
Figure 19 Confirm that the flags have been set for subject alternative name use on certification
authority
If you have reviewed the syntax for the Certreq input file as defined in Advanced Certificate
Enrollment and Management “Appendix 3: Certreq.exe Syntax” at
http://go.microsoft.com/fwlink/?LinkId=161862, you know that the amount of information and
the number of parameters for Certreq is daunting. It is somewhat difficult to define a default,
general purpose input file for Certreq. However, you can use an existing input file and make
changes to suit your purpose. For example, Knowledge Base article 931351, “How to add a
Subject Alternative Name to a secure LDAP certificate,” at
http://go.microsoft.com/fwlink/?LinkId=124340, provides an example input file. The input file
assumes that you have run the command that enables you to use subject alternative name
entries for Windows Server CAs. This template includes the Server EKU object identifier (OID)
and the name of the example custom template, which are the two extensions that are critical to
our needs when creating certificates for Office Communications Server and a CA with custom
templates.
Microsoft Corporation
36
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
By using the input file example from Knowledge Base article 931351 for this scenario, you can
modify the template to meet the specific needs in the Contoso domain, and for requesting a
certificate for the Front End Server, as follows:
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=pool01.contoso.com"
Exportable = FALSE
KeyLength = 1024
KeySpec = 1
KeyUsage = 0xA0
MachineKeySet = True
RequestType = PKCS10;
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
;Server Authentication
OID=1.3.6.1.5.5.7.3.2 ;Client Authentication
[RequestAttributes]
CertificateTemplate = CustomWebTemplate
SAN=”dns=*.contoso.com&dns=*.fabrikam.com"
Some of the parameters in the example input file are not required, but it is helpful to fully
understand them so that you know exactly what is requested. To understand what this specific
request file is doing, review the following:




[Version] Signature="$Windows NT$ Though this section is not required, if it is
included, there must be a signature statement. Currently, the only signature is
“$Windows NT$, and the lack of closing double quotes is not a typographical error. Use
it exactly as shown.
[NewRequest]
This section and header is mandatory for a new certificate request. If it
is not included you will get an error “INF file not found 0xE0000102 (INF: -536870654)”
returned from the parser.
Subject = "CN=pool01.contoso.com"
Specifies the subject name for the system that
you are requesting the certificate for.
Exportable = FALSE Specifies whether the private key is exportable or not. By default,
this value is FALSE. If you are creating a certificate request that is not the machine for
which this certificate is intended, such as an offline request for an Edge service,
Exportable should be TRUE, otherwise you will not be able to export the certificate and
the private key. Remember that if you are load balancing servers, Exportable should be
TRUE as well because you will likely copy this certificate to each of the servers in the
pool or load balanced group.
Microsoft Corporation
37
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2

KeyLength = 1024 Default length is 1024. This parameter sets the key size for the
public/private key pair. It increments by doubling the key length from 512 to 1024 to
2048, and so on. Maximum length is 16384, but Office Communications Server currently
can use up to a 4096 bit length, with the other caveats discussed earlier in this
document.
 KeySpec = 1
Specifies uses for the private key. Possible values are 1 = AT_EXCHANGE
or encryption and key exchange, 2 = AT_SIGNATURE meaning that the private key was
issued for signing. The default is 2, but generally a Web Server (or, more specifically
TLS/MTLS) needs the private key for encryption.
 KeyUsage = 0xA0 Default value is 0xC0. KeyUsage defines a bitmap that can be used
nine different ways, including the logical adding of values for multiple uses. Our choice
of 0xA0 indicates CERT_KEY_ENCIPHERMENT_KEY_USAGE equaling 0x20 and
CERT_DIGITAL_SIGNATURE_KEY_USAGE equaling 0x80. This allows the keys to be used
for both encryption and for digital signing. For the full listing of possible values, see
Advanced Certificate Enrollment and Management “Appendix 3: Certreq.exe Syntax” at
http://go.microsoft.com/fwlink/?LinkId=161862.
 MachineKeySet = True The default value is FALSE. This parameter defines if this
certificate and key pair are being created for the machine, and not the user. This
instructs Certreq to create the key material and store it in the machine store, and not
the store of the person running the command. For all purposes on Office
Communications Server, except for client software, the key must be in the machine
stores.
 RequestType = PKCS10 The default value for this parameter is PKCS10. It is used to
define the standard that should be used to generate and send the certificate request. If
you are running this from a machine that is creating a certificate for another machine
(for example, Edge services) you would want to use PKCS12 instead, which is a defined
format for certificate and private key export, and is usually a .pfx extension rather than
the more common .cer.
 [EnhancedKeyUsageExtension]
This section header is required for defining the
certificate’s purpose.
 OID=1.3.6.1.5.5.7.3.1 OID=1.3.6.1.5.5.7.3.2
Define the purpose of the certificate. In
this case the first is the Server EKU, the second the Client EKU. These must appear in the
request file each on a new line.
 [RequestAttributes]
This header must be included to define extra attributes to be
included in the certificate.
 CertificateTemplate = CustomWebTemplate There is no default value for this
parameter. If you have a custom template that has been created, specify the template
name, not the display name. “Web Server” is defined as WebServer.
 SAN=”dns=sip.contoso.com&dns=sip.fabrikam.com” There is no default for this
parameter. This allows you to define SAN entries to be included in the certificate. These
can be wildcard, DNS, URL, GUID, UPN, EMAIL, IPADDRESS or OID. String values must be
double quoted as shown.
Save this file as request.inf (or whatever name you choose) and then type the following
command at the command line on the Front End Server:
certreq –new request.inf poolcert.req
Microsoft Corporation
38
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Note You can specify a full path name for request.inf and the request file’s location
when you create it.
The command directs Certreq to create a request in the format noted in the RequestType field,
which is a Public Key Cryptography Standard # 10 (PKCS10) request in this scenario. Also, a
public and private key pair is created and placed in the local machine enrollment store. At this
point, you can either submit the request from the Front End Server or put the poolcert.req on
removable media and take it to the issuing CA, the Certificate administrator, or whatever
process might be in place. When you are ready to request the certificate, type the following
command:
certreq –submit poolcert.req poolcert.cer
Note You can specify a full file path name for the request file and the resulting .cer file.
If the user that is submitting the request has Read and Enroll permissions for the CA and the
stated template, after you successfully run the certreq – submit command, the certificate is
ready for use. Or, if you took this to the CA or someone else to run, you would then copy the
.cer file to removable media and transport it back to the Front End Server. Depending on the
policies in place on your CAs, it might be necessary for a CA administrator to approve the
request and release the certificate for retrieval before you can retrieve it.
After you have the .cer file on the Front End Server, type the following command to import the
certificate and to place it into the local machine store:
certreq –accept -machine poolcert.cer
This command also accomplishes the linking of the certificate to the key pair created in the
certreq –new step.
This completes the tasks necessary to use Certreq to create a key pair and a certificate request,
send the request to the CA, and then import the resulting certificate onto the server as a linked
certificate. Note that there are dozens of parameters and accepted options for the parameters
for the input file to Certreq. To determine what you may need or want, see Advanced Certificate
Enrollment and Management “Appendix 3: Certreq.exe Syntax” at
http://go.microsoft.com/fwlink/?LinkId=161862. The input file in this scenario is an example and
you should review it and modify it to meet your organization’s needs for creating and requesting
certificates for your Office Communications Server infrastructure.
Microsoft Corporation
39
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
2
1
Load Balanced
Director
Consolidated Pool
Figure 20 Enterprise Edition consolidated topology
Table 1 Legend for Figure 20 Enterprise Edition Consolidated Topology
Number
1
2
Friendly Name
Enterprise Front End
Director
DNS Entry
pool01.contoso.com
director.contoso.com
Common Name/
Subject Name
pool01.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com,
pool01.contoso.com
sip.contoso.com,
sip.fabrikam.com,
director.contoso.com
CA (Public/Private)
Private
Private
Notes
Install certificate on each
server in pool (if more than
one) Certificate is configured
in IIS Manager and installed
on each server, and subject
alternative name must
contain the URL of the Web
Components if different from
the pool name
Install certificate on each
server in pool (if load
balanced)
Microsoft Corporation
40
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
3
4
2
5
1
Expanded Pool
Load Balanced
Director
Figure 21 Phase 1: Enterprise Edition expanded topology
Microsoft Corporation
41
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Table 2 Legend for Figure 21 Phase 1: Enterprise Edition Expanded Topology
Number
1
2
3
4
5
Friendly Name
Front End
Web Conferencing
Web Components
Audio/Video Pool
Director
DNS Entry
pool01.contoso.com
webconf.contoso.com
webpool.contoso.com
avpool.contoso.com
director.contoso.com
Common
Name/ Subject
Name
pool01.contoso.com
webconf.contoso.com
webpool.contoso.com
avpool.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com,
pool01.contoso.com
NA
web.contoso.com,
webpool.contoso.com
NA
sip.contoso.com,
sip.fabrikam.com,
director.contoso.com
CA
(Public/Private)
Private
Private
Private
Private
Private
Notes
Install certificate on
each server in pool
Install certificate on
each server in pool
Certificate is
configured in IIS
Manager and installed
on each server, and
subject alternative
name must contain
the URL of the Web
Components if
different from the pool
name
Install certificate on
each server in pool
Install certificate on
each server in pool (if
load balanced)
Microsoft Corporation
42
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
2
1
Standard Edition Server
Director
Inner Firewall
Figure 22 Phase 1: Standard Edition server topology
Table 3 Legend for Figure 22 Phase 1: Standard Edition Server Topology
Number
1
2
Friendly Name
Standard Edition server
Director
DNS Entry
seserver.contoso.com
director.contoso.com
Common Name/
Subject Name
seserver.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com,
seserver.contoso.com
webcomponents.contoso.com
sip.contoso.com,
sip.fabrikam.com,
director.contoso.com
CA (Public/Private)
Private
Private
Notes
Certificate is also configured
in IIS Manager on server for
Web Components
Install certificate on each
server in pool (if load
balanced)
Phase 1 Summary
The phased approach outlined in this document is an example deployment rollout that an
enterprise might use to implement Office Communications Server. The phases break up the
deployment into manageable pieces that ensure a new, full set of features that enable an
enterprise (or, even a smaller organization) to realize the full potential of their infrastructure.
Microsoft Corporation
43
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The organization and content of these phases is based on actual Office Communications Server
deployment scenarios experienced in the field. Typically, a company would require that IT
deploy the pool(s) first, and then additional steps to accomplish external connectivity for
external users, audio/video and Live Meeting activities. Voice, monitoring, archiving, and
Communicator Web Access are all phases of deployment that require that some functions be
deployed previously.
In Phase 1, certificates were defined for the front end pool and the IIS Web services on the front
end. This phase is the base requirement for all other phases, considering a new implementation.
Migration scenarios might not follow this deployment phase exactly as it is outlined in this
document. Phase 1 allows for the internal users to use Office Communications Server for instant
messaging (IM), presence, Live Meeting, audio/video conferencing, and telephony for internal
use. In the following phases, more features will be added to enhance this already rich feature
set.
Phase 2 – Director
Phase 1 of the deployment covered the installation of the SQL Back End server and the first pool
Front End Server. Using the same three tools covered in Phase 1 (that is, the Installation Wizard,
LcsCmd, and certreq), you can define how to get the certificate for Phase 2 deployment. In
Phase 2, you can proceed more quickly to the point of getting and confirming the certificate
because most of the background work is complete for the certificate and CA/PKI details.
You deploy the Director by installing a Standard Edition server or an Enterprise Edition server,
deactivating the Web Conferencing, A/V Conferencing and Web Components server roles, and
configuring the server as the next hop server for SIP traffic. The Director is not required, but it is
highly recommended. For details about what the Director does and why it is recommended, see
Office Communications Server 2007 R2 “External Access Components” at
http://go.microsoft.com/fwlink/?LinkId=161871.
The certificate requirements for the Director are very simple in comparison to the pool or the
upcoming Edge services. Because the Director is joined to the domain, you can use your online
CA to request a certificate, and the CA root and chain is deployed automatically. However, if you
use public CA certificates (that is, you process these as offline requests and submit them to the
public CA), you need to obtain and install the root CA or the CA chain. Assignment is relatively
simple because there is only the one certificate.
Using the Certificate Wizard
To deploy the Director, see Office Communications Server 2007 R2 “Deploy a Director” at
http://go.microsoft.com/fwlink/?LinkId=162094. During the deployment, you are instructed to
obtain a certificate for the Director. The SN/CN for the certificate is the FQDN of the Director.
Microsoft Corporation
44
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Include any domains in the SAN of domains that you want the Director to redirect, in the format
of sip.<domain name> (for example, sip.fabrikam.com). After you define the properties of the
certificate, as you did for the properties of the certificates for the pool, submit the request and
assign the certificate.
This completes the certificate process for the Director.
If you have load-balanced Directors running on Enterprise Edition server, see the “Hardware
Load Balancer” section later in this document. In that situation, the certificate uses the SN/CN as
the name of the physical server that you are requesting the certificate for, and the subject
alternative name entries are the FQDN of the load balancer virtual IP of the Enterprise Edition
Director and a subject alternative name entry for each SIP domain that the Director is
responsible for. You enter these in the format of sip.contoso.com and sip.fabrikam.com. Each
Director requires its own certificate. By following these rules, you ensure a greater potential of
success the first time through the process.
LcsCmd
Like the certificate request for the pool, the process for requesting a certificate with LcsCmd is
straight forward.
The command that you run to request and assign a certificate for the Director is the same as the
command that you ran for the pool. The changes that you make are in the SN/CN fields, and
typically only the FQDN and friendly name of the target machine. The purpose of the subject
alternative name on the Director is to ensure that you are accounting for the SIP domains that
the Director and Office Communications Server is responsible for. Because the Director
performs a pre-authentication of the user to ensure that the account exists, and is enabled for
SIP and a domain that the Director is aware of, the certificate needs to define the SIP domains
too. And, because a Director can redirect users to another pool entirely (that is, again, serving a
different SIP domain) it must be able to identify and communicate with all pools it is responsible
for. To request and assign a certificate for the Director, run the following command at the
command line:
LcsCmd /Cert /Action:request /online:true /assign:true /ca:Contoso-DC.contoso.com\contosoCONTOSO-DC-CA /caAccount:contoso\CAAdmin /caPassword:P@ssword1
/friendlyname:”Contoso-Director SIP”/sn:director.contoso.com /OU: IT /org:Contoso
/city:Redmond /state:Washington /country:US /san:*.contoso.com, *.fabrikam.com /L
Note The /Assign command is only available in Office Communications Server 2007 R2.
Like our pool example, this command generates public and private keys, creates and sends a
certificate request for director.contoso.com, and assigns the certificate to the proper store on
receipt of the certificate response.
Microsoft Corporation
45
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Certreq
The example for using Certreq is almost the same as the example used previously in Phase 1.
You create and modify a request .inf file to provide the FQDN of the Director, specify a custom
template and the friendly name, and update the subject alternative name if needed. Then, you
run the commands to generate the key pair, submit the certificate request, and then accept and
assign the certificate.
The following example shows only the changed sections from the previous example in Phase 1:
[NewRequest]
Subject = "CN=director.contoso.com”
SAN=”dns=director.contoso.com&dns=*sip.contoso.com&dns=sip.fabrikam.com”
Using the.inf file containing the previous code, you run the three commands to create, retrieve,
and assign the certificate as follows:
certreq –new request.inf director.req
certreq –submit director.req director.cer
certreq –accept –machine director.cer
1
3
5
4
2
Reverse Proxy
Perimeter DNS
External Firewall
Inner Firewall
Figure 23 Phase 2: Summary
Microsoft Corporation
46
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Table 4 Legend for Figure 23 Phase 2: Summary
Number
1
2
3
Friendly Name
Director
Enterprise Front End
Standard Edition server
DNS Entry
director.contoso.com
pool01.contoso.com
seserver.contoso.com
Common Name/
Subject Name
director.contoso.com
pool01.contoso.com
seserver.contoso.com
SAN Entries
sip.contoso.com,
sip.fabrikam.com,
director.contoso.com
sip.contoso.com,
pool01.contoso.com
sip.contoso.com,
seserver.contoso.com
CA (Public/Private)
Private
Private
Private
Notes
Install certificate on each
server in pool (if load
balanced)
Install certificate on each
server in pool (if more than
one) Certificate is configured
in IIS Manager and installed
on each server, and SAN
must contain the URL of the
Web Components if different
from the pool name
Certificate is also configured
in IIS Manager on server for
Web Components
Microsoft Corporation
47
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Phase 2 Summary
The Director provides specific functionality that acts like a traffic policeman. The Director looks
at the traffic, determines if the traffic is from a known source and is for a known destination,
and allows it or blocks it based on SIP domain name allow and deny rules. It is capable of preauthenticating, or screening, traffic for external users who access the internal infrastructure
from the Edge Servers. In figure 23, the Edge Server is shown for reference only, and to anchor a
point of reference for the associated DNS records.
Because the Director is a recommended role, you can choose not to implement it, but the
benefits of adding another layer of screening, pre-authentication, and load reduction at the
pools makes it an easy choice to include in your design. And, certificate installation is easy to
accomplish on this server.
Phase 3 – External Access with Edge
Server Roles
Most enterprises require external user access to Office Communications Server, and provide
access for anonymous participants into Live Meetings. Edge Server roles provide external access
to Office Communications Server. The Edge Server roles provide a means of establishing instant
messaging, Web conferencing and Live Meeting, and Audio/Video communication. You must use
a reverse proxy to provide address book, group expansion, and Live Meeting content download.
Phase 3 outlines the steps that you need to take to ensure that the required certificates are
properly formatted, assigned, and functioning.
Access Edge Server, Web Conferencing Edge Server,
and Audio/Video Edge Server Roles
With the Edge Server role, you can provide access to your Office Communications Server and
Office Communications Server 2007 R2 infrastructure for remote employees, partners by using
federation, and Web conference access. Web conferences can be accessed by employees (that
is, in the Office Communications Server-connected Active Directory, and Office Communications
Server-enabled), federated partners (that is, by way of membership in the partner’s Active
Directory and Office Communications Server-enabled), and anonymous users. Audio/Video
services authentication and relay are also provided by the Edge Server.
If you are going to implement Web conferencing, you need a reverse proxy for the Web content
that is delivered by the Edge Server from the Web Conferencing Server role and Web
components on the Front End pool. The reverse proxy is also a vital component where the
address book service, group expansion, device and client updates are available for external
Microsoft Corporation
48
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
access. Content for these services does not exist on the Edge Server. The reverse proxy is a less
risky system because it does not manage and maintain data.
The reverse proxy is discussed separately from the Edge Server so that you can concentrate
specifically on the Edge Server roles.
Note The Access Edge Server role is the single most misconfigured role. Pay special
attention to your DNS naming, certificate CN/SN naming, and FQDNs of the Edge and
pool servers. Ensuring that there is consistency and parity among these three elements
will dramatically lower the likelihood of difficulty for MTLS communications from the
Edge Server to the pool.
Use the Edge Planning Tool to assist you in defining your requirements. The Edge Planning Tool,
in addition to walking you through your configuration and asking questions to determine what
your configuration should be, identifies and provides guidance as to what your certificate
naming and subject alternative name structure should be. To download the tool, see the
following:

Microsoft Download Center “Edge Planning Tool for Office Communications Server 2007
R2” at http://go.microsoft.com/fwlink/?LinkId=161872.
 Microsoft Download Center “Edge Planning Tool for Office Communications Server
2007” at http://go.microsoft.com/fwlink/?LinkId=161873.
Certificates are required for the Access Edge Server, the Web Conference Edge Server, and the
A/V authentication service. The actual media for audio and video is protected by the Secure
Real-Time Protocol (SRTP) and does not use a certificate to protect the traffic. Only the
authentication of user access to the A/V services requires a certificate. There is a required
certificate that is assigned to the internal facing interface of the Edge Server. This certificate is
responsible for encrypting communication for the edge internal interface to the internal
network and pool or Director. This certificate also performs mutual authentication with the
intended next hop server (that is, pool or Director).
It cannot be stressed enough that using a subject name wildcard certificate for the Edge Server
is not a supported scenario. As you will find, you only need three public certificates because the
A/V edge can be a private certificate. And, the Access Edge Server that supports the access
proxy for SIP is the only one of the three servers that needs subject alternative name entries,
and only if you are going to support automatic configuration.
You should be aware that using a single certificate is not a recommended practice for the Edge
Server. By using a dedicated certificate per role, you increase the security of the Edge Server
roles by reducing the likelihood that an attacker can compromise one key pair, thereby
compromising all keys on the Edge Server.
And, as mentioned earlier, public CAs and your internal CA can create wildcard SN/CN
certificates, but they are neither reliable nor supported. It is recommended that you do this
right the first time and avoid the potential for serious issues in the future by not trying to use a
Microsoft Corporation
49
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
certificate that uses a wildcard SN/CN, such as *.contoso.com, to define the three Edge Server
services.
Using the Certificate Wizard
For Edge Server certificates, you run the wizard from the Edge Server. Because three of the Edge
Server roles are Internet facing, you need to use public CA certificates for the Access and Web
Conferencing Edge Server roles. Also, the external facing interface (or potentially the only
interface) in your proxy server should be a public certificate as well. If you choose not to use
public certificates, challenges that can be very hard to manage may arise. The main challenge is
that each of the clients that connect to your external interfaces need to have the root CA
certificate or the CA chain from the PKI that you issue the certificates from internally. If you use
a public CA, it is likely that your client systems already have the necessary CA certificates, and
even if they do not the certificates are much easier to obtain.
This scenario does not mention the audio/video edge because an authentication service is
offered for A/V and it does not actually interact with a client. You can use a certificate from your
internal PKI or CA for this Edge Server service.
For details about Edge Server deployment, see:

Office Communications Server 2007 “Office Communications Server 2007 Edge Server
Deployment Guide” at http://go.microsoft.com/fwlink/?LinkId=133015.
 Office Communications Server 2007 R2 “Deploying Edge Servers for External User
Access” at http://go.microsoft.com/fwlink/?LinkId=143690.
For Unified Communications, which includes Office Communications Server, Office
Communications Server 2007 R2, and Microsoft Exchange Server, there are specific public CA
vendors that format their certificates and subject alternative names properly to work with
Microsoft Unified Communications servers. For a list of approved public CAs and instructions for
how to submit requests to them, see Knowledge Base article 929395, “Unified Communications
Certificate Partners for Exchange 2007 and for Communications Server 2007,” at
http://go.microsoft.com/fwlink/?LinkId=140898.
Edge Server Certificate Requests
The wizard walks you through the request process by asking you the same questions covered in
the “Phase 1 – SQL Server Backend and Enterprise Pool or Standard Server” section of this
document. The first certificate is for the Access Edge Server, and the certificate services Session
Initiation Protocol (SIP) requests from external sources.
In the wizard, after you have deployed the files and have initially installed the Edge Server, you
come to a step that contains Configure Certificates for the Edge Server. To begin, click
Configure Certificates for the Edge Server. For details about how to proceed, see Office
Microsoft Corporation
50
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Communications Server 2007 “Step 3.6. Set Up Certificates for the External Interface” at
http://go.microsoft.com/fwlink/?LinkId=161874 and Office Communications Server 2007 R2
“Set Up Certificates for the External Interface” at
http://go.microsoft.com/fwlink/?LinkId=142207.
Access Edge Server
When you make a request for the Access Edge Server, you are requesting a MTLS certificate that
enables mutual authentication and encryption of SIP traffic. The service that uses the certificate
is a component of the Edge Server called the RTCSrv service, which is in the Services applet
under Office Communications Server Access Edge.
Certificate Wizard – Access Edge Server
The Access Edge Server certificate uses a SN/CN that is the FQDN in the external DNS that clients
use to refer to the edge service. For example, the FQDN in this scenario is sip.contoso.com. The
sip host portion of the FQDN is a recommendation based on fallback when SRV lookups fail.
Your external DNS is going to have specific SRV records for client auto-configuration that are
anchored to this DNS A record. Using the “sip” FQDN prefix as a consistent practice simplifies
some situations where the client and server software can resolve the issue. You also need to
request that the certificate be defined with the exportable key option if you are using or plan to
use load balancers. Subject alternative name entries are also applicable for the Edge Server (for
example, access.contoso.com or sip.fabrikam.com) to comply with multiple SIP domains in your
environment. However, remember that wildcard SN/CN certificates are not acceptable or
supported for use on the Access Edge Server.
After you finish the request, send the request to your chosen public CA provider.
Your request to the public CA will look like the following:
-----BEGIN NEW CERTIFICATE REQUEST-----.
MIIEkAYJKoZIhvcNAQcCoIIEgTCCBH0CAQMxCzAJBgUrDgMCGgUAMIIDbQYIKwYB
<portion removed for brevity>
gwF5MbmOqBCgo8z8cz8FnC8vRIDNwXor/KxFskmo9RVBsks4/YbXLi7CWvA/2WvD
QuswDen15VKHjH/Hhsmdj0rOnbU=
-----END NEW CERTIFICATE REQUEST----------.
It has been reported that if you run the certificate wizard in Office Communications Server 2007
R2 on Windows Server 2008, you receive outputs where the encoded CSR is missing the BEGIN
NEW CERTIFICATE REQUEST header and the associated footer. Many CAs do not require this
Microsoft Corporation
51
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
portion, but you might encounter a situation where a CA requires the header and footer in the
CSR.
After you receive the certificate, re-run the wizard to assign the certificate (typically retrieved
from the public CA in a .cer, .pfx, or .p7b file) the appropriate interface.
Most CAs accept either the entire code, from the beginning dash preceding BEGIN NEW
CERTIFICATE REQUEST to the final dash following END NEW CERTIFICATE REQUEST, or just the
Base 64 coded portion between the header and footer sections. Be sure that you understand
which format your chosen CA requires.
LcsCmd – Access Edge Server
LcsCmd uses the same syntax explained previously in this document, with a couple of
modifications. First, there is no online CA to send the request to, so you want to save the
request to a file. Next, you are working with the Edge Server, which has a potential for 4
certificates, and you need to inform LcsCmd how to assign that certificate after you get it. Also,
the command is run in two parts instead of just one. The first command string requests the
certificate and the second command string assigns it.
Note The filename parameter holds a path and a name for the request and response
file (on the ImportResponse). The path must exist, or else the command fails.
LcsCmd /cert /action:request /friendlyname:”Access Edge” /sn:sip.contoso.com /ou: IT
/org:Contoso /city:Redmond /state:Washington /country:US /san:sip.contoso.com,
sip.fabrikam.com /fileName:”C:\CertHold\accessedge.req” /L
After you have successfully submitted your request and have received the CA response from the
public CA, save the response file to a known path. Next, you run an assign command through
LcsCmd to put the certificate into the proper store on the Edge Server.
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\accessedge.cer” /assign
/Components:AP /L
The /Components parameter indicates that the Access Proxy is the component that the
certificate will be assigned to. The /Components and /Assign parameters are not available in
the Office Communications Server 2007 version of LcsCmd. In Office Communications Server
2007, you need to issue an additional command to import the received and signed certificate,
and then assign it to the correct role.
In Live Communications Server documentation, the components of the Edge services are
referenced throughout, but by different names. The Access Edge service or RTCSrv is known as
the Access Proxy (AP). The Web Conferencing Edge is known as the Data Proxy (DP). The A/V
Edge services are known as the Media Relay (MR) and the Media Relay Authentication Service
(MRAS).
Microsoft Corporation
52
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Certreq – Access Edge Server
Certreq operates in the same manner as discussed previously in this document. You use the
same input file to direct the request behavior, except that you need to change the identifying
features of the certificate request, receipt and import.
For the Access Edge Server, you change the basic .inf are as follows:
[NewRequest]
Subject = "CN=sip.contoso.com"
SAN="dns=sip.contoso.com&dns=sip.fabrikam.com"
In this scenario, you do not submit the request to an online CA, but a public CA. You save the
request file to a file, and then you copy the request to the method of certificate request dictated
by the public CA. However, you still need to create a request and then accept the resulting CA
response by running the following command at the command line:
certreq –new request.inf accessedge.req
certreq –accept –machine accessedge.cer
Web Conferencing Edge Server
For the Web Conferencing Edge Server, you request a certificate to provide MTLS authentication
and encryption for meetings and meeting content. The data is managed by a service called the
RTCDataProxy and it uses Persistent Shared Object Model (PSOM) traffic from Live Meeting
external clients.
Certificate Wizard – Web Conferencing Edge Server
For the Certificate Wizard, you follow the same instructions as you did for the Access Edge
Server, with the exception that you create and request a certificate from a public CA for the
Web Conferencing Edge Server. Create your request, submit, and receive the certificate from
the public CA, and then re-run the installation wizard to assign the certificate to the Web
Conferencing Edge Server.
LcsCmd – Web Conferencing Edge Server
For LcsCmd, you use the same command syntax that you used to request a certificate for the
Access Edge Server. However, the components parameter is different. Recall that /Assign and
/Components are not available in Office Communications Server 2007 LcsCmd. To request a
certificate, run the following command at the command line:
Microsoft Corporation
53
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
LcsCmd /cert /action:request /friendlyname:”Web Conference Edge”
/sn:webconf.contoso.com /ou: IT /org:Contoso /city:Redmond /state:Washington
/country:US /fileName:”C:\CertHold\webedge.req” /L
Then, respond to the received certificate as follows, using the DP to indicate Data Proxy:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /assign:true
/Components:DP /L
Certreq – Web Conferencing Edge Server
For the Web Conferencing Edge Server, you change the .inf file as follows:
[NewRequest]
Subject = "CN=webconf.contoso.com"; must be the FQDN of Web Conferencing service name as
represented in DNS
You use the same command for Certreq to create the request, request the certificate from a
public CA, and accept it. Run the following command strings at the command line:
certreq –new request.inf webconf.req
certreq –accept –machine webconf.cer
Audio/Video Authentication Edge Server
The A/V Edge Server requires some explanation to really understand what you are assigning a
certificate to and what that certificate really does. There are actually two services that partner
to accomplish external A/V connectivity and media transport. The first is the RTCMEDIARELAY
service, which does the real work for the A/V functions. This service does not have a certificate
associated with it. Media streams in and out of the Enterprise by passing through the media
relay service. The data is secured by Secure Real-time Transport Protocol (SRTP).
The second service is the RTCMRAUTH service, commonly referred to as Media Relay
Authentication Service (MRAS). MRAS uses the assigned certificate for two purposes: a TLS
connection for SIP traffic and a bank/authentication certificate used to create session keys that
authenticate the client to the media traffic.
The TLS capability of the certificate is used when a secure TLS connection is established by the
Office Communications Server infrastructure to the MRAS server. This secure connection is used
by MRAS to handle SIP service request/response transactions from the Office Communications
Server infrastructure. This request/response transaction carries the user name and password
(that is, authentication tokens) that are you need to access the A/V Edge Server.
Microsoft Corporation
54
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The authentication or bank certificate is used to create shared secrets that you need to
construct the user name and password handed out by MRAS in the SIP service request/response
transaction. These credentials are used during ICE connectivity checks to authenticate with the
A/V Edge server using the ICE/STUN/TURN protocol (that is, over both TCP 443 and UDP 3478).
These credentials are not used for encryption in any way. They are only used for authentication.
After the A/V Edge Server has authenticated the client, it allocates a publicly accessible port that
the client may use for the transport of media streams, which is then handled by the Media Relay
service.
Unlike the roles previously discussed, the A/V Edge Server certificate can be a private CA
certificate because it only communicates with the internal Office Communications Server
architecture in SIP and provides client negotiation for potential candidates. It never
communicates with external systems or clients. Because this server is not a joined to a domain,
you need to explicitly install a certificate CA chain. Unlike domain-joined machines (that is, the
Edge Servers are actually in a Workgroup), the Edge Servers do not get the CA chain natively.
Certificate Wizard – A/V Authentication Edge Server
The Certificate Wizard process is essentially the same as previously discussed for the other two
Edge Server roles. The wizard walks you through the process of creating your request and then
you send the request off to the public CA. After you receive the certificate response file, you rerun the wizard to import and assign the certificate.
LcsCmd – A/V Authentication Edge Server
For LcsCmd, the command syntax is similar to the syntax used previously for Access Edge Server
and Web Conferencing Edge Server. Run the following command at the command line:
LcsCmd /cert /action:request /friendlyname:”AV Edge” /sn:av.contoso.com /ou: IT
/org:Contoso /city:Redmond /state:Washington /country:US
/fileName:”C:\CertHold\avedge.req” /L
And then, run the following command at the command line:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /assign:true
/Components:MR /L
Note the change in component name to MR for the A/V authentication Edge role. The /Assign
and /Components switches are not available in the Office Communications Server 2007 version
of LcsCmd.
Although it is potentially cheaper and easier to manage one certificate versus three certificates,
it is not a good security practice to use the same certificate for all of your external Edge Servers.
The A/V Edge Server is responsible for authentication and creation of session keys for media
Microsoft Corporation
55
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
streams. By assigning the same certificate to each interface, you lessen the ability of that
interface to be properly secured. Remember that the authentication service is responsible for
generating and sending session keys to A/V candidates. Encrypting the keys with a shared
certificate heightens the potential for compromise as there is more information available for an
attacker to determine the encryption key and therefore the session key. This is not a supported
practice.
As mentioned previously in this document, wildcard SN/CN certificates are not supported. And,
the above scenario cannot be accomplished without a wildcard subject name and a series of
subject alternative name entries for the required interfaces. The best guidance is to do this right
the first time and use separate certificates from the start.
Certreq – A/V Authentication Edge Server
When you use Certreq to request the A/V certificate, you change the subject name part of the
.inf file. Also, there is no need for a subject alternative name because this field is not used for
this certificate. Make the following changes in the .inf file:
[NewRequest]
Subject = "CN=av.contoso.com" ; must be the FQDN of Audio/Video authentication server in
DNS
You have a choice of where you can request this certificate from: either can be a public CA or
from your internal PKI. Either way, you are likely to be making an offline request. Keep this in
mind as you proceed. Run the following commands at the command line:
certreq –new request.inf avedge.req
certreq –accept –machine avedge.cer
Edge Server Internal Edge
The internal edge of your Edge Server needs a certificate as well to authenticate and encrypt
traffic to and from the next hop server. The next hop server might be a Director or the pool(s).
Using the Certificate Wizard – Edge Server Internal Edge
The wizard walks you through the process of requesting a certificate for the internal edge. This
certificate can be generated by and retrieved from your internal infrastructure CA, which
reduces the cost of certificates. This certificate can be a public CA certificate too. In this
scenario, you typically use the offline request process because your Edge Server is usually
located behind a firewall in the perimeter network. Unless you request the certificate before
you locate it in the perimeter, it is likely that the firewall is not going to allow the necessary
traffic to submit and retrieve a certificate. Because of this, the offline request is addressed in
Microsoft Corporation
56
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
this section. If you are able to use the online request process, see the previous sections of this
document where the process was covered in relation to the pool or Director. The process is the
same here.
Start the wizard and walk through the process for creating your internal edge certificate. Name
it appropriately, with a friendly name, and then save the request. Submit the certificate signing
request to either you internal CA or to a public CA. After you receive the certificate response, rerun the wizard, accept and import the certificate, and assign it to the internal edge.
LcsCmd – Edge Server Internal Edge
The process for LcsCmd is essentially the same as described previously in this document. There
are changes to some of the parameters. Also, depending on the accessibility of your internal CA
(or if you have chosen to use a public CA), you still save the request to a file. Recall that /Assign
and /Components are not available in Office Communications Server 2007 LcsCmd. Run the
following command at the command line:
LcsCmd /cert /action:request /friendlyname:”Internal Edge” /sn:internaledge.contoso.com
/ou: IT /org:Contoso /city:Redmond /state:Washington /country:US
/fileName:”C:\CertHold\internaledge.req” /L
And, run the following command to receive and assign the certificate as follows:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /assign:true
/Components:INTERNAL /L
Certreq – Edge Server Internal Edge
The procedure for Certreq follows the same defined template previously discussed to generate,
submit, retrieve, and assign your certificate for the internal edge. Make the following changes in
the .inf file:
[NewRequest]
Subject = "CN=internaledge.contoso.com" ; must be the FQDN of Internal facing edge
interface in DNS
And, then submit and act on the request by running the following commands at the command
line:
certreq –new request.inf internaledge.req
certreq –submit internaledge.req internaledge.cer
certreq –accept internaledge.cer
Microsoft Corporation
57
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Reverse Proxy Server
The reverse proxy server enables Live Meeting external users to connect to your Web
Conferencing servers, and to the content that is stored there for use during and after the
meeting. It also enables users to retrieve the address book, expand a group, and download
device updates. The purpose of the proxy server is to provide a logical separation of external
requests from content stored on internal server locations. In a security context, requests from
the proxy server are trusted more than a request from client or server systems on the Internet.
Configure a Reverse Proxy
Though there are a number of devices and servers that can act as a reverse proxy, this section
covers specific certificate requirements relating to Microsoft Internet Security and Acceleration
(ISA) Server 2006 with Service Pack 1 (SP1). Refer to the documentation for your proxy server,
firewall, or device to understand how the following information pertains to your environment.
Important You need to apply SP1 to ISA Server 2006. If you do not or you are unable
to, there are known issues with subject alternative name entries on certificates that are
applied to ISA 2006.
If you did not configure an external Web Farm FQDN during the configuration of your pool, see
Office Communications Server 2007 R2 “Configure a Reverse Proxy” at
http://go.microsoft.com/fwlink/?LinkId=161876. You cannot configure this through the wizard
or the Office Communications Server administrative interface, but you can do this with an
LcsCmd command string.
This scenario assumes that there are two network interfaces in the ISA Server, an externally
facing and an internally facing network interface card (NIC). However, it is possible to use a
single interface in an ISA Server dedicated as a Web proxy. For details, see Forefront Edge
Security “Configuring ISA Server 2004 on a Computer with a Single Network Adapter” at
http://go.microsoft.com/fwlink/?LinkId=161875. Although this refers to ISA Server 2004, it also
applies to ISA Server 2006.
LcsCmd – Reverse Proxy
Because the wizard does not provide for a means to request and process a certificate for the
reverse proxy, in this scenario you use only LcsCmd and Certreq to obtain the certificates. You
can use the process discussed previously to request and receive certificates for other machines,
using the process outlined in the “Requesting a Certificate from Another Machine” section
earlier in this document.
Microsoft Corporation
58
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The reverse proxy uses an SSL/TLS certificate. As a result, the Server EKU is not necessary in this
scenario. However, as with the Client EKU, if you include the Server EKU, the certificate does
operate properly.
You can run this request from the reverse proxy so that the keys are generated and bound on
the reverse proxy. This does mean that you need to copy over the LcsCmd.exe and support files
to the reverse proxy. This can cause a minor problem because Office Communications Server
2007 R2 runs only on x64 servers, while ISA Server runs on x86. To resolve this, on the Office
Communications Server media, install the vcredist_x86.exe (that is, Visual C Redistributable for
x86) from the <media drive>:\Support\i386 directory. From the same directory, copy
LcsCmd.exe, LcDeployR.dll, and LCTaskHandler.dll to a directory that you create to hold the
three files. Now, you can run LcsCmd, as long as the .exe and two .dlls are in the same directory
and you have installed the VC x86 redistributable. After you are done configuring the
certificates, you can remove the three files and uninstall the redistributable, if your Security
processes require it. It is more secure to use a workstation, as mentioned earlier in this
document.
If you are using LcsCmd and supporting files, run the following command at the command line:
LcsCmd /cert /action:request /friendlyname:”Web Proxy External” /sn:ocsweb.contoso.com
/ou: IT /org:Contoso /city:Redmond /state:Washington /country:US
/fileName:”C:\CertHold\webproxyext.req” /L
Send the resulting request file to your CA provider using whatever offline means you have
defined.
The SN/CN is the FQDN by which your reverse proxy is known to your external users through
DNS. This might be the published external domain maintained by an Internet Service Provider
(ISP) or on your perimeter-based DNS.
After you have received the signed certificate, run the following command at the command line
to import the certificate:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /L
From here, you use the ISA Server publishing rules wizard to assign the certificate to the SSL
listener that is publishing the internal Web content.
Certreq – Reverse Proxy
The procedure for Certreq follows the same defined template previously. Make the following
changes in the .inf file:
[NewRequest]
Subject = "CN=ocsproxy.contoso.com" ; must be the FQDN of the reverse proxy in DNS
Microsoft Corporation
59
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Run the following commands to submit, retrieve and import the certificate:
certreq –new request.inf ocsproxy.req
Copy the request file, output above, to removable media and then take it to a machine that is
able to send the request to the public CA. Run the following command at the command line:
certreq –submit ocsproxy.req ocsproxy.cer
After you receive the signed certificate from the CA, submit it to the proxy by running the
following command at the command line:
certreq –accept ocsproxy.cer
In this scenario, you are only installing a single certificate for the Web publishing rule, even
though there are two interfaces. You are not using the HTTP inspection component of ISA Server
2006, so there is no need to establish an SSL bridge and a second certificate. If this is something
that you require, see the ISA Server 2006 documentation “Microsoft Internet Security and
Acceleration (ISA) Server 2006” at http://go.microsoft.com/fwlink/?LinkId=161877.
2
1
Standard Edition Server
Director
Figure 24 Phase 3: Consolidated Edge
Microsoft Corporation
60
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Table 5 Legend for Figure 24 Phase 3: Consolidated Edge
Number
1a
1b
1c
2
3
4
Friendly Name
Consolidated
Access Edge
Server
Consolidated Web
Conferencing
Audio/Video
Authentication
Service
Edge Internal
Reverse Proxy
Director
DNS Entry
Perimeter DNS
sip.contoso.com
Perimeter DNS
webconf.contoso.c
om
Perimeter DNS
av.contoso.com
Internal DNS
internaledge.conto
so.com
Perimeter DNS
ocsproxy.contoso.
com
Internal DNS
director.contoso.c
om
Common
Name/ Subject
Name
sip.contoso.com
webconf.contoso.c
om
av.contoso.com
internaledge.conto
so.com
ocsproxy.contoso.
com
director.contoso.c
om
SAN Entries
sip.contoso.com,
sip.fabrikam.com
Not applicable
Not applicable
Not applicable
Not applicable
sip.contoso.com,
sip.fabrikam.com,
director.contoso.c
om
CA
(Public/Private)
Public
Public
Private
Private
Public
Private
Microsoft Corporation
61
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
2
1
Consolidated
Pool
3
Edge Server
Director
Standard Edition
Server
Inner Firewall
Figure 25 Phase 3: Scaled single-site edge
Microsoft Corporation
62
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Table 6 Legend for Figure 25 Phase 3: Scaled Single-Site Edge
Number
1a/3a
1b/3b
1c/3c
2/4
5
Friendly Name
Load Balanced
Access Edge
Load Balanced Web
Edge
Load Balanced AV
Authentication Edge
Internal Edge Interface
Reverse Proxy
Listener for Web Edge
DNS Entry
Perimeter DNS
sip.contoso.com (VIP
of HLB)
Perimeter DNS
webconf.contoso.com
(VIP of HLB)
Perimeter DNS
av.contoso.com
Internal DNS
internaledge.contoso.com
(VIP of HLB)
Perimeter DNS
ocsproxy.contoso.com
Common
Name/ Subject
Name
sip.contoso.com
webconf.contoso.com
av.contoso.com
internaledge.contoso.com
ocsproxy.contoso.com
SAN Entries
sip.contoso.com,
sip.fabrikam.com
Not applicable
Not applicable
Not applicable
Not applicable
CA
(Public/Private)
Public
Public
Private
Private
Public
Notes
One certificate per
server, noting VIP is
the SN/CN
One certificate per
server, noting VIP is
the SN/CN
Copy of the first
cert, with duplication
of certificate and
public key to each
AV Auth server
(MRAS)
One certificate per
server, noting VIP is the
SN/CN
Microsoft Corporation
63
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Phase 3 Summary – External Access with Edge Server
Roles
The Edge Servers provide specific services to allow external users (that is, domain, federated
and anonymous users) access to your internal Office Communications Server infrastructure. As
any server in the perimeter, the Edge servers provide a vital function by separating external and
internal traffic.
The certificate process on these servers can be complex, but the way that it has been broken
down in this section should simplify the complexity. This section outlines what certificates are
needed, where they need to be acquired, and what information they need to contain. And, this
section also covers the importance of considering a split DNS architecture to segment perimeter
DNS lookups from internal and external. Lastly, this section looks at the reverse proxy, which is
necessary for Address Book retrieval, group expansion, and content access when users are
outside of your internal infrastructure.
Phase 4 – Voice Services
Office Communications Server 2007 and Office Communications Server 2007 R2 have very rich
voice capabilities. Rather than invent a system that enables users to retrieve voice mail from any
number of devices, Office Communications Server uses Exchange and the advanced e-mail
handling capabilities to provide a fully featured voice mail capability. In addition, there are
methods to connect basic voice gateways, hybrid gateways, IP-PBX, and SIP trunks into the
Office Communications Server system. This provides a great deal of flexibility, and allows for the
re-use of existing technologies.
Exchange Unified Messaging
Exchange Unified Messaging (Exchange UM) provides voice mail and e-mail capabilities. The
existing self-signed certificates normally retrieved for Exchange processes are not applicable
when you integrate it with Office Communications Server. As a result, you need to acquire fully
provisioned certificates for Exchange UM.
To implement certificates for Exchange UM, see Office Communications Server 2007 R2
“Configuring Certificates on the Server Running Microsoft Exchange Server 2007 Unified
Messaging” at http://go.microsoft.com/fwlink/?LinkId=161878.
You need to request a certificate that requires server authentication. After you install it, you
need to run the Microsoft® Windows PowerShell™ Enable-Exchange Certificate cmdlet through
the Exchange Server. This is an Exchange cmdlet, not an Office Communications Server cmdlet.
Microsoft Corporation
64
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
For details, see Exchange Server 2007 “Enable-ExchangeCertificate” at
http://go.microsoft.com/fwlink/?LinkId=161879.
Mediation Server
For Enterprise Voice, the Mediation Server acts as the connection to communicate with all other
Office Communications Servers.
For details about installing and configuring the Mediation Server through the wizard, see Office
Communications Server 2007 R2 “Configuring a Certificate for Mediation Server” at
http://go.microsoft.com/fwlink/?LinkId=161880.
Note that there is no need for any subject alternative name entries. The SN/CN is the only
certificate parameter that is referenced.
Also, this document does not cover specific certificate requirements for the Mediation Server’s
connection to the gateway due to the wide range of certificate use on gateways. If you do find
that your gateway can use a certificate, see Office Communications Server 2007 R2 “Step 5.
Deploy a Mediation Server” at http://go.microsoft.com/fwlink/?LinkId=161881.
You can deploy a Mediation Server with one or two network interfaces. However, there is a
known issue that might occur if the NIC or NICs are provisioned for the same network. Verify
that the NIC or NICs are configured on different IP networks. These networks do not have to be
physically separate, but must be logically separate. The symptoms include voice communication
working only in one direction, or failing completely.
The problem stems from the fact that, given the right conditions, the return packets are
stamped for the wrong interface, or would leave over the proper interface with the other
interface’s IP stamped into the Session Description Protocol (SDP) message. This results in
invites responding to the wrong address completely. If you decide to use a single interface with
only one IP address, this works fine. However, you need to be cautious because communication
from the Mediation Server to the pool is designed to be secured with MTLS, and traffic to the
media gateway can be left as unencrypted SIP.
The documentation for the Mediation Server does indicate that the preferred method is to use
two separate network cards in the Mediation Server. Each NIC must be on a different logical
network. If you follow this advice, you can implement the Mediation Server as the
documentation intended.
For details, see PointBridge blog article, “OCS Mediation Server NIC Configuration,” at
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=55.
Microsoft Corporation
65
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
LcsCmd – Mediation Server
Follow the same procedures that you have used for other internal server roles to request,
submit, and retrieve a certificate. Make sure that you are also requesting and installing the CA
certificate chain (that is, if it is not already in place) because the Mediation Server is a domain
member. Run the following command at the command line:
LcsCmd /cert /action:request /online:true /friendlyname:Mediation Server
/sn:mediation.contoso.com /ou: IT /org:Contoso /city:Redmond /state:Washington
/country:US /fileName:”C:\CertHold\mediation.req” /L
The SN/CN is the FQDN by which your Mediation server is configured for resolution through
DNS. Import and install the certificate by running the following command at the command line:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /assign:true
/L
Import and install the chain file by running the following command at the command line:
LcsCmd.exe /Cert /Action:ImportCAChain /Filename:CAChain.p7b
Certreq – Mediation Server
Certreq is very important for those situations where you have a CA that has custom templates
that you are required to use.
Certreq uses the same input file format and runs the same commands. The input file might
reflect these changes from the one presented in the section on the pool certificate request
earlier in this document. Make the following changes in the .inf file:
[NewRequest]
Subject = "CN=mediation.contoso.com" ; must be the FQDN of Mediation server name in DNS
And, later in the file:
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
; Server Authentication
[RequestAttributes]
CertificateTemplate = CustomWebTemplate ; Name of the custom template to use
To submit and process the request, run the following commands at the command line:
certreq –new request.inf mediation.req
certreq –submit mediation.req mediation.cer
Microsoft Corporation
66
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
certreq –accept mediation.cer
2
1
Office Communications
Server Pool Deployment
PSTN
PBX
Media
Gateway
Mediation
Server
Figure 26 Phase 4: Mediation Server
Table 7 Legend for Figure 26 Phase 4: Mediation Server
Number
1
2
Friendly Name
Mediation Server
Front End Pool - SIP
DNS Entry
mediation.contoso.com
sip.contoso.com
Common Name/
Subject Name
mediation.contoso.com
sip.contoso.com
SAN Entries
Not applicable
sip.contoso.com,
sip.fabrikam.com,
access.contoso.com
CA (Public/Private)
Private
Private
Notes
MTLS certificate to
authenticate the Mediation
server to the Front End SIP
services
Media Gateways
Voice gateways vary widely in their capabilities and their ability to receive and use a certificate
to secure and authenticate connections and traffic between the gateway and the mediation
server. If your gateway can use a certificate, refer to the documentation of your gateway vendor
to request and deploy the certificate.
Hybrid Media Gateways
Microsoft Corporation
67
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Hybrid media gateways contain the functionality of the Mediation server as well as the features
and connectivity provided by the media gateway. Hybrid gateways would then replace the
Mediation server and would require that certificates be issued to authenticate the gateway and
the Mediation server functionality. Refer to vendor documentation on how to request and
install certificates for these specialized devices.
IP-PBX
Some IP-PBX, using SIP trunking, may be able to use a certificate to authenticate and secure the
traffic from the IP-PBX to the mediation server. Refer to the vendor documentation to
determine whether your IP-PBX can use a certificate and the recommended implementation.
Phase 4 Summary – Voice Services
The Mediation Server requires a certificate that provides for the authentication and encryption
of traffic from the Mediation Server to the pool. There may be more certificates that are
applicable to voice scenarios, but these requirements are driven by third-party equipment (for
example, media gateways, SIP trunk capabilities, and so on). For details about using certificate
with their equipment and services, see the third-party vendor and trunk provider.
Phase 5 – Group Chat Server
The Group Chat Server is a new role introduced with Office Communications Server 2007 R2. For
Group Chat Server, you need a certificate to authenticate and encrypt the communication
between the Front End Server and the clients. To request and install a certificate for the Group
Chat Server, see Office Communications Server 2007 R2 “Obtaining Certificates for Group Chat
Server” at http://go.microsoft.com/fwlink/?LinkId=161882.
You cannot use the wizard to request a certificate for the Group Chat Server. You can use
LcsCmd to do what is required for the certificate in this scenario. You can use Certreq to request
a certificate from an internal CA that uses non-standard templates.
LcsCmd – Group Chat Server
You can use the basic LcsCmd commands to request, submit, and retrieve a certificate for the
Group Chat server. You must have the FQDN of the Group Chat Server as the SN/CN and you
must also include the Client EKU for the Administration tool, otherwise the Group Chat
administration tool will not be able to connect to the Group Chat server. In this scenario, you
are requesting a certificate that provides MTLS. Run the following command at the command
line:
Microsoft Corporation
68
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
LcsCmd /cert /action:request /online:true /friendlyname:”Group Chat Server”
/sn:groupchat.contoso.com /ou: IT /org:Contoso /city:Redmond /state:Washington
/country:US /san:groupchat.contoso.com /enableClientEKU:TRUE
/fileName:”C:\CertHold\groupchat.req” /L
The SN/CN is the FQDN by which your Group Chat Server is configured for users through DNS.
To import and install the certificate, run the following command at the command line:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CAResponse.cer” /assign:true
/L
You also need a certificate chain for the Group Chat Server, but because it is a domain-joined
server, the Group Chat Server should have a chain available to it by default. If you need to
explicitly request a chain, run the following command at the command line:
LcsCmd.exe /Cert /Action:ImportCAChain /Filename:CAChain.p7b
Certreq – Group Chat Server
Certreq uses the same the same input file format and runs the same commands. The input file
might reflect these changes from the one presented in the section on the pool certificate
request earlier in this document. Make the following changes in the .inf file:
[Version]
Signature="$Windows NT$
[NewRequest]
Subject = "CN=groupchat.contoso.com" ; must be the FQDN of Group Chat server in DNS
And, later in the file:
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
; Server Authentication
OID=1.3.6.1.5.5.7.3.2
; Client Authentication
[RequestAttributes]
CertificateTemplate = CustomWebTemplate ; Name of the custom template to use
SAN="dns=groupchat.contoso.com" ; Wildcard entries are not preceded by the wildcard (*)
character
To submit and process the request, run the following commands at the command line:
certreq –new request.inf groupchat.req
certreq –submit groupchat.req groupchat.cer
Microsoft Corporation
69
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
certreq –accept groupchat.cer
2
1
Group Chat Server
and Compliance
Database
Consolidated Pool
Figure 27 Phase 5: Group Chat Server
Table 8 Legend for Figure 27 Phase 5: Group Chat Server
Number
1
2
Friendly Name
Group Chat Server
Front End Pool - SIP
DNS Entry
groupchat.contoso.com
sip.contoso.com
Common Name/
Subject Name
groupchat.contoso.com
sip.contoso.com
SAN Entries
Not applicable
sip.contoso.com,
sip.fabrikam.com,
access.contoso.com
CA (Public/Private)
Private
Private
Notes
MTLS certificate to
authenticate Group Chat to
Front End, with client EKU for
Group Chat administration
tool
Phase 5 Summary – Group Chat Server
The Group Chat Server, a new role introduced in Office Communications Server 2007 R2,
provides a persistent chat room functionality and an enhanced way for teams to collaborate.
Microsoft Corporation
70
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The certificate setup and configuration process is a very easy one for this role. The certificate
values are necessary to secure MTLS for the pool to Group Chat Server, client EKU for the Group
Chat administration tool, as well as TLS/SSL for the Group Chat client.
Phase 6 – Communicator Web Access
The Communicator Web Access server enables a number of features in Office Communications
Server. It provides a web-based instant messaging (IM) service with a web browser, the ability to
attend meetings, desktop sharing, and it enables users to call in to meetings through Public
Switched Telephone Network (PSTN).
To accomplish this, the Communicator Web Access server needs to communicate with the
Internet and communicate with the pool. To enable authentication and encryption, certificates
are used for server-to-server communication and client browser-to-Communicator Web Access
communication.
The Communicator Web Access server is really a specialized Web server. Because of this, the
certificates are generated and configured through a wizard unique to Communicator Web
Access or by using LcsCmd.
For details about installing, and configuring Communicator Web Access, see the following:

Office Communications Server 2007 “Office Communicator Web Access Planning and
Deployment Guide” at http://go.microsoft.com/fwlink/?LinkId=161883.
 Office Communications Server 2007 R2 “Deploying Communicator Web Access (2007 R2
Release)” at http://go.microsoft.com/fwlink/?LinkId=161884.
 Forefront TMG (ISA Server) Product Team Blog “Publishing Communicator Web Access
2007 through ISA Server 2006” at http://go.microsoft.com/fwlink/?LinkId=162697.
For details about preparing the certificates that are needed for Communicator Web Access, see
the following:

Office Communications Server 2007, “Planning for Certificates,” at
http://go.microsoft.com/fwlink/?LinkId=161885.
 Office Communications Server 2007 R2, “Preparing Certificates for Communicator Web
Access,” at http://go.microsoft.com/fwlink/?LinkId=161886.
Because Communicator Web Access is a Web server, you need to set up IIS 6.x or IIS 7 to
proceed with the install. To ensure that you have the correct components installed, see the
following:
Note Windows Server 2003 uses IIS 6.x, while Windows Server 2008 uses IIS 7. For
Office Communications Server 2007, follow the recommendations for setting up IIS 6.x
under Windows Server 2003. The requirements are essentially the same.

Office Communications Server 2007 R2 “Installing IIS 6.0 for Communicator Web
Access” at http://go.microsoft.com/fwlink/?LinkId=161887.
Microsoft Corporation
71
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2

Office Communications Server 2007 R2 “Installing IIS 7.0 for Communicator Web
Access” at http://go.microsoft.com/fwlink/?LinkId=161888.
The certificates that you need to obtain for Communicator Web Access fulfill two needs: to
provide for TLS/SSL for client access and MTLS for authentication/encryption to the other
servers in your infrastructure (that is, the pool).
There are specific requirements for the Communicator Web Access certificates. The certificate
that you need for client access (that is, the SSL certificate) must follow the guidelines listed here
and in Office Communications Server 2007 R2 “Deploying Communicator Web Access (2007 R2
Release)” at http://go.microsoft.com/fwlink/?LinkId=161884. You can either use the
Deployment Wizard by choosing Install Communicator Web Access from the Deploy Other
Server Roles page, or you can use LcsCmd.
This document emphasizes the importance of having parity between DNS and certificate SN/CN
and subject alternative name FQDNs. This is just as important for Communicator Web Access.
The DNS records discussed here assume that you are deploying Communicator Web Access as a
single server. Make sure that you are using the certificate subject alternative name field to
define the FQDNs that the server will be known by externally. For security, you should avoid
exposing the host name of the Communicator Web Access server to external requests. Deploy A
reverse proxy to disassociate the Communicator Web Access server from direct access from
external users.
Note When using Communicator Web Access, it is highly recommended that you use a
reverse proxy in the perimeter to respond to requests and to publish out the
Communicator Web Access server. This provides an important security zone that
separates your internally placed Communicator Web Access server from the perimeter
and the Internet. If you have deployed a reverse proxy for the Web conferencing
content, you can use this reverse proxy for Communicator Web Access as well. You need
to create a new publishing rule and a new listener for Communicator Web Access
because attempting to modify and use the rule and listener for the same configuration
that serves the Front End, Web components, and Web Conferencing Server does not
yield the expected results.
Internal and external users can use the same FQDN to connect to the Communicator Web
Access server. By doing this, you reduce the complexity of the required certificates and the
configuration of the server.
Because you are using SSL certificates in this scenario, the URL is https://im.contoso.com, which
is the name that internal and external users connect to. The client application sharing
component will use the CNAME records for functions specific to application sharing through
Communicator Web Access.
This means that you need to request one public CA certificate (that is, for the reverse proxy and
serving client connections only) and acquire one certificate from the internal CA (that is, for the
Microsoft Corporation
72
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
actual Communicator Web Access server connection to the Office Communications Server Front
End Server).
Our public CA certificate for the reverse proxy has the following requirements:


Subject Name/Common Name for Reverse Proxy: im.contoso.com
Subject Alternative Names: im.contoso.com, download.im.contoso.com,
as.im.contoso.com
Be sure that you are fully aware that you are requesting the certificate for the publishing rule
and listener on ISA Server. Other firewalls and devices should follow similar rules for their
requirements, but the SN/CN and subject alternative name should be similar.
The internally generated certificates have the following requirements for MTLS and TLS (recall
that both protocols can be served by one certificate):


Subject Name/Common Name: cwa.contoso.com (must be the real FQDN of the
Communicator Web Access server because MTLS checks the Trusted Server list and
reject the certificate at installation if it does not match the host FQDN)
Subject Alternative Names: cwa.contoso.com, download.cwa.contoso.com,
as.cwa.contoso.com
Creating and Requesting the Certificates
You use the same process used previously to create the certificates and then submit them to
either the public or internal CA.
CA Certificate Chain
The certificate chain is vitally important for your certificates, public or internal, because you
must have a full trust from the server holding the certificate up through and including the
issuing, intermediate, and root CAs. If you forget to retrieve and install the certificate chain, the
issues that you may experience include warnings during some operations, services cannot start,
servers cannot connect, and clients cannot communicate. However, a domain-joined computer
like Communicator Web Access retrieves and installs the chain automatically with the certificate
request.
Verify that you have the complete certificate chain from the public CA that you acquire the
external (that is, publishing rule/reverse proxy) certificate from. If you do not have the complete
certificate chain, one potential error that clients connecting from the outside might encounter is
the “Your session was ended… Error code:0-0-18100-2-0” error message. For details about this
error, see the “Validation and Troubleshooting” section later in this document.
Microsoft Corporation
73
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
LcsCmd – Communicator Web Access for Reverse Proxy
When you use LcsCmd, the process for the CWA and the reverse proxy are the same as outlined
previously in this document. First, you run commands for the public CA. You need to run these
commands from the reverse proxy, and not from the Communicator Web Access server. If you
run the commands from the Communicator Web Access server, the public and private key pair
are created on the Communicator Web Access server, and the keys will not be on the reverse
proxy when you receive the certificate and attempt to bind the certificate to the key pair. You
can request and export the private key and certificate from the Communicator Web Access or
from another system as was discussed in the “Requesting a Certificate from Another Machine”
section earlier in this document.
From the reverse proxy, run the following command at the command line:
LcsCmd /cert /action:request /online:false /friendlyname:”Web Proxy CWA”
/sn:im.contoso.com /ou: IT /org:Contoso /city:Redmond /state:Washington /country:US
/san:im.contoso.com, download.im.contoso.com, as.im.contoso.com
/fileName:”C:\CertHold\CWAproxyext.req” /L
Send the certificate request to your public CA by using their processes for offline requests. After
you receive the signed certificate back from the public CA, use LcsCmd to place the certificate on
to the reverse proxy and bind the key pair. Run the following command at the command line:
LcsCmd /cert /action:ImportResponse /fileName:”C:\CertHold\CWAResponse.cer”
/assign:true /L
You need to configure the reverse proxy to listen for requests for the Communicator Web
Access server and then pass those requests on to the Communicator Web Access server. For ISA
Server 2006, you do this by configuring a second, new Web listener. You cannot use the same
publishing rule and listener that you created earlier for the Web components and Web
Conferencing Server. For details about configuring the Web listener, see Forefront Edge Security
TechCenter “Secure Application Publishing” at http://go.microsoft.com/fwlink/?LinkId=125682.
When you are configuring the Web listener, you are asked for the certificate to use with the SSL
protocol. Point to and select the certificate that you just received for the client connections to
Communicator Web Access and apply it here. TLS/SSL will now be available for use from your
clients so that they can connect through the reverse proxy to the Communicator Web Access
server.
For the internal certificate to allow for MTLS between other Office Communications Server
servers and the Communicator Web Access server, you need to create the internal CA
certificate. You could use a public CA certificate, but if you already have an internal CA, which
does not cost anything, you can use that instead. If you request the MTLS certificate according
to the instructions, this certificate also acts as the TLS/SSL certificate for internal users to
connect to the Communicator Web Access server.
Microsoft Corporation
74
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
LcsCmd – Communicator Web Access for MTLS/TLS
This request is less complex than the previous examples because you are on the domain and
internal network, and you have direct access to the internal CA. A single command generates
keys, creates and submits the certificate request, retrieves it, and then applies the certificate.
Then, you need to modify the request slightly to request a certificate for SSL purposes.
For MTLS, run the following command at the command line:
LcsCmd /cert /action:request /online:true /assign:TRUE /ca:ContosoDC.contoso.com\contoso-CONTOSO-DC-CA /caAccount:contoso\CAAdmin
/caPassword:P@ssword1 /friendlyname:”Communicator Web Access Internal”
/sn:cwa.contoso.com /ou:IT /org:Contoso /city:Redmond /state:Washington /country:US
/san:cwa.contoso.com, as.cwa.contoso.com,download.cwa.contoso.com /L
Recall that the /Assign switch is only available in Office Communications Server 2007 R2 version
of LcsCmd.
Certreq – Communicator Web Access for Reverse Proxy
If you make some changes to the .inf file that provides information to the utility, you can use
Certreq to request a certificate for the reverse proxy. Make the following changes in the .inf file:
[NewRequest]
Subject = "CN=im.contoso.com" ; must be the FQDN of the CWA server in Perimeter DNS
SAN="dns=im.contoso.com&dns=download.im.contoso.com&dns=as.im.contoso.com"
After you have the fully formed .inf file, the commands are the same for Certreq, but you must
run the commands from the reverse proxy, not the Communicator Web Access server. (If you
follow the guidance provided earlier in this document on how to request certificates from
another machine, you can perform this through a workstation or another server.) On the
reverse proxy, run the following commands at the command line:
certreq –new request.inf CWAreverse.req
certreq –submit CWAreverse.req CWAreverse.cer
certreq –accept CWAreverse.cer
Microsoft Corporation
75
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Certreq – Communicator Web Access for MTLS/TLS
Certreq is available in those cases where a custom template is required for the internal CA.
Following is the entire .inf file:
[Version] Signature="$Windows NT$
[NewRequest]
Subject = "CN=cwa.contoso.com" ; must be the FQDN of CWA host name in internal DNS
EncipherOnly = FALSE
Exportable = TRUE
; FALSE = Private key is not exportable
KeyLength = 1024
; Common key sizes: 512, 1024, 2048,
; 4096, 8192, 16384
KeySpec = 1
; Key Exchange
KeyUsage = 0xA0
; Digital Signature, Key Encipherment
MachineKeySet = True
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = CMC
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1
; Server Authentication
[RequestAttributes]
CertificateTemplate = CustomWebTemplate ; Name of the custom template to use
SAN="dns=cwa.contoso.com&dns=download.cwa.contoso.com&dns=as.cwa.contoso.com"
Run the following commands at the command line:
certreq –new request.inf CWA.req
certreq –submit CWA.req CWA.cer
certreq –accept CWA.cer
This certificate provides MTLS for Front End Server connections and TLS/SSL for internal client
connections.
Microsoft Corporation
76
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
1
2
Office
Communications
Server Pool
Deployment
Communicator
Web Access
3
Reverse Proxy
Internet
External
CWA Client
Perimeter DNS
Internal DNS
Figure 28 Phase 6: Communicator Web Access
Table 9 Legend for Figure 28 Phase 6: Communicator Web Access
Number
1
2
Friendly Name
CWA Reverse Proxy Listener
Communicator Web Access
DNS Entries
cwa.contoso.com
cwa.contoso.com
DNS Record
Location
Perimeter
Internal
Common Name/
Subject Name
cwa.contoso.com
cwa.contoso.com
SAN Entries
cwa.contoso.com
download.cwa.contoso.com
as.cwa.contoso.com
autodiscover.contoso.com
cwa.contoso.com
download.cwa.contoso.com
as.cwa.contoso.com
CA (Public/Private)
Public
Private
Notes
The URLs and the other
entries on the subject
alternative name ensure that
the certificate is able to
provide for TLS/SSL
The certificate is installed
during deployment and can
be further managed by the
Communicator Web Access
administration tool post
deployment
Phase 6 Summary – Communicator Web Access
The Communicator Web Access server in Office Communications Server 2007 R2 is more
advanced and provides more services than its predecessor. With Communicator Web Access,
Microsoft Corporation
77
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
you can use desktop sharing and dial-in conference attendance. You can also use a browser, as
in previous versions of the server, to access presence and IM, which enables you to stay in touch
with your colleagues regardless of where you are.
Hardware Load Balancer
Configurations
Hardware load balancers provide scalability as well as high availability in Office Communications
Server 2007 and Office Communications Server 2007 R2. Hardware load balancers add logic
behind an Enterprise pool to continue operation in the event of server failures, and scale up to
provide services for tens of thousands of users. They also ensure that the Director can handle
incoming traffic, and scale the Edge services up, as well as provide availability in the event of
server failures.
To do this, the hardware load balancers present unique certificate requirements. The hardware
load balancers do not use certificates, but require changes in the way that certificates are
created for the servers that are attached to the hardware load balancers. This section defines
the requirements for certificates to operate properly with hardware load balancers.
Hardware Load Balancer and Connected Server
Certificate Requirements
Initially, hardware load balancers appear to create another level of complexity to the already
complex subject of certificates in Office Communications Server. The following rules and
guidelines should simplify the process:





If there is a subject alternative name on the certificate, ignore the subject name and
refer only to the subject alternative name. This tip will significantly reduce the confusion
when defining or troubleshooting a certificate issue, especially behind a hardware load
balancer.
All servers attached behind a load balancer must appear the same to the client or server
contacting it.
Each server in a load balanced pool has its own certificate, created according to the
specifications defined in this section.
All servers and clients trying to contact a given server resource use the virtual IP (VIP)
address of the load balancer, not the actual server address.
The DNS name of the VIP is the SN/CN of the certificate. Subject alternative names
should exist on the Access Edge Server role, Director role, and pool only. Subject
alternative names are not necessary on any other roles. However, if you decide to
include a subject alternative name, populate the subject alternative name with the
SN/CN only.
Microsoft Corporation
78
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2

The subject alternative name for the Access Edge Server must contain a sip.<domain
name> entry for each domain that you are hosting SIP for. The final entry is the SN/CN.
For the certificates in the load balanced pool or Edge Server, mark the certificate as
exportable, copy the certificate to each member, and then assign it to the correct
interface. For example, the external interface for four Edge Servers behind a load
balancer each have a copy of the Access Edge Server, Web Conferencing Server, and A/V
authentication certificates. The internal interface behind a load balancer each has a
copy of the certificate created for the internal edge interface. To do this, do any of the
following:
o Installation wizard: Select the Mark cert as exportable check box on the
Security and Settings page
o LcsCmd: Include the parameter ‘/exportable:TRUE’
o Certreq: Specify ‘Exportable = TRUE’ in the .inf

Verify which services are actually being exposed through the load balancer – you may
not need to consider load balancing for every service offered.
 For the purposes of the public IM connectivity, include the Client EKU option on any
certificate in the SIP path, specifically Access Edge Servers, Directors, and Front End pool
servers. This ensures that the requirements for AOL federation through public IM
connectivity are met.
 With respect to security, when you import the common certificate (that is, per role and
interface) to the destination server, remove the export option to secure the key pair.
For details unique to that implementation, refer to the vendor documentation for the load
balancer that you are implementing. For details, see Unified Communications Partners
“Microsoft Unified Communications Hardware Load Balancer Deployment” at
http://go.microsoft.com/fwlink/?LinkId=133624.
Pool / Front End Servers
To review what you defined and installed on the pool server, there is one certificate serving a
dual purpose:
1. MTLS Certificate for the front end authentication and communication.
2. SSL/TLS Certificate for the front end Web processes.
You assigned the certificate a SN/CN of pool01.contoso.com. This name also has an A record in
the internal DNS, which assures that it will be resolved to the pool. When you install the pool,
you are instructed to create this DNS A record, which defines the pool separately from the
physical host names, and A records for the servers that make up the pool. This is the FQDN that
you are interested in when you define the certificate(s) for your pool. If you do not create this A
record for the pool, you will receive a warning during the validation of the pool indicating that
there is no A record defined for the pool. This A record is not as important if there is only one
server in the pool, but if you scale the pool (that is, now or at a later date) this record becomes a
Microsoft Corporation
79
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
necessity to define the pool servers as a unit rather than as individual servers. The certificate
counts on the pool FQDN, and not single server definitions.
Note that it also contains a subject alternative name with specific entries for additional SIP
domains, specifically sip.<domain name> entry. Include these on the certificates too.
If you or someone in your organization decides to add servers to this pool, you need to
implement a hardware load balancer to accept requests for pool01.contoso.com. In this
scenario, you need to re-request certificates for the two computers. You can also request one
certificate and import (with private key) the single certificate to each computer’s Personal
certificate store because the information on each certificate is the same.
Following the same basic convention, you need to go back to IIS Manager on each server and reassociate the new certificates to the HTTPS protocol on each Web server.
There is no requirement for a second certificate because IIS can use the existing certificate
created for the consolidated pool. Subject alternative name entries are provided for the Web
Conferencing and Web Components.
The required entries are in the following format:
Pool Front End 1:
SN/CN: pool01.contoso.com
SAN: sip.contoso.com, sip.fabrikam.com, pool01.contoso.com, webpool.contoso.com,
webconf.contoso.com
Pool Front End 2:
SN/CN: pool01.contoso.com
SAN: sip.contoso.com, sip.fabrikam.com, pool01.contoso.com, webpool.contoso.com,
webconf.contoso.com
The Expanded topology follows the same conventions by requesting and installing a certificate
for the SIP, Web Conferencing, and Web Components pool. The certificate is assigned to the SIP
pool through the Certificate Wizard. The Web Conferencing and Web Components are assigned
through IIS Manager.
The Audio/Video pool must have a separate certificate created and assigned. The only entry
necessary for the Audio/Visual pool certificate is the subject name. There is no need for subject
alternative names.
Microsoft Corporation
80
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
1
2
Load Balanced
Director
Consolidated Pool
Inner Firewall
Figure 29 Load balanced Consolidated Pool and Director
Table 10 Legend for Figure 29: Load Balanced Consolidated Pool and Director
Number
1
2
Friendly Name
Consolidated Pool
Director
DNS Entries
pool01.contoso.com
webpool.contoso.com
webconf.contoso.com
director.contoso.com
Common Name/
Subject Name
pool01.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com
sip.fabrikam.com
pool01.contoso.com
webpool.contoso.com
webconf.contoso.com
director.contoso.com
CA (Public/Private)
Private
Private
Notes
Install certificate on each
server in pool (if more than
one) Certificate is configured
in IIS Manager and installed
on each server, and SAN
Install certificate on each
server in pool (if load
balanced)
Microsoft Corporation
81
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
must contain the URL of the
Web Components if different
from the pool name
2
1
3
Expanded Pool
Load Balanced
Director
Inner Firewall
Figure 30 Load balanced Enterprise Edition expanded topology
Microsoft Corporation
82
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Table 11 Legend for Figure 30: Load Balanced Enterprise Edition Expanded Topology
Number
1
2
3
Friendly Name
Front End
Audio/Video Pool
Director
DNS Entry
pool01.contoso.com,
webconf.contoso.com,
webpool.contoso.com
avpool.contoso.com
director.contoso.com
Common Name/ Subject
Name
pool01.contoso.com
avpool.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com,
pool01.contoso.com,
webconf.contoso.com,
webpool.contoso.com
NA
CA (Public/Private)
Private
Private
Private
Notes
Install certificate on each
server in pool
Certificate is configured in
IIS Manager and installed
on each server, and
subject alternative name
must contain the URL of
the Web Components if
different from the pool
name
Install certificate on each
server in pool
sip.contoso.com,
sip.fabrikam.com,
director.contoso.com
Microsoft Corporation
83
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Director
You can configure the Director role behind a load balancer, but the limitation for supported topologies in Office
Communications Server 2007 R2 only allows you to use Enterprise Edition pools as Directors. Just as in a pool
configuration, multiple Enterprise Edition servers can be load balanced. Also, if you use multiple Enterprise Edition
Directors, this does not mean that you have a SQL server per Director because the SQL server can host multiple
instances per Director, in addition to hosting the main SQL server for your pool.
Note If you are using multiple SQL Server instances, they must be distinct instances on the same SQL Server.
However, if you are using Office Communications Server 2007, you can use Standard Edition Directors behind a load
balancer. Note that when you migrate to Office Communications Server 2007 R2, you need to upgrade the Standard
Edition Directors to Enterprise Edition.
The certificate for supporting load balanced Directors is as follows:
Director01
SN/CN: director.contoso.com
SAN: sip.contoso.com, sip.fabrikam.com, director.contoso.com
Director02
SN/CN: director.contoso.com
SAN: sip.contoso.com, sip.fabrikam.com, director.contoso.com
Microsoft Corporation
84
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
1
Director SQL
DIRECTOR01
Office Communications
Server Pool Deployment
DIRECTOR02
Internal
DNS
2
Inner Firewall
Figure 31 Load balanced Director topology
Table 12 Legend for figure 31 Load Balanced Director Topology
Number
1
2
Friendly Name
Director 01
Director 02
DNS Entry
(Internal)
director.contoso.com
director.contoso.com
DNS Entry
(Perimeter/External)
director.contoso.com
director.contoso.com
Common Name/ Subject
Name
director.contoso.com
director.contoso.com
SAN Entries
sip.contoso.com
sip.fabrikam.com
director.contoso.com
sip.contoso.com
sip.fabrikam.com
director.contoso.com
CA (Public/Private)
Internal CA
Internal CA
Microsoft Corporation
85
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Notes
The internal and perimeter
DNS entries and the
subject name must
reference the virtual IP of
the Director’s hardware
load balancer. You must
include references for all
SIP domains that the
Directors will manage
traffic.
The internal and perimeter
DNS entries and the
subject name must
reference the virtual IP of
the Director’s hardware
load balancer. You must
include references for all
SIP domains that the
Directors will manage
traffic.
Edge Servers
The Edge Servers follow the same basic formula described in the previous section. Because there are up to three roles
that the Edge Server can service, and a total of four interfaces (that is, Access Edge Server, Web Conferencing Server,
A/V authentication, and internal edge), you need four certificates. The entries are in the following format:
Edge Server
Access Edge Role (Public CA):
SN/CN: access.contoso.com
SAN: sip.contoso.com, sip.fabrikam.com, sip.contoso.com
Web Conferencing Role (Public CA):
SN/CN: webconf.contoso.com
A/V Authentication Role (Internal CA):
SN/CN: av.contoso.com
Internal Edge (Internal CA):
SN/CN: internaledge.contoso.com
Note that the Web Conferencing Server, A/V authentication, and internal edge certificates do not have subject
alternative names. You do not need subject alternative name entries on these certificates. However, if you think you
need to have a SAN for the sake of consistency, it should only include the SN/CN that you have already defined for the
certificate.
There is a potential issue that you might encounter. The Edge Server needs to be able to find the internal pool servers.
As a security practice, you do not want to create DNS entries for your internal pool servers on the perimeter DNS
servers. To resolve this problem, you need to create or modify the existing HOSTS file that exists in the
%systemdrive%\System32\Drivers\etc directory on the Edge Server. In the current scenario, you configure your HOSTS
file as follows:
# Copyright (c) 1993-2009 Microsoft Corp.
Microsoft Corporation
86
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# localhost name resolution is handled within DNS itself.
#
127.0.0.1
localhost
#
::1
localhost
192.168.10.20
pool01.contoso.com
192.168.10.20
contoso-fe01.contoso.com
192.168.10.20
contoso-fe02.contoso.com
Client Requirements and Client Communication
Client communication is relatively simple when compared to server communication. Because the clients communicate
with TLS/SSL, as long as they have the root or root chain certificates of the issuing authority of the server that they are
trying to authenticate or establish and encrypt communication with, the negotiation is fairly seamless.
Typically, the only time you experience certificate issues with clients is when you do not have the root certificate. And,
the clients rely on the base operating system to manage and maintain the certificates. Windows comes with a wide
variety of well-known public CA root certificates. If Windows happens not to have the root certificate of a given public
CA, you can go to the Web site for that CA vendor.
If you encounter problems connecting to your infrastructure (that is, internally or externally) check the event logs.
Certificate issues are logged and provide problem descriptions and resolutions.
It is recommended that you stick with the UC Certified public CAs because problems with clients are typically external,
not internal. By doing this, you get a certificate from a vendor that follows the guidelines for Unified Communications
(that is, both Office Communications Server and Exchange Server), and the likelihood of an issue or configuration
problem is greatly reduced.
Validation and Troubleshooting
You validate the pool-assigned certificates initially through the Setup Wizard. The process of validating the operation of
the pool involves checking that the proper entries are made in Active Directory, that groups are created properly and
that they exist, and that communication can be established from two Office Communications Server 2007 R2-enabled
accounts.
Microsoft Corporation
87
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
The validation consists of a number of different validation runs, depending on the services that you have implemented
on the Front End Server. Certificates are checked for each of the service roles as follows:






Front End
Web Components
Web Conferencing
Audio/Video Conferencing
Application Sharing
Validate Application Functionality (if installed)
o Conferencing Attendant
o Conferencing Announcement
o Response Group
o Outside Voice Control
Services Are not Starting and Event Log Shows Numerous Errors
During the process of checking the pool for proper configuration, the certificates are checked to ensure that they exist
and that the enabled users can communicate through the pool. This confirms that the certificates are properly formed,
can provide authentication for the users and services, and that the users can maintain a communication through the
pool and to the applications. This check also confirms proper naming for the trusted servers list in Active Directory.
Of all of these fields, the common name is the most critical. The CN must be the FQDN as represented in DNS and in
Active Directory for your web services on this pool server. If this is wrong, the server will fail service startup. The services
will not start and clients will not be able to connect.
If your server certificate and the entry in the trusted service list in Active Directory do not match, you will see these
events in the event log on the affected server:
Microsoft Corporation
88
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Figure 32 Review error messages in Events log
This error clearly states that the name of the subject of the certificate with the noted serial number is incorrectly
configured. You need to correct this (and any other errors that appear in the Office Communications Server event log)
before continuing. Similar errors will appear for each of the configured services that have entries in the trusted services
list in Active Directory.
No Certificate Chain for the Certificate That You Are Attempting to Trust
Output of the validation wizard, presented through Internet Explorer, provides detailed information about what was
checked, and what succeeded or failed. For certificate-related issues, you are most interested in errors that indicate that
the server or the user was unable to start, authenticate, or connect. A typical error is as follows:
Figure 33 View the No Certificate Chain for the Certificate That You Are Attempting to Trust error message
And, following this is a message that is somewhat ambiguous, but important:
Figure 34 Troubleshooting the No Certificate Chain for the Certificate That You Are Attempting to Trust error message
Microsoft Corporation
89
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
A failure of this type indicates that you do not have the certificate chain for the CA that issued this certificate in the
Trusted Root Certification Authorities. To resolve this issue, retrieve and install the CA chain, as the suggested resolution
advises in figure 34.
Service Not Started, Not Configured, or Recognized
At first glance, this appears to be a complex problem. However, it is a simple problem to troubleshoot.
Figure 35 View the Service Not Started, Not Configured, or Recognized error message
Remember, wildcards are not supported, and this is one effect of using wildcards.
Figure 36 Troubleshooting the Service Not Started, Not Configured, or Recognized error message
Verify that the service on the target machine is started. Next, check the certificate and the DNS records. If they are out
of synch, your service will not start, with other interesting records in the Office Communications Server event log. Check
the Office Communications Server event log for hints as to why they did not start. If all else fails, you may be dealing
with a firewall (a common issue on Windows Server 2008 and the Advanced Firewall with the profiles for each type of
trust zone – Domain, Private, and Public) and proper rules on the integrated firewall as well as your Enterprise firewall.
To do a quick check, run the Netstat –ano command at the command line.
If this shows that the port/protocol IP address is running, you probably need to look at the source rather than the
destination, using the same techniques. NetMon 3.3 is helpful for this type of work because you can follow the network
traffic conversation to determine which one is not responding to queries.
If all else fails, you can use the logging tools to create a logging session and parse it with OCSLogger (available as a
Resource Kit tool) to provide a conversation-based view of the logs captured. An overview of the options available in the
Office Communications Server logging tool is beyond the scope of this document.
Typically, this issue is related to a communications failure problem.
Failure [0xC3Ec79E6] Service failed to start as requested
Causes
Common Name / Subject Name of certificate was created as a wildcard (e.g. *.contoso.com)
Common Name / Subject Name is not correctly configured in DNS or configuration of Front End Server
Resolution
Microsoft Corporation
90
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Carefully review your certificates and confirm that the CN of the certificate matches exactly the entry in DNS for the
name of the server. You should have created an additional A record in DNS for the pool, and this is the FQDN that you
should have as the first entry in the subject alternative name of the certificate, and the second entry should be the
FQDN of the server as listed by FQDN in DNS.
You might also see this error in a case where certificates are not involved. Remove any references to the Front End
Server or pool FQDN from the following locations:
 "Global Properties" | "Edge Servers" | "Access Edge and Web Conferencing Edge Servers"
 "Global Properties" | "Edge Servers" | "A/V Edge Servers"
 "Front End Properties" | "Host Authorization"
In most cases, when services do not start, it is usually caused by misnaming of certificate, DNS, or the server.
Communicator Web Access error – “Your session was ended… Error code:0-0-18100-2-0”
For details, see Unified Communications blog “Your session was ended… Error code:0-0-18100-2-0” at http://unifiedcommunications.blogspot.com/2009/06/your-session-was-ended-error-code0-0.html.
CRL and CDP Troubleshooting
Certificate revocation lists and certificate distribution points are rather simple issues to resolve. A couple rules you need
to know are as follows:

The CRL and CDP must be accessible from the machine on which the certificate is installed. Typically, this is listed
in a couple formats, with LDAP and HTTP being the most common. The machine on which the certificate is
installed must be able to reach the issuing CA as listed in the certificate under CRL Distribution Points through
port TCP/80 for HTTP or port TCP/389 for LDAP. You can use a Web browser to attempt to reach the CDP for
HTTP locations. You should be able to download the CRL by using the browser. For LDAP, any of the LDAP-aware
tools (ADSI-Edit) should be able to locate the CDP and the CRL.
 The Office Communications Server servers are designed to run in what is known as “best effort” mode and in
offline caching for CRLs. This means that if they cannot retrieve the CRL on the update cycle, they will continue
to run. They will not have the latest CRL, so it does make sense to retrieve the CRL from another online machine
that can reach the CDP, download the CRL and then import the CRL onto the machine.
The simplest solution is to make sure that you have HTTP access from any certificate-based system to the issuing CA. It
does not have to be wide open with an Any-to-Any rule, but just TCP/80 to the CA (that is, internal or external).
Microsoft Corporation
91
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Frequently Asked Questions
If I have an Edge Server that I only want to use for instant messaging (IM) access for my external users, what type of
certificate should I use? Do I have to assign certificates to the Web edge and the A/V Authentication edge?
If you only want to present IM to external users, you can assign a certificate just to the edge interface or IP that you
intend to offer IM services to your external users. It is also a good idea to deactivate the unused edge services, which
you can do by using LcsCmd. For details, see Office Communications Server 2007 R2 “Deactivating Servers (Command
Line)” at http://go.microsoft.com/fwlink/?LinkId=161889.
Can I use any Public CA for my Edge and other externally facing certificates?
The question of using any public CA is a bit more complicated than a simple yes or no answer. The question is really
around what format and options you can use for the request. There are some specific requirements for a certificate (as
has been discussed at length in this document), but there are a few specific needs:


Subject Name/Common Name must be the FQDN of the machine as it is known in DNS.
Subject Alternative Names must appear on the certificate as they appear in DNS as FQDNs, and must be properly
formed. If you have a subject alternative name, the SN/CN should appear in the subject alternative name.
There is a specific problem known with at least a couple well-known public CAs in which subject alternative name entries
requested as sip.contoso.com appear in the subject alternative name as www.sip.contoso.com. Subject alternative
name entries of this type will not work for the intended purpose. The best guidance is to use the public CAs referenced
in Knowledge Base article 929395, “Unified Communications Certificate Partners for Exchange 2007 and Office
Communications Server 2007,” at http://go.microsoft.com/fwlink/?LinkId=140898 because these public CAs have been
vetted and are known to work as intended.
Issue 1: I imported my certificate, but I don’t see it when trying to select it for a role
Issue 2: I’ve retrieved and installed my certificate, but there isn’t a private key associated with the certificate. What
went wrong?
Typically, this happens for the following reasons:
1. The certificate was created on another machine and the private key was not exported with the certificate. The
certificate is on the desired machine, but it is no longer with the private key.
2. When it was accepted or imported, the certificate was placed into the User Store and not the Machine Store.
The user does not use the certificate, the machine or a service on the machine uses it. By having the certificate
and private key in the user context, it is like not having a certificate at all. Context matters with Office
Communications Server.
To resolve issue 1, do the following:
1. Open MMC as an administrator on the machine from which the certificate was requested, and then add the
Certificates snap-in. When you add the snap-in, you will be asked if you are managing certificates for the user or
the computer. Choose Computer, and then Local Computer.
Microsoft Corporation
92
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
2.
3.
4.
5.
6.
Navigate to the Personal node, and then click Certificates.
Locate the certificate that you requested, right-click the certificate, click All Tasks, and then click Export.
Complete the Export Wizard.
As long as the certificate was created with the exportable flag set, click Yes, export the private key.
On the Export File Format page, select Personal Information Exchange – PKCS#12 (.PFX) format, and then select
the appropriate options, including the following:
a. Include all certificates in the certificate path if possible (this will export the CA chain with the certificate
and key).
b. Delete the private key if export is successful (this will remove the private key from the requesting
system).
c. Export all extended properties (including any EKU options).
7. Choose and set a password for the export (required).
8. Define a location and filename for the exported .pfx file.
9. Check the summary to confirm your choices.
10. Click Finish.
11. Import the certificate to the Computer store on the target machine.
To resolve Issue 2, do the following:
This specific issue can be more complicated because it is possible that the private key was marked as not exportable.
This means that you cannot follow the guidance above.
Run through the same steps outlined to resolve Issue 1 to determine whether the private key can be exported from the
user store and then import it back to the machine store. If you find that the private key cannot be exported, you have to
re-request the certificate, and then place it into the proper store.
Microsoft Corporation
93
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Additional Resources




















Office Communications Server 2007 Resource Kit Tools at http://go.microsoft.com/fwlink/?LinkId=161890.
Office Communications Server 2007 R2 Resource Kit Tools at http://go.microsoft.com/fwlink/?LinkId=158267.
Unified Communications Certificate Partners for Exchange 2007 and Office Communications Server 2007 at
http://go.microsoft.com/fwlink/?LinkId=140898.
Microsoft Unified Communications Open Interoperability Program at
http://go.microsoft.com/fwlink/?LinkId=158268.
Microsoft Unified Communications Hardware Load Balancer Deployment at
http://go.microsoft.com/fwlink/?LinkId=133264.
Certificates Technical Reference (see “How Certificates Work”) at
http://go.microsoft.com/fwlink/?LinkId=161869.
DNS Requirements for Automatic Client Sign-In at http://go.microsoft.com/fwlink/?LinkId=162885.
DNS Requirements for External User Access at http://go.microsoft.com/fwlink/?LinkId=162886.
Knowledge Base article 968878, “Response Group Service cannot start if you assign a certificate that contains a
SAN list, and the last name on the list is not the pool FQDN to Office Communications Server 2007 R2,” at
http://go.microsoft.com/fwlink/?LinkId=161892.
Knowledge Base article 939802, “Error message when you click the "Join the Meeting" link in the e-mail message
that you receive from the Web Conference session presenter in Communications Server 2007: "An error
occurred verifying the server's certificate",” at http://go.microsoft.com/fwlink/?LinkId=161893.
Knowledge Base article 954581, “Error message if you try to access the internal paths or external paths from the
Office Communications Server 2007: "Certificate Error",” at http://go.microsoft.com/fwlink/?LinkId=161894.
Knowledge Base article 937302, “Error message when you try to start a Multipoint Control Unit in
Communications Server 2007: "0xC3EC79E6",” at http://go.microsoft.com/fwlink/?LinkId=161895.
Knowledge Base article 939530, “You cannot download the corporate address book, and you receive an error
message when you use Communicator 2007 to log on Communications Server 2007: "Cannot Synchronize
Address Book",” at http://go.microsoft.com/fwlink/?LinkId=161896.
Knowledge Base article 940779, “Error message when you use Communicator 2007 to externally connect to the
Communications Server 2007 Web Components by using ISA Server: “Cannot Synchronize Address Book”,” at
http://go.microsoft.com/fwlink/?LinkId=150724.
Knowledge Base article 938294, “You cannot share a document in a Web conference that is hosted by
Communications Server 2007 Enterprise Edition,” at http://go.microsoft.com/fwlink/?LinkId=161897.
Knowledge Base article 948260, “You may receive error messages when you run the Validation Wizard on a
computer that is running Communications Server 2007 Access Edge Server” at
http://go.microsoft.com/fwlink/?LinkId=161898.
Windows PKI Blog at http://go.microsoft.com/fwlink/?LinkId=161899.
Managing Certificates for Office Communications Server (Command Line) at
http://go.microsoft.com/fwlink/?LinkId=161870.
Windows Server 2008 PKI and Certificate Security, by Brian Komar at
http://go.microsoft.com/fwlink/?LinkId=161900.
Microsoft Windows Server 2003 PKI and Certificate Security, by Brian Komar at
http://go.microsoft.com/fwlink/?LinkId=161901.
Microsoft Corporation
94
Deploying Certificates in Office Communications Server 2007 and Office Communications Server 2007 R2
Acknowledgements
This paper could not have been written with help from a number of people. Thanks to the following people:
Aaron Tiensivu [MVP], Brian R. Ricks [MVP], David Feng [MVP], Dennis Lundtoft Thomsen [MVP], Desmond Lee [MVP],
Dustin Hannifin [MVP], Jeff Schertz [MVP], Joachim Farla [MVP], Lee Mackey [MVP], Thomas Wenzl [MVP], Thomas
Binder [Microsoft Consulting Services], Thomas Laciano [Sr. Program Manager], Nick Smith [Microsoft Consulting
Services], Mitch Duncan [Sr. Technical Writer], Rui Maximo [Sr. Technical Writer], Rick Varvel [Architect - Microsoft
Consulting Services]
Microsoft Corporation
95