how to use single Certificate for OCS 2007 R2 and Exchange 2007/2010

The calculator has been updated Please read the errata and the updated version of the calculator https://www.experts-exchange.com/articles/OS/Microsoft_Operating_Systems/Server/MS_Live_Communications_Server/OCS-2007-R2-Exchange-2010-DNS-calculator-errata-notes-and-updated-version.html

One of the key factors to ensuring a successful Exchange/OCS deployment is that the certificates and DNS configurations must be setup correctly. I can say that more than 90% of the issues I troubleshoot in Exchange/OCS implementations can be traced back to Certificates and DNS issues.

Exchange and OCS heavily rely on Certificates as a key element of secure infrastructure deployment by using MTLS and TLS. The challenge is that implementing the certificate is confusing and comes with a price.

In this post we will investigate how to overcome these challenges and how you can use a single certificate for our Exchange/OCS deployment. Let us cut to the chase and go to the cool stuff.

Exchange and SSL -- an old story I have to tell:

Exchange started using SSL certificates when Exchange 2003 was introduced. At that time things were simple. To implement the certificate, all you had to do was create a certificate with a single name, for example (mail.domain.com), where it resolved to the External IP that was Nat’d to the Front End Server IP or Virtual IP if you were using several FEs.

As we all know, implementing certificates in Exchange 2007/2010 is more complicated and cumbersome. Now we have your standard mail.domain.com and the new introduced autodiscover.domain.com to deal with. This change also created the need for UCC certificates.

UCC certificates allow multiple names to be included in the certificate. This type of certificate is commonly called a SAN (Subject Alternative Names). For those of you who have worked with ISA 2004 or 2006 this may recall some nightmares as these certificates were not supported.

In order to publish a website over SSL, the “to” field in the ISA publishing rule had to match the certificate’s common name or (subject name), or you would get the famous (the targeted principle name is not correct) error. So we had to use 2 certificates in order to work around that, or use a single certificate, but not use ISA to publish Exchange websites. What a headache!
  3.30-image-1-729189.bmp
OCS 2007 R2, like if Exchange is not enough:


When OCS 2007 R2 was introduced, more changes also needed to be taken into account. In OCS 2007 R1, Microsoft decided to use MTLS for server to server communication and TLS for server to client communication. This meant that you needed to use an internal Certificate Authority (CA) in order to issue certificates for internal servers. Implementing remote access solutions in OCS was not as simple as it was in Exchange because it did not work with internally issued Certificates. In addition, OCS required DNS entries internally that is different than your external DNS records. Is your head spinning yet? Let’s take a closer look at internal DNS records used for a typical OCS 2007 R2 Deployment:
  3.30-image-2-790762.bmp
Please note that Those IPs will be VIPs if you use HA deployment. They will be created using HLB (hardware load balancers) since OCS doesn’t support MS WLB.

Note: You can change comp.domain.com to any name you want, just make sure to enter that name in the setup or modify it using LCSCMD command line tool.


Now let us take a look at the external DNS records used by OCS by an external User:

  3.30-image-3-711327.bmp
Keep in mind that SIP is used for Edge client access, webcon and AVconf are sample DNS entries that could be changed as they are not hard coded.

Combine it all with Certificates:


Now you have a table that lists all of the DNS names that is required, all you need to do is pull a certificate for each name (duh, that is why I am here writing this post, we want them all in one certificate). You can use single certificate, but let us see first the names that I will need to include in the certificate:
  3.30-image-4-722898.bmp
The above table list all the names required for OCS and Exchange, but there are 2 catches here:

SAN certificates are not supported by ISA2004/2006 for SSL publishing, you will have to use ISA 2006 SP1 or TMG since this issue were fixed in both versions.

If you use single certificate for Edge web conference and Edge Access, you will find that Edge server requires that names must be matched between Access/web conference IPs (you will note that in the edge server configuration wizard, you will be able to change the name, but it will not take effect), so the name must be matched, thus the same IP must be used so you will have to change the ports between access and web conference (in typical configuration Access/Web conf will use port 443, since OC clients are hard coded to try to use port 443, so you will have to change the web conf port to any other port, use 444 for simplification).
The final note has 2 catches:

444 is a non standard port so you might have to adjust your firewall.


If you want to use port 443, then use a separate certificate for the Web Conference edge server IP.
You might wonder how I can change the port of the web conference without affecting the information worker, well the following diagram elaborates how web conference tokens are created:
  3.30-image-5-735180.bmp
The story begins when an external user clicks on the conference link (this external user is either domain user or anonymous user), then the following occurs:

The users access the Access Edge server and to get authenticated (Kerberos, NTLM for domain users or digest for anonymous users).

The front End server component contacts the web conf server component, AV component, Web component to add the user to the WEB MCU and AV MCU.

Pay attention in this step please, the user gets back an authentication token and configuration cookies that has the web conf edge/AV conf edge configuration and this is where the client gets notified about the ports used by the edge servers.

So as you can see web conf and AV conf ports are not hard coded, but are passed to the user in the config tokens.

Please note the web conf, front end and AV conf servers are located in the same box, but they were separated to elaborate how they work internally.

Avoid this common mistake:

One of the most common mistakes that we encounter in OCS implementations is seeing the FQDN for the AV authentication server and the port set to 443. This is not correct and will result in calling errors on the Office Communicator client. Please make sure that the AV authentication service uses port 5062.

Now after tons of notes, let’s make our final names table:

  3.30-image-6-783594.bmp
If you follow the suggestions listed in this article you will be able to use a single certificate for Exchange and OCS. Please note that I did not cover the internal edge certificate and pool certificate names as they are fairly simple to implement.

To help you, I have created my own Exchange/OCS certificate and DNS calculator. Please note this calculator is not supported by Microsoft and you should verify your configuration with a professional OCS/Exchange consultant. The calculator is very simple to use. All you will have to do is enter the OCS sip domain, host names used by edge server, OCS server type either (standard or enterprise) and DNS names and the certificate configuration will be created for you automatically.

To download the calculator, please use the link and credentials below:

Exchange/OCS Calculator:

http://support.enowzone.com/Downloads/OCS-DNS-Certificate-calculator-V1.4.xlsx

Credentials:
Username: enowzone\ese

Password: Tool4you

I hope that in this post I was able to help you out in your deployment and eliminate the confusion caused by using a single certificate for OCS and Exchange. Have a nice deployment and see you next time!