The subject of Web site certificates used by the ISA and TMG firewalls to impersonate the published Web Server came up the other day. The commentator mentioned that there really weren’t any explanations of why or how the ISA or TMG firewall uses these certificates and what’s important to know about Web site certificates.
First, the reason why you install certificates on the ISA Firewall is typically to support secure Web Publishing. When you do this, the external client can connect to the external interface of the ISA Firewall and terminate the SSL connection there. The ISA Firewall is able to do this because it has a certificate installed on it and bound to a Web Listener that allows the ISA Firewall to impersonate the published Web server.
But what do I mean by “impersonating” the published Web server? What exactly is being to make this impersonation work? Many people would think that maybe the ISA firewall is pretending to be an IIS server of some type, and that the browser had some kind of mechanism that allowed it to identify whether or not it was connected to an OWA or other Web site. While this would be a cool feature, that’s not what happens when the ISA firewall impersonates the Web server.
It’s actually very simple. When a external Web browser tries to connect to the secure Web site published by the ISA firewall, the first part of the SSL session setup between the client and server includes the ISA firewall sending the Web site certificate to the client. If the common or subject name on the Web site certificate matches the name included in the client request, then that “proves” to the client that it is connecting to the correct Web server.
That’s all there is to it. If the name in the client request doesn’t match the common or subject name on the Web site certificate returned by the ISA firewall to the client, then the impersonation fails, because the client is expecting that common or subject name to be the same as that included in the request.
However, for the entire process to complete successfully, you need:
- The client request to match the common or subject name on the certificate bound to the Web Listener. For example, if the client requests https://owa.msfirewall.org/owa, then the common/subject name on the certificate must be owa.msfirewall.org
- The client needs the CA certificate of the CA that issued the certificate installed in it’s Trusted Root Certification Authorities certificate store. This is how a machine trusts the Web site certificate; if the CA that issued the certificate is trusted, then the machine also will trust the Web site certificate. The CA certificate needs to be installed on both the client and the server
- If you expect non-managed clients to connect to your published, secure Web site, then you should install a commercial Web site certificate on the ISA firewall. If only managed clients are going to connect to the secure Web site through the ISA firewall, it might be more secure to use a private certificate that you generate on your own certificate server, and use an Enterprise CA internally so that the CA certificate is automatically added to all the domain computers
- Both the Web site certificate and the CA certificate must not be expired. If any of the certificates are expired, they will not longer be valid and will not work.
- In some cases, clients will need to connect to the CRL site that publishes the certificate revocation list. If you have problems with secure Web site publishing, try publishing your CRL. Publishing the CRL can also significantly improve performance in some cases.
That’s all there is to it, at least conceptually. How to make the certificate requests, how to install the Web site and CA certificates, and how to check for validity are part of a longer article. I’ll probably do one soon for either ISAserver.org or Windowsecurity.com in the near future.
Thomas W Shinder, M.D.
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
MVP — Microsoft Firewalls (ISA)