Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA) Part 1
By Thomas W Shinder MD, MVP
Have Questions about the article?
If you missed the other parts of this series, then check them out at:
- Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA), Part 2
- Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA), Part 3
- Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA), Part 4
A question that’s come up from time to time over the last few years on the http://forums.isaserver.org/ Message Boards and mailing list relates to using a commercial certificate in your OWA Web Publishing solution. Commercial certificates provide some advantages for a group of OWA publishing scenarios, so I thought it was about time to provide some guidance on this issue.
You may already know that the ISA firewall provides both stateful packet and application layer inspection for secure remote access connections to Microsoft Exchange Outlook Web Access. You might also already know that the ISA firewall provides a superior secure solution for secure remote access to Microsoft Exchange OWA, and you might know that the ISA firewall is the best solution for providing secure remote access not only to OWA, but to all of the Exchange Server’s mail services.
But do you know how to use a commercial Web site certificate to publish your OWA, OMA and Exchange ActiveSync sites?
There’s a chance that you don’t, since there’s no documentation on the Internet at this time on how to do it. This article series corrects this knowledge deficit.
Why use a Commercial Web Site Certificate?
Before getting started on how to make things work, the first question you should be asking yourself is why would you want to incur the expense and administration overhead inherent in deploying commercial certificates? Why not just fry up your own Web site certificates and bind them to the OWA Web site and the ISA firewall’s Web listener, like we have done in all the OWA articles on this site?
The primary advantage of using a commercial Web site certificate is that you don’t have to worry about populating the Trusted Root Certification Authorities certificate store with the CA certificate of the CA issuing the Web site certificate. Windows client operating systems come pre-populated with a collection of trusted root certification authorities and if you use a commercial certificate issued by one of the certification authorities, then you don’t have to worry about populating the Trusted Root Certification Authorities certificate store yourself.
Why should we care about this? If a Web client application tries to connect to an SSL site that presents its Web site certificate that was issued by a CA the Web client system does not trust, an error is generated at the client. Sometimes the error isn’t a big deal, like that you see with Internet Explorer. When Internet Explorer encounters a Web site certificate issued by a CA that the Web client doesn’t trust, a dialog box appears telling you that you haven’t configured your computer to trust the site and would you like to continue anyway.
The figure below shows what such a dialog box looks like.
Figure 1: Security Alert dialog box generated by Internet Explorer indicating that the client system does not trust the CA issuing the presented Web site certificate
Other applications are less forgiving. One major example is Outlook 2003 and RPC over HTTP. Many an Exchange and ISA firewall admin has been stumped by the fact that their OWA sites work fine, but their RPC/HTTP connections fail, in spite of the fact that they seemed to have done everything right. They might have done almost everything right, but they forgot one step: the failed to include the CA certificate of the CA issuing the Web site certification to the certificate bound to the ISA firewall’s SSL Web listener.
The Outlook 2003 RPC/HTTP client doesn’t have a mechanism to inform the user that the client machine doesn’t trust the CA issuing the Web site certificate. So, instead of informing the user of this situation, the connection just fails. There a other applications, such as the Windows Mobile 2003 ActiveSync and OMA that suffer from the same problems.
You don’t have to worry about this when you use a commercial certificate from a provider that has its root certificate included with the operating system. All you need to do is deploy public Web site certificates to the ISA firewall and optionally to the OWA site, and you’re good to go.
Certificate Common/Subject Names
If there’s one thing that tyro ISA firewall admins don’t “get”, it’s the importance of the common/subject name on the Web site certificates used in their Web Publishing solutions. The common/subject names are inextricably tied to how you configure the ISA firewall’s Web Publishing Rule and how you instruct both internal and external users how to access the secure Web sites.
The reason for this is that requests made to SSL sites must be for the name in subject name field on the certificate (often referred to as the common name). The figure below shows a high-level view of the processes that take place when you use highly secure SSL to SSL bridging when publishing your OWA and other Exchange SSL Web services.
Figure 2: Secure SSL to SSL bridging enables you to create end to end encrypted OWA connections while at the same time enabling stateful application layer inspection of OWA communications
- The external client sends a request to mail.msfirewall.org. The client sends a request to a public DNS server and resolves that name to the IP address on the external interface of the ISA firewall that is used by the SSL Web listener. After resolving the name, the request is sent to that IP address. The Web SSL Web listener has a Web site certificate bound to it and the common/subject name on the Web site certificate is mail.msfirewall.org.
If the common/subject name on the Web site certificate bound to the Web listener was www.domain.com and the request was for mail.msfirewall.org, the connection request would fail because the name in the request and the common/subject name on the certificate do not match.
In addition, the name in the request must match the name on the Public Name tab on the Web Publishing Rule used to publish the OWA Web site. If you haven’t worked with Web Publishing Rules, then you’ll see later in this article series where the Public Name is and I’ll reinforce the importance of using the correct name on the Public Name tab when we get to that section.
- The ISA firewall is configured with a Web Publishing Rule that accepts incoming SSL requests for mail.msfirewall.org. The ISA firewall first performs stateful packet inspection and after passing those security checks, the communications are passed to the ISA firewall’s stateful application layer inspection mechanism, which in this case is mediated by the ISA firewall’s Web proxy filter.
The communication is passed to the ISA firewall’s Web proxy filter after the ISA firewall decrypts the SSL communication. The decrypted data is inspected by the Web proxy and HTTP Security filters and parameters of the communications are compared to constraints set by the Web proxy and HTTP Security filters. These application layer inspection filters insure that only legitimate connections to Exchange Web services are allowed through the ISA firewall and passed to the Exchange Web site. If the communications do not pass these application layer inspection checks, they are dropped.
If the communication passes both the ISA firewall’s stateful packet and application layer inspection checks, then the communication is re-encrypted and a second SSL tunnel is created between the internal interface of the ISA firewall and the Exchange Web site (hosting access to OWA, OMA and Exchange ActiveSync.
During establishment of the second SSL tunnel, the ISA firewall acts as a Web client to the Exchange Web site. In the example provided in the figure, the ISA firewall is configured to send a request for https://owa.msfirewall.org. The Web site certificate bound to the OWA Web site must have the common/subject name owa.msfirewall.org in order to the connection request to succeed. If the common/subject name on the Web site certificate on the Exchange Server does not match the name in the request made by the ISA firewall, then the connection fails.
Have Questions about the article?
For you folks who have been following my OWA articles over the years, you’ll notice that I’m not using the same name from end to end like I usually do. I figured that some people are never going to come over to the wit and wisdom of a fully compliant split DNS, or they want to deploy a smart split DNS infrastructure, but they just can’t do it for reasons outside of their control.
For this reason the solution described in this document series using different names for internal and external access to the OWA web services. Later in this series I’ll explain why this works and how the ISA firewall’s ability to re-write host headers solves a lot of problems for us.
You’ll perform the following procedures that will enable you to use commercial Web site certificates to publish your OWA Web site:
- Create a Web Site Certificate Request on the OWA Server The first step is to create a certificate request on the OWA server. This is a text file that you use to submit your request to the commercial CA.
- Obtain the Web site certificate from the commercial CA After creating the certificate request text file, you then go to the commercial CA’s Web site and fill in the forms so that they confirm you identity. You also paste the contents of the certificate request file into the Web interface to make the certificate request.
- Install the commercial web site certificate and CA certificates on the OWA Site The commercial CA will either send you a certificate file, or an email with text that you paste into Notepad to create the certificate file. You return to the OWA Web site where you created the Web site certificate request file and install the certificate.
- Export the Web Site Certificate, with its private key and certificate chain, to a File and Copy the File to the ISA Firewall Now that the Web site certificate is installed on the OWA server, you’re ready to export it with its private key, to a file. The file will also contain all certificates in the certificate. You then copy the certificate file to the ISA firewall where you will later install the certificate into the ISA firewall’s machine certificate store.
- Remove the Web Site Certificate from the OWA Web Site We will be using a non-commercial certificate on the OWA site. We will create the private certificate using an internal Microsoft Certificate Server. We will need to remove the commercial certificate from the OWA Web site before you can install the new certificate.
- Request a Private Web Site Certificate for the OWA Web Site In the example used in this article series, we will use an enterprise CA. This allows us to make a request to an online certificate authority. We’ll use the OWA Web sites certificate request wizard to make the request and have it automatically installed and bound to the OWA Web site.
- Import the Commercial Web Site Certificate and Create the SSL Listener An SSL listener is a software component of the ISA firewall that accepts incoming SSL requests for the Web proxy filter. The Web proxy filter is a application filter that communicates with the ISA firewall’s firewall service and performs stateful application layer inspection on the incoming SSL connections. We’ll use this listener in the SSL Web Publishing Rule for the OWA site.
- Create the Web Publishing Rule The Web Publishing Rule contains instructions on how the ISA firewall should handle the incoming SSL connections to the OWA Web site.
- Configure Public and Private Name Resolution Name resolution is critical for all ISA firewall deployments. In this example provided in this article series, I’m going to depart from my typical split DNS solution and use different names for internal and external access. The DNS infrastructure must be configured to support the OWA Web Publishing solution so that it works for both internal and external network clients
- Test the Solution We’ll finish up the series by testing the solution and examining the log file entries to see how the connections are handled by the ISA firewall.
There are a lot of procedures and steps within those procedures that you need to carry out to get to the completed solution. It can sometimes get very confusing when you’re in the middle of the configuration process and you’re not sure where you are. For this reason, I’ve included a procedure map in the figure below. For each step in the process, I’ll reproduce the map and highlight where you are in the configuration process, sort of like a ISA firewall configuration GPS :-).
Figure 3: Roadmap for our commercial CA solution
The Big Picture:
The “big picture” for the solution is that we will bind a commercial certificate to the Web listener on the ISA firewall and a private certificate on the OWA Web site on the internal network. This saves us the cost of purchasing two commercial Web site certificates, which isn’t required. Only the external clients need the benefits of the commercial CA. The ISA firewall is a domain member (ISA firewall best practice) in a domain that has an enterprise CA, so the internal CA’s CA certificate is already installed in the trusted root certification authorities machine certificate store on the ISA firewall and all clients on the internal network that are domain members.
The lab network we’ll be working with appears in the figure below.
Figure 4: Network topology for the lab network used in this article series
The Exchange Server performs multiple roles on our lab network:
- Active Directory domain controller
- DNS server
- Enterprise CA
- WINS server
- DHCP server
- Exchange 2003 Server in single server configuration
The name of the Active Directory domain is msfirewall.org and the domain is in Windows Server 2003 mode. The name of the machine is EXCHANGE2003BE.msfirewall.org and the NetBIOS name of the machine is the same as the machine’s DNS host name.
The ISA firewall is a member of the msfirewall.org domain. This is done to both increase the overall level of security the ISA firewall can provide, by supporting user-certificate authentication and more importantly, to support the Firewall clients on the internal network. The ISA firewall has two NICs and no network templates are applied to the configuration.
We won’t use Network Templates because we want to configure the ISA firewall to meet our design requirements. However, we’ll use the default Network Template that’s applied transparently when you install the ISA firewall on a multihomed machine.
The external client is not a member of the domain and it is running Windows XP Service Pack 2. In our lab network, the external client has a valid address on the same network ID on which the external interface of the ISA firewall lies. I did this for convenience. I could have placed the client somewhere on a remote network over the Internet and the same principles would apply.
The goal of this article series is not to provide comprehensive guidance on how to publish OWA and other Exchange Server Web sites. There are a number or articles on this Web site (www.isaserver.org) and on the Microsoft Web site (www.microsoft.com/isaserver) on how to publish OWA and other Exchange Web services. You might also want to check out our book Configuring ISA Server 2004 for more information not only on how to publish OWA Web sites, but also for more comprehensive insight on how to customize Web Publishing Rules.
Have Questions about the article?
In this article we went over the advantages of using the ISA firewall to securely publish OWA Web sites and using commercial certificates on the ISA firewall’s Web listener. We also discussed how the ISA firewall’s SSL to SSL bridging feature works and the importance of certificate naming conventions when binding certificates to the ISA firewall’s Web listener and the OWA Web site. In this next article in this series we’ll begin the configuration process on the OWA Web site.
If you missed the other parts of this series, then check them out at: