Decision point – Which certificates to use?
The best way to approach the use of certificates for a publicly accessible web site is to acquire a
certificate from a known Certificate Authority such as Verisign.
The advantage of such certificate is that the issuer (the company which owns the certificate authority
who generated the certificate) is already trusted by Windows based computers. You can use Internet
Explorer's Internet Options and Content tab to see the list of trusted certificate authorities. Another
option is to open an mmc console and use the Certificates snap-in to view the list of Trusted Root
If you cannot afford the purchase of a publicly signed certificate, you can issue your own certificates
using a Windows 2000/2003 server, with the free Certificate Authority services within those network
In some cases, such as when using the Exchange 2003 RPC over HTTP feature, you will be required to
manually import the home-brewed CA certificate to the client computers in order for those computers to
trust the unfamiliar Certificate Authority.
Create your own certificates
To issue your own certificate from a Windows 2003 server, use the following steps to install the required
Open Add/Remove programs, and select Add/Remove Windows components.
To make the process to issuing certificates easier, you should install both
the IIS server and the Certificate Services which include both the Certificate Authority installation and
the Certificate Services Web Enrolment support.
During the installation process you will be asked to select which type of Certificate Authority you would
like to install. If the sole reason you install the CA is to generate a web site certificate, select a "Stand-
Alone root CA". In a larger environment when PKI infrastructure is deployed you should check if an
Enterprise root CA is installed - which will be able to issue the certificates.
Continue the installation process; provide a common name for the CA. I suggest you enter the public
domain that you are using. In the following case I used my own registered domain name: liran.org
Accept the installation defaults and finish the installation.
When done, you will notice that on the CA server, a CA certificate is placed in the
%windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the
trusted root Certificate Authorities store on the ISA firewall later on.
Generating the web site certificate request
Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services
(IIS) Manager tool from the Administrative Tools menu, and expand the web sites tree. Locate and
click Properties on the Default Web Site, which holds the OWA virtual directories. Select to the
Directory Security tab, and click Server Certificate…. In the Wizard select: Create a new
Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as
Default Web Site, and the Bit Length: 1024 and click Next. Type the name of your organization and an
OU, and click Next. In the Common Name window, make sure to enter the exact FQDN that will be
used by external users to access the OWA web site. If the following example I used owa.liran.org. You
should register this record with your publicly available DNS service provider for your domain. This record
should point to the ISA firewall external interface IP address.
For smaller companies, the external IP address of the ISA firewall may already be configured on your
public DNS for your domain as the MX record with a name such as mail.liran.org . When creating the
certificate, you may use this record as the certificate common name, and save some time on calling the
DNS provider for additional DNS record registration, but I will advise against it as you might want to set
up a mail gateway in the future which will use the mail.liran.org as the MX record, but will no longer
point to the ISA External interface IP address. The is no problem having more then one DNS record
pointing to a single IP address, so just add another host record such as owa.liran.org.
Continue running the certificate wizard, enter additional information in the Geographical Information
page. In the Certificate Request File Name page make sure to note the location and file name of the
certificate request file. The default location is c:\certreq.txt. Continue the process and click Finish.
Form a request to a certificate
To approve the certificate request, open a web browser on the Exchange server and enter the URL to the
CA server. For example: http://CAServer/CertSrv (replace CAServer with the IP address or computer
name of your CA server) On the Certificate Services Welcome screen, click Request a certificate.
Select advanced certificate request, and click Submit a certificate request by using…. On the
Submit a Certificate Request or Renewal Request page focus on the Saved Request window.
Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code
between the Begin and End sections, and paste into the Saved Request window.
When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the
certificate server, open the Certification Authority console from the Administrative tools menu.
Expand the CA, and navigate to the Pending Requests tree. On the right pane you will see the
certificate request just waiting there to be approved. Right click the certificate and select All Tasks and
then Issue. The issued certificate will be moved to the Issued Certificates container.
Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv ,
and click View the status of a pending certificate request. Click the saved request certificate link,
and select Download certificate using the DER Encoded. Save the file certnew.cer to the Exchange
server desktop. Open the IIS console on the Exchange server, and again navigate to the Directory
Security tab of the Default Web Site. Click Server Certificate… and use the wizard to process the
pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish,
and OK to close the properties page. Restart the Default web site.
At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or
If you try to access the OWA web site using a web browser with https://, you might be prompted with an
Alert such as the following one:
Note that the Alert contains three parts as explained:
a. Warning will appear if the CA that generated the certificate is not trusted.
In case you generated the certificate yourself from a privately installed CA,
you will need to import the CA certificate to the computer Trusted root
certificate authorities store. This is NOT required process on every client
unless you find this message very annoying.
b. Warning will appear if the certificate dates are invalid.
This could happen if the date scope of the certificate does not match
the date settings on the browsing computer, or if the certificate dates
themselves either will start in the future or already ended.
c. Warning will appear if contacting with a URL that is different for the
certificate common name.
In the above example I used the server NetBIOS name instead of
https://owa.liran.org/exchange, which caused the alert to appear.
In order for ISA firewall to properly publish the secured web site, you must make sure that SSL
connection to the OWA web site will not fail any of the above tests. This will be covered later on.
Importing the certificates to the ISA firewall.
The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL
connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a
To do so, return to the Directory Security tab of the default web site on the Exchange server, and click
View Certificate. On the certificate window, select the details tab, and click Copy to file. In the
wizard, select Yes, export the private key, select to enable strong protection, set a password, and
select to save the certificate to a file named c:\owasitecert.pfx. Copy the file to the ISA firewall hard
drive. As I explained at the last section on step 1, the ISA 2004 server must be able to perform SSL
client connectivity to the Exchange secured OWA site without any warning messages.
Checking SSL connectivity between ISA 2004 and the OWA site
Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD
console, and enter the following line to test SSL connectivity: telnet ExchangeIP 443. (Replace
ExchangeIP with the Exchange server internal network IP address).
If a connection could not be made, create a computer definition for the Exchange server in the ISA
console, and then create an access rule to allow HTTPS from LOCALHOST to the Exchange server
computer object. Check connectivity again using telnet. When the connection could be made, continue by
importing the required certificates to the ISA firewall.