Secure Outlook Web Access with (free) SSL

By Justin Fielding

Takeaway: I have recently spent some time building a small Active Directory / Exchange 2003 environment in my home lab. One thing that bothered me was the lack of encryption while using Outlook Web Access (OWA) in its default state. Over the next couple of weeks I’m going to run through the steps needed to secure [...]

I have recently spent some time building a small Active Directory / Exchange 2003 environment in my home lab. One thing that bothered me was the lack of encryption while using Outlook Web Access (OWA) in its default state. Over the next couple of weeks I’m going to run through the steps needed to secure OWA from requesting a certificate to installing CA trusts on the client side.

Digital certificates

In order to secure OWA, the first thing we need is a valid certificate. There are three ways you can get this:

1. Buy a certificate from Verisign, Thawte SSL 123, etc.
2. Create your own CA and Certificates.
3. Obtain a free certificate from StartCom!

If cost is not a consideration, and the services you want to secure are going to be used by the public at large, then buying a domain root certificate ( e.g *.mydomain.com) is probably the best solution. The certificate authority will already be recognised by 99.9% of operating systems, browsers, and applications requiring no additional configuration on the client’s part.

Creating your own Certificate Authority and the accompanying certificates is not too much of a challenge. Check out this article over at petri.co.il, which covers installing the Certificate Authority (CA) service for Windows Server 2003. Users will need to have your CA registered as a trusted source in order to avoid those annoying certificate errors. This shouldn’t be too much hassle if your users are internal, as installing the CA root can be slotted in as part of the standard build process for new machines.

The third way is something of a compromise between the two. StartCom is, so far as I’m aware, the only CA giving away completely free SSL certificate. They believe that everyone has the right to secure computing regardless of their financial status. There are no thirty-day trials, no ninety-day trials; just 100  percent free certificates. So what’s the catch? Currently, not all software houses recognise StartCom as a secure CA and, therefore, their signed certificates as trusted. StartCom are working on this and Firefox, Netscape, Thunderbird, and Mozilla all recognise their authenticity. Mac OS X and Safari will be trusting the StartCom CA as of version 10.5 (Leopard) later this year. Microsoft do not recognise StartCom yet but work is in progress. As mentioned above, installing the new CA as a trusted source is quite easy and can be part of the standard build process.

As I’m only using my lab setup for testing, there doesn’t seem to be much point in paying for a certificate. Creating my own CA is an option, but I decided to go for a StartCom certificate as it’s already trusted by a large number of applications with more to follow in the near future.

The process of obtaining and installing a certificate is fairly straightforward:

• Generate a new certificate request
• Export certificate request
• Request certificate from CA (StartCom)
• Import generated certificate
• Add CA trust

Generate a certificate request

Let’s start by generating a certificate request on the server hosting OWA:

1. Open the IIS Manager from Administrative Tools.
2. Browse to Local Computer | Web Sites and open up the properties pane of your Default Web Site.
3. In the properties pane select the Directory Security tab and click on Server Certificate… button.
4. Select Create A New Certificate.
5. Next, choose the option Prepare The Request Now But Send It Later.
6. Enter a descriptive name for the certificate; this is for your own reference. I used Exchange SSL Certificate.
7. The next options are for Organisation and Organisational Unit. I opted to use Home Lab and Testing Unit. These are supposed to relate to your company and branch/unit but their content isn’t critical.
8. The Common Name is extremely important. This must match the Fully Qualified Domain Name (FQDN) of your Exchange server. That is the address that will be used externally to gain access. In my case this was mail.externaldomain.com. I am obviously not hosting my Exchange / OWA server directly on the Internet, but I have an ‘A’ record setup in my DNS for mail.externaldomain.com, which points to my router’s external address. The router redirects any incoming connections on port 443 to the Exchange server.
9. Enter geographical options as accurately as you can.
10. Specify a location to save the certificate request. I like to rename my requests to something more meaningful than the default certreq.txt; in this case I have used mail.externaldomain.com certreq.txt.

That’s it. The certificate request has been generated and is ready to be processed. Next week, I’m going to run over the task of requesting a certificate from StartCom and then enabling the generated certificate in IIS to secure OWA. I’ll also take a look at ways in which we may be able to overcome the issue of CA trust in Internet Explorer to get rid of those nasty red address bars and certificate alerts.

Source URL:-http://www.techrepublic.com/blog/networking/secure-outlook-web-access-with-free-ssl-part-1/293