Export (0) Print
Expand All
0 out of 2 rated this helpful - Rate this topic

Preparing Certificates for Communicator Web Access

Communications Server 2007 R2

Topic Last Modified: 2011-11-17

Communicator Web Access (2007 R2 release) uses two different protocols – mutual TLS (MTLS) and Secure Sockets Layer (SSL) – to carry out its appointed tasks. MTLS is a protocol that provides secure communication between two computers. In this case, MTLS is used to authenticate connections between Communicator Web Access and Office Communications Server 2007 R2.

Secure Sockets Layer (SSL) is an Internet protocol used both as a way to authenticate parties in a conversation and as a way to encrypt that conversation. With Communicator Web Access, SSL (and certificates) are used to secure connections between the clients and the server.

Although Communicator Web Access uses two different protocols you can typically get by with installing a single certificate: in most cases the same certificate can be used both for MTLS and SSL. (The MTLS certificate is assigned when you activate Communicator Web Access, while the SSL certificate is assigned each time you create a virtual server). If you have just one Communicator Web Access server you can use a single certificate as long as that certificate meets the following criteria:

Subject name

Matches the URL of the Communicator Web Access site. For example, if the URL is https://im.contoso.com then the certificate should have im.contoso.com as subject name. Matches the fully qualified domain name (FQDN) of the Communicator Web Access server. The Communicator Web Access server URL should be defined in the SAN field.

Subject alternative name (SAN)

Includes the following:

  • The URL of the Communicator Web Access site.
  • The as URL.
  • The download URL.
  • The fully qualified domain name (FQDN) of the Communicator Web Access server.

For example, suppose you have a computer named cwaserver.contoso.com, and users access this server using the host name im.contoso.com. In that case your certificate would need to include the following information:

Subject name

  • im.contoso.com

Subject alternative name (SAN)

  • im.contoso.com
  • as.im.contoso.com
  • download.im.contoso.com
  • cwaserver.contoso.com

It is possible for a single Communicator Web Access computer to host multiple virtual servers (for example, im.contoso.com and im.fabrikam.com). In that case, you will need two certificates, one for contoso.com and one for fabrikam.com.

It is also possible to have separate SSL and MTLS certificate. For example, if your Communicator Web Access URL is https://im.contoso.com then your SSL certificate should have following information:

Subject name

  • im.contoso.com

Subject alternative name (SAN)

  • im.contoso.com
  • as.im.contoso.com
  • download.im.contoso.com

The MTLS certificate should list the full qualified domain name (FQDN) of the Communications Web Access computer in the subject name of the certificate. If the fully qualified domain name (FQDN) of that computer is cwaserver.contoso.com then the MTLS certificate should include the following information (with no subject alternative name required):

Subject name

  • cwaserver.contoso.com

The certificates assigned to the Communicator Web Access server and the certificates assigned to Office Communications Server do not have to be issued by the same certification authority (CA). This enables you to assign a certificate from a public CA to a virtual server used by external users. For details, see Requesting a Third-Party Certificate for Communicator Web Access. This is important for users who log on to Communicator Web Access from a public computer (for example, a computer in an Internet cafe) or a borrowed computer. If the virtual server uses an SSL certificate issued by a CA that is not trusted by the computer, the user will see a "blocked content" message when he or she accesses the Communicator Web Access sign-on screen. Although the user might be able to log on, he or she will not be able to send instant messages or participate in desktop sharing sessions. The only solution to this problem is to assign a new certificate to the virtual server, or have each client obtain a certificate from the CA used by that virtual server.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.