More on OCS Edge Server Certificates

There are a pair of related Office Communications Server 2007 topics I wanted to expand on from previous blog articles that I’m still seeing come up quite often in both day-to-day projects and in the Microsoft discussion forums. One of them is centered around adding and supporting additional SIP domains. And because the two most common topics in OCS-related issues are Certificates and the Edge Server, it makes sense that deploying certificates on an Edge Server might just be the other topic. Although the screenshots and details will be specific to the more current R2 product, all of these requirements and recommendations apply equally to both 2007 releases.

Edge Server Certificates

So it is probably a good idea to first review the certificate requirements and spell out an important point that is not always clear to the first-time reader of the documentation. Way back in November 2007 I posted an in-depth article that covered many facets of the Edge Server which included this very breakdown of certificate requirements:

• Internal Interface
  • Issued by internal Windows Enterprise CA
  • Subject Name is the server’s FQDN (e.g. ocsedge.contoso.local)
• Access Edge Server
  • Issued by trusted third-party certificate authority
  • Subject Name is the FQDN used by the client to connect (e.g. sip.contoso.com)
• Web Conferencing Edge Server
  • Issued by trusted third-party certificate authority
  • Subject Name is unique FQDN (e.g. webconf.contoso.com)
• A/V Authentication Edge Server
  • Issued by internal Windows Enterprise CA
  • Subject Name is unique FQDN (e.g. av.contoso.com)

This outline mirrors the requirements spelled out in the Certificate Requirements for External User Access portion of the official documentation. The recently released Certificate Deployment White Paper also further enforces this recommendation. That said, it is possible to use the same certificate on both the Access Edge and Web Conferencing roles,

The key point to understand from the requirements is that the A/V Conferencing Edge service does not use, nor require a certificate. But the A/V Authentication service does require a certificate. This separation can be easy to confuse since the A/V Conferencing and A/V Authentication components can often be misunderstood to be one in the same. Technically they are part of the same core role (A/V Edge) and both used for audio and video communications (as well as Desktop Sharing in R2), but are in fact two separate, distinct services:

The terminology can be a bit cloudy as the A/V Conferencing Edge is also sometimes referred to simply as the A/V Edge role (as seen above in the Services applet). An important distinction between the two services is that the A/V Conferencing is an externally-listening service while the A/V Authentication is internally-listening service, as shown in the Edge Interfaces property tab:

The OCS Certificate Wizard probably best depicts this as A/V Authentication Certificate option is quite clear here:

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

The other important clarification from the documentation above is that the A/V Authentication service (being an internal communications service) does not require a certificate from a trusted third-party Certificate Authority. The same internal Enterprise CA that issues the Internal Edge certificate should be used for A/V Authentication, but not the same certificate; each role should have its own dedicated certificate. Of course if no internal CA is available then a trusted public Issuing CA can be used for any and all of the roles, it’s just more costly.

Why use Dedicated Certificates?

I’ve seen all the arguments for wanting to use a single certificate for all the Edge Server roles and they almost always break down to a single issue: Cost. And companies on a tight budget certainly can and will balk at the first sight of the needing 4 certificates, especially if the deployment of an Exchange 2007 Server certificate with all 147 SAN entries is fresh in their minds.

But when comparing costs of the certificates for a single, simple deployment of OCS it can actually be cheaper to purchase multiple certificates instead of one. First off, it has been established that 2 of the certificates should be issued by an internal private CA which is typically handled by an in-place Windows Server Enterprise Certificate Authority. Cost so far: $0.

This leaves only the two remaining externally-facing, certificate-requiring services: Access Edge and Web Conferencing Edge. The typical argument is to attempt using the same certificate on both roles in order to ‘save money’. But a more costly SAN certificate would be required as the Common Name value in the Subject Name field would need to be set to the Access Edge FQDN (typically sip.domain.com) while the Web Conferencing Edge FQDN would need to be included in the Subject Alternative Field (SAN) (e.g. webconf.domain.com). Most of the major players in the field offer UCC or SAN certificates at roughly more than double the cost of their standard SSL certificates. For example, looking at Digicert’s current offerings one can see that the cost of a single UCC cert for 1 year is $328 but the cost of two separate standard SSL certificates would be $144 each, at a combined cost of $288. Thus, it is pretty hard to argue against best practice recommendations when it also ends up being more expensive.

Additional SIP Domains

But if an organization is required to support more than one SIP domain with Automatic Sign-In for external user access or for anonymous external Live Meeting access then the above cost savings comparisons are not as relevant. Following is a brief review of why these two requirements might impact certificate costs.

Assume the above configuration is in place with a single supported SIP domain of contoso.com. Once a second SIP domain (fabrikam.com) is required for external access, then a whole chain of dependencies is put into place:

1. If a user with a sign-in name in the additional SIP domain (jeff@fabrikam.com) needs to login exte
   rnally via Edge using Automatic Configuration with Office Communicator then there will need to be a publicly-resolvable SRV record (_sip._tls.fabrikam.com) in the same domain as the OCS user’s sign-in domain.

2. That SRV record must point to an A record in the same domain (sip.fabrikam.com), it cannot point to an A record in another domain (like sip.contoso.com) as then the Automatic Configuration process would fail.
   
3. Because the OC client is given (via DNS) the hostname of sip.fabrikam.com to connect to for Access Edge services, the assigned certificate on that Edge server must include that hostname. If it is currently only configured with a Common Name of sip.contoso.com then the OC client will fail to connect with a certificate name mismatch error.
   
4. Additionally if that same user sends a Live Meeting initiation to a foreign party with the intention of having them join the meeting anonymously over the Internet, the sending user’s SIP domain (fabrikam.com) is what the anonymous user’s Live Meeting client will perform an SRV record lookup against. This puts the anonymous Live Meeting client into the same scenario as the Office Communicator client using Automatic Configuration.

This means that the Access Edge certificate needs to have entries for both SIP domains (sip.contoso.com and sip.fabrikam.com) moving it up into the more expensive SAN-certificate category. But for the same reasons as shown in the process above the Web Conferencing Certificate does NOT require modification. Only the Access Edge FQDN needs to be resolved in some way by clients and once a connection is made from the client, all other service FQDN values (Web Conferencing, A/V Conferencing, External Web Farm, etc) are passed in-band to the OC or LM client. Regardless of what SIP domain a user signs in with (@fabrikam.com) the other services are all still configured with a single FQDN value using the original primary SIP domain (webconf.contoso.com, av.contoso.com).

Now the certificate cost scenario is a bit more of a debate than before. When supporting a single SIP domain the cost savings was $40/year to go with the best practice recommendation of dedicated certificates. But with the requirement of at least one SAN cert there are two viable options:

1. Replace the Access Edge certificate to a SAN certificate (and leave the standard certificate on the Web Conferencing Edge) at a total cost of $472/year. This solution retains the more secure, best practice approach that will be easier to troubleshoot and manage over time.
   
2. Replace both the Access Edge and Web Conferencing Edge certificates with a single SAN certificate for $288/year and insert the Web Conferencing Edge FQDN into the SAN field in addition to all supported SIP domains.

Regarding choice #2, if the same certificate is assigned to both Access Edge and Web Conferencing Roles then the configuration will look a little strange on the Web Conferencing Edge properties. Since the certificate’s Common Name would be the sip.contoso.com entry, then that entry would be displayed as the FQDN, and not the desired webconf.contoso.com entry which is stored in the certificate’s SAN field:

This would seem like it should cause a problem, but it actually does work. This is because the Web Conferencing FQDN that is handed out in-band to connecting clients is actually pulled from a different setting in OCS and not the value shown above, which is simply reflecting a portion of the certificate’s Subject Name. The actual Web Conferencing External FQDN is stored in Active Directory and is configured on the internal server by accessing the Web Conferencing Edge Server tab on the pool’s Web Conferencing Properties in the OCS management console:

But ultimately, if neither of the automatic sign-in or anonymous access features are required (thus Manual Configuration will be used for all external Office Communicator and Live Meeting client connections) then the original SAN-less certificates can be retained as all external services will be resolved and connected to using the current A records in the primary contoso.com domain, regardless of how many additional SIP domains were added.