We are currently going through design and implementation of an Exchange 2007 environment in my organization. Our current e-mail architecture is varied and does not have any version of mail services newer than 6 years old. So, we are learning a lot about Exchange and how it can fit our environment of over 2,200 users globally.
Part of our requirements includes providing access to downlevel clients (Windows 2000 and below) as well as access to remote users. This will be easily accomplished through Outlook Web Access (OWA). As you know, OWA login is usually done on a page with an https or secure sockets layer (SSL) address. The SSL encryption is provided by a certificate hosted on that server. The certificate can be self-signed by the server, signed by an authorized certificate authority (CA) in the organization or by a trusted third-party provider like Verisign or Thawte.
If the certificate is self-signed by the server or by an organizational CA, then somehow the clients need to know about the trusted root or they need to accept the warning that the browser gives when they login to the website. You want the users to understand what trust means or take the question out all together. I vote for the latter. Remove doubt that the certificate is from a trusted source.
For the external OWA connections, we are purchasing certificates from a recognized third-party. I have gone through several iterations of getting certificates though since this is my first time getting these for an Exchange environment. There is a particular “flavor” of certificate known as a subject alternative name (SAN) or unified communications certificate. A great article on this can be found here. (Take note of the root website here. It is one of the best and most readable Exchange resources you will find since it comes from the Microsoft Exchange product team.)
So, I am now in the process of getting these SAN certificates and will be implementing them this week so the errors will go away when users login to these portals since they know and trust the root certificate authority.
The next challenge is to address this same issue on internal private OWA servers. We will be implementing a two-tier enterprise CA architecture using an offline root and a single enterprise CA. We will be publishing this through Active Directory so the clients recognize this as an internal trusted root. We are then positioned to use this CA for other uses: digital signatures, S/MIME, 802.1x, device authentication and other uses.
As you can tell, this has been a lot of education and work for my company. We have had some help in these efforts since this is entirely new to us and we have to implement it successfully the first time. I will let you know how things go.
Thanks for your time. Let’s be good network citizens together & practice safe networking!