About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2010/07/21

single cert for ocs/exchange

this is a rewrite of previous post that got thrown away somehow…

Single certificate for OCS/Exchange firewall usage

Certificates can be complicated to understand, difficult to manage, and if you don’t have an internal PKI structure, downright expensive as you move forward with more and more dynamic applications that extend your Unified Communications to your remote users and business partners.

Internal certificates work wonders for your Active Directory Domain Services members. For Unified Communications, where OCS and Exchange are going to be using the same ISA 2006 server as the firewall, utilizing a Subject Alternative Name (SAN) certificate for your edge configuration and your ISA configuration can save you time, management hassles, and possibly provide cost savings as well. For internal servers, an internal PKI is just fine, but for the public interface of your system, you should most likely be looking at using a public-sourced key such as Go-Daddy, Thawte, DigiCert, etc. OCS Federation, remote users, and Public Instant Messaging Connectivity (PIC) demand public certificates. I know that I do not want to ship my internal CA root certificate to a slew of administrators and expect them to get that certificate into the correct spot for our systems to co-exist. But I digress.

The following table shows the SAN names needed on a certificate to support the base OCS and Exchange functions on ISA 2006/TMG/UAG – and I imagine that this certificate construction will work just fine on many other firewalls as well. The table comes from my test domain; you should replace my test domain with your own domain name.

Obtain a public SAN (UCC) certificate from your favorite provider; import the certificate into your OCS Edge server and your ISA server computer account Trusted Root Certificate store and then you can use one certificate for all these uses. This approach leaves you with only the one certificate to manage and renew, or, if life treats you badly, move to a new server.

 

SAN Name (what URL?)

Usage

Notes

1

SIP.tsoorad.net

OCS Edge Server

IM, Presence, Federation, PIC

2

LM.tsoorad.net

OCS Edge Server

Web Conferencing

3

AV.tsoorad.net

OCS Edge Server

A/V

4

OCS.tsoorad.net

ISA Reverse Proxy

Web Components

5

CWA.tsoorad.net

ISA Web Listener

Communicator Web Access

6

DOWNLOAD.CWA.tsoorad.net

ISA Web Listener

Cname for CWA desktop sharing

7

AS.CWA.tsoorad.net

ISA Web Listener

Cname for CWA desktop sharing

8

MAIL.tsoorad.net

ISA publisher

Outlook Anywhere, EAS, OWA, POP, IMAP

9

AUTODISCOVER.tsoorad.net

ISA Web Listener

Autodiscover is used by outlook and OCS.

No comments:

AudioCodes 400HD firmware v3.04

Those fine folks (and apparently busy beavers) at AudioCodes have popped a new IP Phone firmware release out into the wild. Brings a nice ne...