As we close out the year 2003, I want to take this opportunity to thank everyone for the very kind words you’ve had for the ISA Server and Beyond book. While we wanted to make the book a valuable reference on the finer points of ISA Server, I never expected so many people would write in about how much they liked it. While I’m not convinced we deserve it, I do want to let you all know that Debi, Martin and I all appreciate it.
One of the subjects I spent a lot of time on in the ISA Server and Beyond book was using SSL with Server Publishing Rules and Web Publishing Rules. This was a topic that we only briefly covered in the Configuring ISA Server book. While the coverage of SSL related topics such as secure OWA publishing and SSL bridging is very complete, but there was one thing I left out: the dreaded 500 Internal Server Error – The target principal name is incorrect” error.
You actually encountered this error in our first ISA Server book, but because of time and space considerations for that book, we didn’t have the chance to expand on what the specific problem was that created this condition. That’s was unfortunate because a lot of you have encountered this condition, and a lot more of you will encounter it after you start implementing the cool SSL scenarios you read about in ISA Server and Beyond.
Take a look at the figure 1 to refresh your memory on this error. You’ll see this when you implement SSL bridging using Web Publishing Rules. But what type of SSL connections and Web Publishing Rules lead to this problem? That’s what I’ll cover in the rest of this article.
Figure 1
First, let’s take a look at the scenario and then we’ll analyze the results as we test variations on the SSL publishing theme.
The Basic Setup
Figure 2 below shows the basic setup:
Figure 2
All computers are running Windows 2000 Advanced Server SP2 and the ISA Server is updated to SP1. An Enterprise Root Certificate Server was installed on the internal network domain controller. The Web site on the domain controller/certificate server machine obtained a Web site certificate from the domain controller using the Web site Certificate Wizard found in the Internet Information Services console. The Web sites’s name (the common name [CN] on the certificate) is www.internal.net. The certificate was exported along with its private key and copied to the ISA Server. The certificate was then imported into the ISA Server machine’s Personal Certificate store and then bound to the Incoming Web Requests listener. All of these procedures are explained in exquisite detail in the ISA Server and Beyond book.
In order to allow the external network client to establish an SSL connection to the Incoming Web Requests listener, the external client was connected to the internal network and requested a user certificate via the Web based certificate enrollment site. The request included instructions to save the information in the machine’s certificate store. Again, the details of this procedure, and alternatives to the Web based enrollment site, are discussed in the ISA Server and Beyond book.
A Destination Set that included an entry for www.internal.net and Web Publishing Rules using this Destination Set were created after the certificate was bound to the Incoming Web Requests listener. Each of the Web Publishing rules required an SSL connection to the Incoming Web Requests listener. The differences in these rules focused on how the request was bridged and whether or not the original host headers were retained.
Test #1 – SSL to HTTP Bridging Sending Original Host Header
In the first test we’ll look at how SSL to HTTP bridging works and also what happens when you allow the original host header to be passed to the internal Web server. The external network clients sends a request to https://www.internal.net and establishes an SSL link with the Incoming Web Requests listener. The Web Publishing Rule is configured to forward SSL requests as HTTP requests (SSL to HTTP bridging) and its configured to forward the original Host Header.
Figure 3 shows what’s happening in this scenario:
Figure 3
The Action page of the Web Publishing Rule looks like this:
Figure 4
Good news! The request is successful and we see what appears below:
Figure 5
In this test, the connection between the external network client and the external interface of the ISA Server is secured by SSL. The ISA Server decrypts the SSL packets and then forwards them to the internal network Web server in the clear via HTTP. You can see a capture taken from the internal interface of the ISA Server while this transaction took place. Note the Host: entry in the ASCII decode. In spite of the fact that we configured the Web Publishing Rule to forward the request to 10.0.0.2, the Host: entry says www.internal.net. The reason for this is that we selected the Send the original host header to the publishing server instead of the actual one (specified above) option.
You can see the Web Proxy service log entries for this transaction right above the Network Monitor trace in figure 6. Note that while the original host header was sent to the internal network Web server, the GET request is denoted as http://10.0.0.2 in the Web Proxy service log entry. Keep this in mind when troubleshooting Web Publishing problems. The Host Header received by the internal Web server may not be what you see in the URL contained in the Web Proxy service log entries.
Figure 6
Test #2 – SSL to HTTP Bridging Sending Without Sending the Original Host Header
Let’s repeat what we did in Test #1, except this time we’ll remove the checkmark from the Send the original host header to the publishing server instead of the actual one (specified above). The scenario is depicted in the figure 7:
Figure 7
The request is successful just like the last one. The packet trace and the Web Proxy log entries appear in the figure below. Note that in this case the Host: entry says 10.0.0.2. This indicates that the header in the original request (which contained www.internal.net) was replaced by the Web Proxy service with 10.0.0.2 when it forwarded it to the internal Web server. However, note that the Web Proxy service log entries for this request look the same as those you saw when the original Host Header was retained. Be careful when looking at those Web Proxy service logs during Web Publishing Rule troubleshooting!
Figure 8
Test #3 – SSL to SSL Bridging Sending With and Without Sending the Original Host Header
Now let’s change the type of bridging performed by the Web Publishing Rule. In this test the external client establishes an SSL link with the Incoming Web Requests listener on the external interface of the ISA Server. The ISA Server will decrypt the SSL packets and then re-encrypt them as it creates a second SSL link between the internal interface of the ISA Server to the internal network Web site. The internal network Web site uses the same certificate as that used by the external interface of the ISA Server. The Bridging tab of the Web Publishing Rule looks like figure 9:
Figure 9
This configures the Web Publishing Rule to perform SSL to SSL bridging. Whenever ISA Server performs SSL to SSL bridging, it terminates the first SSL connection on the Incoming Web Requests listener and then creates a second SSL connection with the internal server. This provides end to end security from the Web client to the destination sever on the internal network. This type of end to end security is very important from a legal, ethical and moral standpoint because when the external host creates an SSL connection, they are not aware that the ISA Server is impersonating the destination Web server. The Web clients (and their users) expect the connection to be secure from client to server. The only way you can guarantee the level of security the Web client expects is via SSL to SSL bridging. The figure 10 shows the setup for Test #3. Notice that our Test #3 actually includes two tests: one with the original host header sent to the internal Web server and another one without the original host header.
Figure 10
Just as a reminder, the Action tab of the Web Publishing Rule looks like what you see in figure 11 (the only difference between the two tests was the setting on the Send the original host header to the publishing server instead of the actual one (specified above):
Figure 11
You can see the packet trace and the Web Proxy log entry taken on the internal interface in the figure below. Note that the ACSII decode is just garbage, which I assume is due to the packets being encrypted before being intercepted by Network Monitor on the internal interface. You can see that the destination port number is the Web sites SSL port 443. These results were the same for both tests. Unfortunately, we can’t see if the original host header was sent to the Web server or not, because the header is encrypted in the SSL datastream. The same garbage appeared when I performed the packet trace on the Web server’s interface.
Figure 12
So what was the result? I got the dreaded 500 Internal Server Error – The target principal name is incorrect error that you saw in the very first figure in this article. What did we get the error and how do we fix it?
The Problem and the Solution
The target principle error is do to a mismatch between the name in the request made by the Web client and the common name (CN) on the Web site certificate. For example, if we went to the ISA Server and opened the browser and typed in the URL https://10.0.0.2, you’ll see what appears in the figure below. Notice that while the ISA Server trusts the certificate authority that granted the certificate to the Web site and that the date on the certificate is valid, the name on the certificate doesn’t match the name you included in your request.
Figure 13
Click on the View Certificate button in the Security Alert dialog box and you’ll see what appears in the figure below. Note that we’re in the Details tab and that the Subject field has been selected. You can see in the lower pane the entry CN = www.internal.net. You see the Security Alert dialog box because the request you sent to the Web server doesn’t match this CN field in the certificate.
Figure 14
You have the choice as to whether or not you want to connect to the site when you access the Web site directly form the browser on the ISA Server. You don’t have this option when you configure the Web Publishing Rule to bridge SSL as SSL. When you bridge SSL as SSL, the Web Proxy service becomes the client to the internal network Web server. Now you can see the problem. The Web proxy service becomes aware of the host header mismatch but it doesn’t have a mechanism to inform the external network Web client of the problem, so it returns to the clients a somewhat cryptic error indicating a “target principle name” was incorrect. It would have been more helpful to return an error like “Subject name is incorrect” or “Common Name is incorrect”, but we should be used to that sort of thing by now.
The solution is to prevent the host header mismatch, and the way you prevent the mismatch is to configure the Web Publishing Rule to use the FQDN listed in the Web server certificate’s Common Name entry. You saw in the figure above that the CN for the Web site is www.internal.net, therefore you need to configure the Web Publishing Rule to redirect to www.internal.net instead of the IP address of the site (10.0.0.2). This change is seen in figure 15.
Figure 15
However, in order to make this work, you have to make sure that the ISA Server is able to resolve the FQDN in the redirect to the IP address of the Web server on the internal network. That means you need to either implement a split DNS or use a HOSTS file on the ISA Server. If you do not use a split DNS or a HOSTS file to resolve the name correctly, the ISA Server will forward the request to the public IP address that resolves to the FQDN contained in the redirect. In this example, you do not want the www.internal.net request to be forwarded back to the Incoming Web Requests listener! You want the request forwarded to the internal network Web server.
For more information on how to create a split DNS, check out my article on this subject over at http://www.isaserver.org/tutorials/You_Need_to_Create_a_Split_DNS.html The details of split DNS and HOSTS file settings are covered in the ISA Server and Beyond book.
Summary
In this article we went over several scenarios demonstrating how ISA Server bridges SSL requests. The ISA Server can bridge SSL connections using either HTTP or SSL. If you bridge SSL as SSL, you may end up with a “target principle name” error because of a name mismatch between the FQDN in the request and CN on the Web site certificate. The solution to this problem is to configure the Web Publishing Rule to use the FQDN of the internal Web site and then configure a split DNS or a HOSTS file so that the ISA Server resolves that name to the internal IP address of the Web server and not the public address of the server.
I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=001409 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom
