Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 3: Certificate Naming Conventions and DNS Infrastructure Design

Creating Multiple Security Perimeters with a Multihomed ISA Firewall
Part 3: Certificate Naming Conventions and DNS Infrastructure Design
by Thomas W Shinder MD, MVP

In the first part of this series on configuring a multihomed ISA firewall with multiple network security zones, we went over key concepts and design decisions related to intelligent network perimeterization. In the second part of the series, I described the example network used in this article series, the design goals, and the nature of the traffic that needs to move through the ISA firewall to the various network security zones.

In this, part 3 of the series, we will go over the often misunderstood areas of certificate naming conventions and DNS infrastructure required to support the configuration. This is an area of common confusion, so pay very close attention to the concepts discussed in this article. Once you understand the concepts and issues related to a proper certificate naming infrastructure, you’ll never again have to wonder why your secure Web and Server Publishing Rules don’t work correctly.

If you missed the other articles in this series, check them out at:

• Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 1
• Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 2
• Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 4
• Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 5
• Creating Multiple Security Perimeters with a Multihomed ISA Firewall Part 6

Naming Convention for the Web Site Certificates

One subject that’s always good for creating more confusion than it should is the certificate naming conventions used to support SSL connections to and through the ISA firewall. You must decide in advance what common/subject names are going to be on the Web site certificates bound to the following network elements:

• The Web Listener used to publish the OWA site
• The Web Listener used to publish the OMA/ActiveSync/RPC over HTTP site
• The front-end Exchange Server’s Web site
• The back-end Exchange Server’s Web site

Certificate Naming Conventions for the ISA Firewall’s Web Listeners

First a little background. We must create two Web listeners to support OWA publishing using the ISA firewall’s forms-based authentication mechanism. The OWA FBA significantly enhances the level of security the ISA firewall can provide for remote access OWA connections. It also requires that you disable the FBA feature on the front-end Exchange Server.

In addition, you cannot use the same listener for the OWA Web Publishing Rule and the OMA/ActiveSync/RPC-HTTP Web Publishing Rule because the OMA/ActiveSync/RPC-HTTP client software does not know how to deal with the form presented to them and will fail the connection without informing you why it failed.

Now that you know that you must have two Web listeners, you must also be aware that you cannot create two Web listeners using the same socket. A socket is a combination of an IP address, a protocol and a port.

For example, if we create a Web Listener to be used in the OWA Web Publishing Rule that listens on TCP port 443 on IP address 192.168.1.70, we cannot create a second Web listener, used for the OMA/ActiveSync/RPC-HTTP Web Publishing Rules using the same socket, which would be the socket defined on TCP port 443 on IP address 192.168.1.70. This is why we must bind a second IP address to the external interface of the ISA firewall to support the creation of a second Web listener.

Note:
You can get around the need for two IP addresses on the external interface of the ISA firewall to support OWA FBA Web Publishing Rules and OMA/ActiveSync/RPC-HTTP publishing rules by using a very cool tool from Collective Software (www.collective.com) call FlexAuth. FlexAuth will allow you to use a single IP address for all your Exchange Web services publishing. I’ll do a review on FlexAuth in another article on this site.

The last issue we need to deal with regarding the certificates bound to the Web listeners is that you cannot bind the same certificate to multiple listeners. If we create a certificate with the common name owa.msfirewall.org on it and bind it to the first Web Listener (that we’ll use for the OWA FBA Web Publishing Rule), then we can’t use the same certificate for the second Web Listener which will be used for the OMA/ActiveSync/RPC-HTTP Web Publishing Rule. We’ll have to create a second certificate with a different name, such as rpc.msfirewall.org and bind that certificate to the second Web listener.

Certificate Naming Conventions for the Front-end and Back-end Exchange Servers’ Web Sites

However, we’re not yet done with certificate issues. Since the ISA firewall performs SSL to SSL bridging, the first connection from the remote client terminates on the external interface of the ISA firewall. The ISA firewall then decrypts the connection, performs stateful application layer inspection on the contents and then re-encrypts the contents and forwards the information, through a second SSL channel between itself and the front-end Exchange Server. The ISA firewall must be configured to use the name on the Web site certificate bound to the front-end Exchange Server’s Web site in order to establish the second secure SSL link.

While you could bind one of the Web site certificates you bound to the Web Listeners on the ISA firewall to the front-end Exchange Server’s Web site, I prefer to create a third Web site certificate and bind that certificate to the front-end Exchange Server.

For example, you can create a Web site certificate with the common/subject name feexchange.msfirewall.org and bind that certificate to the front-end Exchange Server’s Web site. Then you configure the Web Publishing Rules to forward the connections to feexchange.msfirewall.org and use a HOSTS file entry on the ISA firewall so that the name feexchange.msfirewall.org resolves to the IP address of the front-end Exchange Server.

Note:
The reason why we use a HOSTS file entry is that it’s unlikely that the common/subject name on the certificate will be the same name that the front-end Exchange Server has registered in the Active Directory integrated DNS. An alternative to using a HOSTS file entry is to manually create a Host (A) record in the DNS to support the name on the front-end Exchange Server’s Web site certificate

Finally, you’ll need to consider the name on the certificate bound to the OWA Web site on the back-end Exchange Server. While external users are not affected by the certificate configuration on the back-end Exchange Server, internal users will be. You will need to bind a certificate to the back-end Exchange Server that has the subject/common name that is the same as the name you want the users on the corporate network to use to access the site.

For example, you might want to create a certificate with the common name be.msfirewall.org and bind the certificate to the back-end Exchange Server. Then users who connect to the back-end Exchange Server’s OWA site will use the URI https://be.msfirewall.org/exchange to reach the site. We’ll talk more about DNS infrastructure considerations and how to deal with dysfunctional naming schemes that require different names to be used by internal and external users.

Certificate Naming Conventions used on the SMTP, POP3 and IMAP4 Sites

The certificate naming convention for the SMTP, POP3 and IMAP4 sites is quite a bit simpler than those for the Exchange Web services sites. The reason for this is that we must use Server Publishing Rules to publish these secure sites on the front-end Exchange Server. Server Publishing Rules are essentially reverse NAT rules that expose the connections to the ISA firewall’s stateful application layer inspection filters. The secure connections are not terminated at the ISA firewall, the connection terminus is at the front-end Exchange Server itself.

There are two key requirements regarding the certificates bound to the SMTP, POP3 and IMAP4 sites on the front-end Exchange Server:

• The external user must be able to resolve the name or names used on the certificate or certificates to the IP address used to listen for the connection via the Server Publishing Rule for that protocol. For example, if we use the name smtp.msfirewall.org for the SMTP service on the front-end ISA firewall, then the name smtp.msfirewall.org must resolve to the IP address on the external interface of the ISA firewall used in the Server Publishing Rule publishing the SMTP site (or at least, resolve to the IP address of a device that forwards the connection to the IP address on the external interface of the ISA firewall listening for the incoming SMTP connections via the SMTP Server Publishing Rule
• The client applications must be configured to use the name on the certificate to connect to the secure SMTP site. For example, if you want to use Outlook Express or Outlook 2003 to connect to the secure SMTP server on the front-end Exchange Server then you must configure the client’s SMTP server settings for the secure connection to be smtp.msfirewall.org. If you do not configure the client to use the same name as that on the site’s certificate, then there will be a certificate name mismatch error and the client application will not be able to establish the secure connection to the secure site. The same is true for the POP3S and IMAP4 sites

You could create three certificates with different names and bind them to each of the sites. For example, imap.msifrewall.org, pop.msfirewall.org and smtp.msfirewall.org certificates could be bound to the IMAP4, POP3 and SMTP services, respectively. However, I usually find it easier to use the same certificate for all the sites. However, keep in mind that if you use the same certificate for all the sites, and for some reason you need to revoke that certificate, then the certificate used on all three sites is revoked. In contrast, if you had created a separate certificate for each site, then you could revoke one certificate without affecting any of the other site certificates.

Certificate Naming Conventions used on the Example Network

On the example network we will use the following naming conventions for the Web site certificates:

• The Web site certificate bound to the first Web Listener, which will be used in the OWA Web Publishing Rule, will have the common/subject name owa.msfirewall.org and external users will access the site using the URI https://owa.msfirewall.org/exchange.
• The Web site certificate bound to the second Web Listener, which will be used in the OMA/ActiveSync/RPC-HTTP Web Publishing Rule, will have the common/subject name rpc.msfirewall.org. While this name might seem unintuitive to users, the fact is that they will not need to remember this name, since the client applications must be “hard-coded” to use this name, with the exception of the OMA Web client. Of course, you can use any host name you like in the common name, just as long as its not the same as the common/subject name used on the OWA Web site certificate
• The Web site certificate bound to the Exchange Server Web site on the front-end Exchange Server will use the common name feexchange.msfirewall.org. When we create the Web Publishing Rules for the Exchange Server Web services, we will use this name for the redirect. We will also configure a HOSTS file entry that resolves this name to the IP address of the front-end Exchange Server. This obviates the need to create a DNS entry to support the name on the certificate, which is likely not actual host name of the front-end Exchange Server machine itself
• The SMTP, POP3S and IMAP4S sites also need Web site certificates bound to them. The common/subject name on the Web site certificate bound to these sites will be mail.msfirewall.org. Note that you do not use the Internet Information Services console to bind Web site certificates to these services. Instead, you use the Exchange Server System Manager.
• The back-end Exchange Server will not have a Web site certificate bound to it on our example network. The reason for this is that we’re not testing Direct Access to the back-end Exchange Server from corporate network clients. If you plan to enable SSL access to the back-end Exchange Server, then you’ll need to bind a Web site certificate to the site, and make sure that the common/subject name on the certificate resolves to the actual IP address of the back-end Exchange Server (or at least to a device that forwards connections to the back-end Exchange Server). Also, if you are using the Web proxy client configuration for hosts on the corporate network, then make sure you configure your internal domains and IP addresses for Direct Access (which you should do anyway as part of ISA firewall best practices).

The figure below shows the servers participating in these connections and the common/subject names on the certificates bound to their respective Web Listeners/Web sites.

Figure 1

Note on Certificate Deployment

I thought about going through the details of certificate deployment and how to request and install the certificates on the ISA firewall, the front-end Exchange Server and the back-end Exchange Server. The problem with covering the details of the certificate deployment is that the methods used to deploy the certificates differ based on the PKI infrastructure you’ve deployed.

If you choose to use Microsoft Certificate Services, then you have the choice of deploying either an enterprise CA or a standalone CA. In almost all circumstances where the ISA firewall is deployed, the enterprise CA is the better option. I have deployed an enterprise CA on the domain controller on the corporate network in the example network used in this article series.

The ISA firewall, the back-end Exchange Server and the front-end Exchange Server are members of the same domain that hosts the enterprise CA. This allows the enterprise CA’s CA certificate to be automatically deployed to all domain members. The implication of this is that all domain members will trust certificates issued by this enterprise CA. The only drawback in this scenario is that the front-end Exchange Server will not automatically receive the CA certificate, in spite of being a domain member. The reason for this is that there is a bug in the RPC filter (or maybe it is a feature?) that prevents autoenrollment when strict RPC compliance is enabled.

This isn’t a major problem, because you can include the CA certificate in the certificate file that also contains the Web site certificate. You can then move the CA certificate to the Trusted Root Certification Authorities machine certificate store on the front-end Exchange Server after important the certificates from the export file.

Note that there are many ways you can approach certificate deployment for both enterprise and standalone CA deployments. For details on certificate deployment, you can check out the Exchange Server deployment kit (http://www.isaserver.org/img/upl/exchangekit/) or the VPN Deployment kit (http://www.isaserver.org/articles/isa2000vpndeploymentkit.html).

For this article, I deployed the certificates using the IIS Certificate Request Wizard on the back-end Exchange Server using the following procedures:

1. Make a request to an online CA (the enterprise CA) for a certificate named owa.msfirewall.org.
2. After receiving the certificate, I exported the certificate (with its private key) and the CA certificate to a file.
3. I then ran the IIS Certificate Request Wizard again to remove the certificate from the Web site.
4. Run the IIS Certificate Request Wizard again and request a certificate with the common name rpc.msfirewall.org.
5. After receiving the certificate, export the certificate with its private key to a file.
6. Run the IIS Certificate Request Wizard again and remove the rpc.msfirewall.org certificate from the Web site.
7. Run the IIS Certificate again and request a certificate with the common name feexchange.msfirewall.org
8. After receiving the certificate, export the certificate with its private key to a file.
9. Run the IIS Certificate Request Wizard again and remove the feexchange.msfirewall.org certificate from the Web site.
10. Run the IIS Certificate Request Wizard and request a certificate with the common name mail.msfirewall.org.
11. Export the mail.msfirewall.org certificate, along with its private key, to a file.
12. Copy the feexchange.msfirewall.org and mail.msfirewall.org certificate files to the front-end Exchange Server.
13. Import the feexchange.msfirewall.org Web site certificate into the front-end Exchange Server’s machine certificate store. Copy the CA certificate that was included in the import to the Trusted Root Certification Authorities store in the machine’s machine certificate store.
14. Import the mail.msfirewall.org Web site certificate into the front-end Exchange Server’s machine certificate store. We do not need to copy the CA certificate into the Trusted Root Certification Authorities store because we already did that.
15. Bind the feexchange.msfirewall.org to the front-end Exchange Server’s Web site.
16. Bind the mail.msfirewall.org to the SMTP, POP3 and IMAP4 services on the front-end Exchange Server.
17. Copy the owa.msfirewall.org and rpc.msfirewall.org certificate files to the ISA firewall (we need to do this because autoenrollment will fail on the ISA firewall as well, since the RPC filter also protects the ISA firewall itself).
18. Import the owa.msfirewall.org Web site certificate into the ISA firewall’s machine certificate store. Copy the CA certificate included in the import to the ISA firewall’s Trusted Root Certification Authorities store.
19. Import the rpc.msfirewall.org Web site certificate into the ISA firewall’s machine certificate store. We don’t need to copy the CA certificate to the Trusted Root Certification Authorities store because we already did that on this machine.
20. Later we will bind the Web site certificates in the ISA firewall’s machine certificate store to the appropriate Web Listeners.

It might seem like a long drawn out process, but you can complete the procedures in less than 10 minutes. Of course, there are other ways to obtain machine certificates, such as using the Web enrollment site on the CA. However, the Web enrollment sites are used differently depending on whether you have deployed a standalone CA or an enterprise CA. You’ll see the details in either the VPN Deployment Kit or Exchange Deployment kit. Check out the tables of content for these kits to see the CA scenario that fits most closely to your organization’s PKI deployment.

DNS Infrastructure

The well designed DNS infrastructure is critically important whenever remote access connections are paired with PKI. The reason for this might be obvious by now: the common/subject names on the certificate must match the names included in the requests made by the clients. In addition, the names used by internal corporate clients when connecting to SSL/TLS resources must also match the names on the Web site certificates bound to the network services to which these clients connect.

The Miracle of the Split DNS Infrastructure

The key to success is a split DNS infrastructure. Now, before you run away in horror, there is a fact that I need to make clear:

A Split DNS Infrastructure has nothing to do with using the same name for internal and external network domains. You should never have to change the name of your Active Directory domain or any other internal DNS domain, to support a split DNS infrastructure.

A split DNS infrastructure is nothing more than two DNS zone databases serving the same domain names, one for corporate network users and the other for users located off the corporate network, such as remote access users located on the Internet.

For example, suppose your internal network Active Directory domain name is isafirewall.local. You know that you can’t use the .local top level domain name on the Internet, so you register the domain name isafirewall.org to enable remote access to your Exchange Server Web and non-Web services.

You configure your external DNS server that is authoritative for the isafirewall.org domain so that owa.isafirewall.org resolves to the ISA address on the external interface of the ISA firewall that’s being used by the Web Listener on the OWA Web Publishing Rule to accept incoming Web requests. The certificate bound to the Web listener has the common/subject name owa.isafirewall.org. The external users are able to successfully establish a connection to the OWA site because their client systems are located on at remote sites on the Internet and use Internet based DNS servers that resolve the sites in the isafirewall.org domain name to the IP addresses bound to the external interface of the ISA firewall (or at least to a public address of a device that routes the incoming connections to the ISA firewall’s external interface.)

But what happens when those same users come back to the corporate network after their travels are complete? The users will try to access the OWA server using the same name http://owa.isafirewall.org and it doesn’t work. Why? Because the name owa.isafirewall.org resolves to an external IP address and not the actual IP address of the Exchange Server on the corporate network. At no time should users loop back through the ISA firewall, or any other firewall, to reach resources on the same Network on which the clients are located.

How do you solve this problem? By using a Split DNS infrastructure. You do not need to change the name of your internal DNS Active Directory domain. All you need to do is configure a DNS zone on your internal network DNS servers for the same domain name, isafirewall.org. The only difference between the external and internal zones is that the external DNS zone resolves names to externally accessible addresses, and the internal zone resolve names to internally accessible addresses, such as the actual IP address of the servers, or of a network device such as a perimeter ISA firewall that provides access to the Network services via perimeter firewall networking.

DNS Infrastructure used on the Example Network

The DNS infrastructure on the example network employs what I consider to be the absolute best practice for DNS infrastructures supporting remote access scenarios. This DNS infrastructure employs the same domain name for the internal network resources and the external network resources. There is a strange and unexplainable misconception that using the same domain name for internal and external resources is somehow unsecure, but this is a falsity of the highest order and you should ignore those who mindlessly claim that it is true.

Our example network used in this article series uses the same domain name msfirewall.org for both internal and external resources. The advantage of this approach is that users never need to be aware of their location to connect to resources that are available from both internal and external locations. Users never need to reconfigure client applications to support moving between the corporate network and external locations.

The example network has an external zone and an internal zone authoritative for the msfirewall.org domain. The external zone is hosted by a DNS server located somewhere external to the corporate network, and the internal zone is hosted in a Active Directory integrated DNS server on the corporate network.

The figure below shows an example of what happens when a user someone on an external network tries to connect to the OWA site through the multihomed, multi-perimeter ISA firewall.

1. First, the client application triggers the operating system to issue a query to a public DNS server for owa.msfirewall.org. The DNS server returns to the client software the IP address for owa.msfirewall.org.
2. The client application then makes a connection request to the IP address returned by the DNS server for owa.msfirewall.org. Included in the request is the Host Header, which the ISA firewall’s Web Publishing Rule uses to match the entry on the Public Name tab of the Web Publishing Rule
3. If the connection request matches the parameters included in the Web Publishing Rule, then it is forwarded to the server name included on the To tab of the Web Publishing Rule. On our example network the Web Publishing Rule will have the name feexchange.msfirewall.org on the To tab. The ISA firewall can use a HOSTS file entry, or a DNS entry. If you use a DNS entry, then you’ll need to manually create the Host (A) record mapping the common/subject name on the Web site certificate to the actual IP address of the front-end Exchange Server on the authenticated access DMZ.

Figure 2

The figure below breaks out the process mentioned in step 3. After the ISA firewall confirms that the request made by the external client matches the parameters in the Web Publishing Rule, it then resolves the name on the To tab of the Web Publishing Rule. The HOSTS file on the ISA firewall contains an entry that maps the name on the front-end Exchange Server’s Web site certificate to the actual IP address of the front-end Exchange Server on the authenticated access DMZ segment. The request is then forwarded to that IP address by the ISA firewall.

Figure 3

The figure below shows the name resolution sequence for an external client connecting to a site published using a Server Publishing Rule instead of a Web Publishing Rule. The external client makes a query to a public DNS server for mail.msfirewall.org and then connects to the IP address returned by the DNS server, which is the IP address on the external interface of the ISA firewall used by the Server Publishing Rules listener.

The difference here is that the connection isn’t bridged by the ISA firewall, the ISA firewall perform a reverse NAT and forwards the connection to the front-end Exchange Server. Only after the connection reaches the front-end Exchange Server are the contents decrypted. In this case, you don’t need to worry about binding certificates to listeners on the ISA firewall.

Figure 4

Have Questions about the article?  Ask at: http://tinyurl.com/dfrxm

Summary

In this article we discussed vital issues in certificate naming infrastructure required to support a secure remote access solution using the ISA firewall. We drilled down on the common/subject names on the certificates bound to the ISA firewall’s Web Listeners, the front-end Exchange Server and the back-end Exchange Server. We then finished up with a discussion of the DNS infrastructure issues involved with a secure publishing solution. In the next article in this series, we’ll get down to the details of configuring the ISA firewall with the Web Publishing Rules, Server Publishing Rules and Access Rules required to support front-end Exchange Server communications.