In this post, I’ll be talking about a web publishing problem and how I dealt with it. The problem was that external clients were failing to access an internal Web server published on ISA 2004 server with HTTP 500 internal error.
As usual, I asked the following logs from our customer when reproducing the problem:
– Collecting an ISA data packager while reproducing the problem (as part of ISA Best practices Analyzer log). The tool could be downloaded from the below link:
– Collecting a network trace from the internal web server
– Collecting a network trace and Fiddler trace from an external test client. It could be downloaded at the following link:
Note: Fiddler or similar tools (like HTTPWatch – we also use it) provide useful information even if the connection is clear text HTTP. For HTTPS connections it’s nearly a requirement to collect it to see what’s going on from client’s perspective. Another possibility is collecting WinInet/WinHTTP ETL traces which I plan to discuss in another post.
After collecting the logs, I started troubleshooting the problem
a) I first checked the Web proxy logs (collected as part of Data packager logs) and saw the same problem there: (I included only a part of the log and also changed the names deliberately)
Result code is -2146893022 which is FFFFFFFF80090322 which is SEC_E_WRONG_PRINCIPAL
Actually the web listener used by the given web publishing rule doesn’t have authentication configured. But that error might also be seen when certificate related issues are seen.
b) Then I decided to check the ETL trace that was also collected as part of ISA data packager. Please note that the ETL trace collected as part of data packager could only be converted to human readable format by Microsoft support but we also provide a lightweight version of the same facility as part of the product. You can do that as follows:
(Before reproducing the problem you have to enable logging from “Enable Diagnostic Logging” and once the problem is reproduced you have to disable logging by selecting “Disable Diagnostic Logging”)
When checking ETL traces, one of the key parameters is the filter info which is also a part of Web proxy log. Example:
So I focused on the relevant filter info and have seen the following problem there: (please note that the ETL output is much more detailed than shown below)
… Failed – server name doesn’t match. local name : web.contoso.com, cert name: *.contoso.com
After seeing the error above, I realized that we were hitting the known limitation with ISA 2004 and wildcard certificates used on published servers:
http://technet.microsoft.com/en-us/library/cc302619.aspx Troubleshooting SSL Certificates in ISA Server 2004 Publishing
I am using wildcard certificates and getting the error: 500 Internet Server Error – The target principal name is incorrect.
ISA Server 2004 only supports wildcard certificates on the ISA Server computer. ISA Server 2006 also supports use of wildcard certificates on the published Web server. When using HTTPS to HTTPS bridging, you cannot use wildcard certificates to authenticate the back-end Web server. Instead, on the internal Web server, create a new certificate that matches the name of the internal Web server, as specified on the To tab in the Web publishing rule. For more information about configuring this scenario, see Publishing Multiple Web Sites using a Wildcard Certificate in ISA Server 2004 (www.microsoft.com).
For confirmation purposes, I also checked the network trace collected from the internal Web server and saw that the web server was really sending a wildcard certificate to ISA 2004 server:
=> The relevant frame:
Frame: Number = 8649, Captured Frame Length = 2974, MediaType = ETHERNET
– TLS: TLS Rec Layer-1 HandShake: Server Hello. Certificate.
– TlsRecordLayer: TLS Rec Layer-1 HandShake:
+ Version: TLS 1.0
Length: 4786 (0x12B2)
– SSLHandshake: SSL HandShake Certificate(0x0B)
Length: 77 (0x4D)
+ ServerHello: 0x1
Length: 4697 (0x1259)
– Cert: 0x1
CertLength: 4694 (0x1256)
CertificateLength: 1457 (0x5B1)
+ X509Cert: Issuer: ContosoSubCA,contoso,com, Subject: *.contoso.com
– The web server has a wildcard certificate assigned (*.contoso.com)
The resolution to this problem is to assign a new certificate to the internal Web server which is not a wildcard certificate. You can find more information below:
http://technet.microsoft.com/library/cc302625.aspx Publishing Multiple Web Sites Using a Wildcard Certificate in ISA Server 2004)
Hope this helps