Re: OWA and SSL woes

  • From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
  • To: "[ExchangeList]" <exchangelist@xxxxxxxxxxxxx>
  • Date: Wed, 25 Feb 2004 07:30:25 -0600

Hey guys,

That's one of the primary advantages that ISA firewalls have over PIX.
The PIX just passes exploits contained in the SSL tunnel over to the OWA
site, and you have to hope that the OWA Web server is adequately
hardened against attack. In contast, the ISA firewall is able to perform
SSL to SSL bridging. 

The first SSL connection is to the external interface of the ISA
firewall. The ISA firewall then decrypts the messages and exposes them
to URLScan and any other Web filter you have installed on the ISA
firewall that performs application layer inspection for HTTP
communications. If the communication passes inspection, then the ISA
firewall re-encrypts the HTTP communication and establishes a second SSL
link, this time between the internal interface of the ISA firewall and
the OWA site. 

If the HTTP communcation does not pass inspection, the ISA firewall
drops it. In contrast, the pix just passes it through because the
exploits are hidden in the SSL tunnel between the remote client and the
OWA site.

One key factor is that you install the Web site certificate on the ISA
firewall and bind that certificate to the Incoming Web Requests
listener. This is how the ISA firewall "impersonates" the OWA site. The
Common Name on the certificate must be the same as the name the user
uses to access the Web site. For example, if the user enters in the browser, then the Common Name on
the certificate must be 

In addition, the redirect used in the Web Publishing Rule must use the
same name, so that the HTTP request that is forwarded to the OWA Web
site is to and *not*, for example, If this redirect is not configured
properly, the external client will receive an Internal Server Error 500

Finally, you should either configure a split DNS so that the ISA
firewall resolves this name to the internal address used by the OWA
site, or create a HOSTS file entry that resolves the FQDN to the address
of the OWA site that its listening on in the internal network.


Thomas W Shinder
ISA 2004 Beta - Get it now!
ISA Server and Beyond:
Configuring ISA Server:


-----Original Message-----
From: Zoran [mailto:zmarjanovic@xxxxxxxx] 
Sent: Wednesday, February 25, 2004 7:40 AM
To: [ExchangeList]
Subject: [exchangelist] Re: OWA and SSL woes

In case with ISA, there is no direct connection between client and
server. You need to install a certificate on ISA and configure it to
listen on 443, then ISA establishes one session with the owa client and
another with the e-mail server. With Cisco pix you have a direct
connection (open 443). Check the situation with your firewall. I am not
sure that cert common name has to match your external OWA FQDN. If you
a certificate for securing communication channel (you created the new
server certificate), check if you disabled integrated authentication on
Exchweb, Exchange and Public virtual subdirectories on IIS and ESM.


> Looks like port 443 is being blocked somewhere, despite assurances to
> the contrary.... Looks like that's probably the issue here.

List Archives:
Exchange Newsletters:
Exchange FAQ:
Other Internet Software Marketing Sites:
Leading Network Software Directory:
No.1 ISA Server Resource Site:
Windows Security Resource Site:
Network Security Library:
Windows 2000/NT Fax Solutions:

Other related posts: