– How many public certificates do I need, in order to configure external access to my OCS 2007 pool?
– 3. One for the HTTP Reverse Proxy, one for the OCS Access Edge and one for the OCS Web Conferencing Edge.
– Even if I'm using a consolidated Edge topology?
– Yes!
– But can't I just use a super-mega-jumbo SAN certificate with all the required alternative names?
– No!
– Why not?
– Because!

Well, to tell you the truth it's not "because", it is the official support policy written in the OCS 2007 Supportability Guide, the OCS 2007 Planning Guide and the OCS 2007 Edge Server Deployment Guide.

Here's a summary of the external certificate requirements:

• For each unique IP address on the external interface that you use for the Access Edge Server and Web Conferencing Edge Server, you will need a separate certificate. We recommend that you use a separate external IP addresses for each server role, even if all servers are collocated. An external certificate is not required on the A/V Edge Server.
• Office Communications Server 2007 will support certificates with a length of up to 1024 bits.
• Office Communications Server 2007 server certificates must be configured with an enhanced key usage (EKU) extension for server authentication.
• For a list of public certificate authorities who have partnered with Microsoft to ensure that their certificates comply with specific requirements for Office Communications Server, see http://r.office.microsoft.com/r/rlidOCS?clid=1033&p1=SupportedCAs.
• For both internal and remote clients, the CA certificate chain for the Office Communications Server 2007 deployment must be downloaded and installed to the certificate store of the client computer in the Trusted Root Certification Authorities folder.
• All server certificates must support server authorization (Server EKU 1.3.6.1.5.5.7.3.1).
• All server certificates must contain a CRL Distribution Point (CDP).
• Auto-enrollment is supported for internal Office Communications Server servers, including an array of Standard Edition Servers configured as Director.
• Auto-enrollment is not supported for Office Communications Server edge servers.
• For the A/V Edge Server, an additional certificate is required for audio/video authentication. The private key of the A/V authentication certificate is used to generate authentication credentials. As a security precaution, you should not use the same certificate for A/V authentication that you use for the internal interface of the A/V Edge Server. We recommend that you issue this certificate from an internal CA, but you can also use a certificate from a public CA

– But why can't I just use my internal CA?
– Well, to tell you the truth, it's technically possible, as long as you remember these guidelines:

• Public certificates are required if you enable Web conferencing and enable your users to invite anonymous participants (individuals from outside your organization that do not have Active Directory credentials).
• Public certificates are required for public IM connectivity, and they are highly recommended for enhanced federation. The public certificate must be from a public CA that is on the default list of trusted root CAs installed on the server.
• It is possible to use your Enterprise subordinate CA for direct federation, as well as for testing or trial purposes if all partners agree to trust the CA or cross-sign the certificate.

It is very unlikely that these requirements will change with the release of Office Communications Server 2007 R2.

Recently, I was doing some tests with Exchange Unified Messaging, but when I tried to connect to Exchange Voice Mail using Communicator R2, I got the following error:

"Incompatible security setting. 
The call could not be completed because security levels do not match"

An Exchange UM dial-plan supports three different security levels: Unsecured, SIP Secured, and Secured. The following table shows the differences in terms of Mutual TLS and SRTP for the various security levels.

When integrating Exchange UM with Office Communications Server 2007, consider the following when selecting the dial plan security level:

• Mutual TLS is required between Exchange UM and OCS, therefore the Unsecured level is not an option.
• Office Communicator 2007 clients support SRTP (Secure Real-Time Transport Protocol), therefore both Secured as well as SIP Secured security levels can be used. The encryption level that Communicator uses can be set by means of Group Policy or by changing the PC2PCAVEncryption registry key.
• If Communicator Phone Edition (aka Tanjay) is deployed, the security level should be set to Secured.

The registry key PC2PCAVEncryption (REG_DWORD) can be used to specify whether encryption is supported, required, or not supported when making and receiving audio and video calls. The supported values are:

• 0 = Support encryption, but do not require it. Should only be used with the TLS network protocol. (default)
• 1 = Require encryption. Unencrypted calls are not accepted. Should only be used with the TLS network protocol.
• 2 = Do not support encryption. Encrypted calls are not accepted.

BTW, if you're playing around with this registry key (or any other), you may find useful to know that Communicator uses the following precedence, when applying settings:

1. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Communicator
2. HKEY_CURRENT_USER\Software\Policies\Microsoft\Communicator
3. Office Communications Server 2007 in-band provisioning
4. Communicator 2007 Options dialog box

Further investigation revealed the following error on Communicator logs:

"SIP/2.0 415 Unsupported Media Type"

After this, it seemed quite obvious that the problem had to do with encryption, more specifically to the SRTP setting. The solution? There are 2 possible ones:

1. Change the Exchange UM VoIP Security level to "Secured" (it was SIP Secured before).
2. Create the registry key PC2PCAVEncryption and change its value to 0

One final note: the problem didn't affect Office Communicator 2007, only the R2 client, so we can assume the R2 clients will be more secure than its predecessors.