How to get external SAN UC SSL certificates that work with OCS 2007 R2 and avoid having to read 100 blog posts!

Been reading up on external and internal DNS names used by OCS 2007 R2 ? Your head stopped spinning yet? So you’ve decided on what FQDN’s to use, next step order some SSL certificates, should be easy enough right, You allready figured out You need SLL certificates that are Unified Communications Certificates (UCC) enabled. In my example I will use GlobalSign Domain Validated SAN’s, if I needed multiple domains for example for and, I would choose GlobalSign Organisation Validated SAN’s instead.

For a GlobalSign SSL certificate to be UCC enabled, it must use SAN domains, no other way of enabling it. So no point in spending lots of budget on seperate SSL certificates for each service. SAN Subdomains are also quite alot cheaper than buying seperate SSL certificates.

One of the tricky parts of Office Communications Server 2007 R2 and SSL certificates, is that You can not use one single SAN SSL for all services, if You intend to use port 443 for all services!

Why would we only use port 443 ? Most of the communications used by OCS will be encrypted, from many companies the only allowed encrypted communication to the internet is allowed on port 443 due to HTTPS being on that port. So by configuring all the services on port 443, we have a higher chance of getting to our servers, when using an internet connection at remote locations, hotels, partners, etc.

This means we will need to configure all services for port 443, each service will need it’s own public IP, and SSL certificates that matches the servers public FQDN. Internally we will use internal PKI to secure communications. This blog post only focuses on the external services and it’s SSL configuration.

One of the issues we will run into, is that the “Access” and “Web Conferencing” services both located on the OCS Edge server, have a perculiar way of setting the configured FQDN – it reads it directly from the Common Name of the assigned SSL certificate! Even if You try to change the FQDN on the service, it will revert back to the Common Name in the SSL certificate.

If You use on the Access server and on the Web Conferencing server, but use a SAN SSL certificate with Common Name and SAN name, it will still change both services to FQDN Only way that will work, is if the two services use different ports – i.e. 443 and 444 (not what I want).

All other services play nice, so in my case, I opted to creating 2 UCC SAN SSL certificates, and to ensure both became UCC enabled, I did 1 certificate with 3 of the services, and the 2 certificate with 2 of the services.

Example on how i map services -> fqdn’s -> Server -> SSL.

Service FQDN Server SSL#
Access Edge SSL#1
Client Web Access ISA->CWA SSL#1
Web Conferencing Edge SSL#2
A/V Edge SSL#2

On the edge server it should look like below, make sure the Access and Web conferencing services do not have same port AND same FQDN! (only one has to be different)

Using this example, we then order our certificates with the following info, from GlobalSign I would recommend ordering it with AutoCSR. If Your CSR request is missing begin and end tags, and your SSL provider requires them, just add them manually “—–BEGIN CERTIFICATE REQUEST—–” header and “—–END CERTIFICATE REQUEST—–“.


  • Common Name: (important the Access service is the common name)
  • Subject Alternative Name’ss (SAN’s):,


  • Common Name: (important the Web Conf. service is the common name)
  • Subject Alternative Name’ss (SAN’s):

Now install Your SSL certificates, remember to install the Intermediate SSL certificate relevant for your purchased SSL (GlobalSign have a special one for OCS 2007 R2!), select the correct certificates for Your services, test that it all works and you installed the intermediates ( and spend some time watching geeky TV series!

Recently I found a good blog post related to this topic but using only 1 SSL certificate, I would suggest reading it as well, alltough what FQDN’s, Port’s to use, SSL configuration, etc. IS a very individual choice of flavour and in that post he uses different ports for Access and Web Conf. to allow a single SSL certificate to be used. There was also a “calculator” for figuring out FQDN names to use for OCS2007R2, in this case calculator means an Excell spreadsheet, but it still helps 🙂

The above configuration with all ports on 443 has served me well, and cheaply.

Enjoy and feel free to link, comment, steal or do what You like with this information.

One Response to “How to get external SAN UC SSL certificates that work with OCS 2007 R2 and avoid having to read 100 blog posts!”

  • Sole:

    Additional information. The OCS Edge servers internal interface service also requires the common name (CN) of the SSL certificate used to be the internal interface FQDN.

    In other words the internal name of the OCS edge server can not use a SAN name from another SSL certificate. This is usually not a problem since in normal environments this certificate will come from the internal PKI infrastructure.

    I have still not experienced any problems using a SAN name for the A/V service on the Edge Server, but considering all other services require the primary CN of the SSL certificate, it would be logical to assume that the A/V service may in some situations require this.

Leave a Reply