Quantcast
Channel: Second Life of a Hungarian SharePoint Geek
Viewing all articles
Browse latest Browse all 206

debugging issues and SSL Failure caused by a DNS-Configuration Mistake

$
0
0

Recently we had two issues in one of our development environments, that were rather weird at first sight.

In the farm there are three web applications (AppA, AppB and AppC), all of them accessible only via HTTPS. AppA and AppB share the same (non-wildcard) SSL certificate, AppC has its own one. All of the applications has its own IP address (IP_A, IP_B, IP_C) as we cannot use host headers with HTTPS in this case, and its own application pool (AppPoolA, AppPoolB and AppPoolC) assigned in IIS.

Symptoms:

1. We want to debug our custom application pages used in AppA. After an IISRESET we open the page using the URL of AppA in the browser, however, instead of the process of AppPoolA, the process of AppPoolB is started (we can see it in Task Manager), although the content of the pages was rendered in the browser using the context of AppA. If we try to deploy the solution from Visual Studio, and would like to automatically attach the debugger to the corresponding web application (AppA), for example using CKSDev, the breakpoints remain inactive. If we attach the debugger manually to the process of AppPoolB, we can debug the pages, and SPContext.Current reflects the correct values in context of AppA. This behavior is not always reproducible, about in 10-20% of the cases we can debug the pages “normally”, via the process of AppPoolA.

2. When accessing AppA in the browser, about in 60-70% of the cases we receive a security warning, that the certificate was issued to an other URL. When checking the certificate, we see, that the server tries to build up the HTTPS connection using the certificate assigned to AppC. If we ignored the warning, content of AppA was displayed.

Reason:

Analyzing the IIS and SharePoint Server settings and SSL certificate / IP bindings I found no errors. However, when PINGing the Fully Qualified Domain Name (FQDN) of AppA, I saw, that the host name of the front end server is displayed, and not always the IP address of AppA (IP_A) are resolved, but quite frequently the IP of AppB and AppC (IP_B, IP_C) as well. Using NSLOOKUP I realized that all of these IPs are assigned to the FQDN of AppA. The host name was resolved to IP addresses randomly in a round-robin fashion by DNS. The AppB FQDN -  IP_B, AppC FQDN – IP_C assignments were correctly configured.

Since the request was sent to the incorrect IP address, it was routed to an other virtual server at the IIS level, this is why the other application pool was started and the other SSL certificate was returned. However, as all of the sites were bound to SharePoint web applications, at the SharePoint level the correct target web application was recognized based on the URL of the request, so the content was rendered as expected, and not based on the content / in the context of the other web applications.

You should be able to reproduce this behavior if you have more SharePoint web applications bound to the same port number but different IPs without host headers, if you set the incorrect IP address in the hosts file locally, and do not let the browser to use a proxy server for accessing the sites.

Solution:

Discussing the issue with the network group it turned out, that FQDNs of the web applications were configured as CNAME records in DNS, referring to the host name of the front end server. Deleting the faulty CNAME assignments in DNS has solved both of the above described symptoms.



Viewing all articles
Browse latest Browse all 206

Trending Articles