When working with SharePoint and certificate solutions (SSL, not IPSec) for providing client level pipe security, you may run into some issues that although doesn’t occur with every environment. This particular concern occurs when you have a Dual SAN (Subject Alternative Access) for your SSL certificate because your SharePoint machine host name is different than the Common Name (CN) that is present on the certificate.
For most environments, you will be accessing your site with a different requesting name than the host name, mostly through the use of Host Headers (HH mode):
Example SharePoint Server Host Configuration:
Server (Machine or Host) Name: servername.sharepointsecurity.com
Querying Name (host-header name): sharepoint.sharepointsecurity.com
(The querying name is the name that matches the Common Name (CN) on the server SSL certificate)
The reason that dual SAN attributes become increasingly important in this type of configuration is because SharePoint users will run into a certificate error saying that there is a mismatch that occurs between the website being requested and the common name that is present on the website certificate if there is no Dual SAN attribute to compensate for the differentiation. Although this resulted in a homely grey box when requesting the website in Internet Explorer 6, in Internet Explorer 7 a whole separate page prompt is brought up making the user aware that there is a mismatch. This is pretty bad for usability and overall user experience. General users that aren’t savvy with internet technology will generally choose the giant red symbol rather than the other which tells them that continuing to this website is not recommended, since, hey, everyone goes by Microsoft recommendations.
When implementing the dual SAN in order to bypass this prompt, you will notice that the search results will continually offer a no-item count in the search results, regardless of how the default content access account is structured. Regardless of the privilege of the default content access account, whether you are using a client certificate, this problem will still persist. This is known problem with dual SAN’s within a SharePoint environment in regards to returned search results.
The easiest, quickest solution to the problem is to extend the SSL secured web application into another, unsecure (HTTP) web application that is accessible by the SharePoint gatherer. Extending a new web application essentially places the relevant SharePoint files, associates the application pool, establishes the appropriate references, content mapping, etc. so that the content that is being served through the extended application is essentially the same between the two web applications.
When extending the web application you can either use an IP loopback adapter or IPSec in order to restrict the communication between the gatherer and the site. This would in essence cause the only entity that is able to access the HTTP site to be the SharePoint gatherer maintain security standards.
In order to extend the SSL Web Application to an HTTP accessible site for content gatherering, there are a few steps to follow through WCAM (Web Central Administration). Because you are extending a new web application, it is important to realize that you are going to be making a new IIS site since this essentially translates to a new web application.
- Open SharePoint Central Administration
- Navigate to the Application Management
- Create or Extend Web Application
- Select Extend an Existing Web Application
- Fill in the relevant information in order to extend the secured information to an SSL site.
*note: some images and things might appear funky when you actually request the site. This doesn’t really matter since the only time it will be requestable with an IP loopback adapter or IPSec is when the SharePoint gatherer IP is hitting it.
Once the web application has been extended onto an accessible HTTP site, you can set the content sources for the search to crawl the non-secure site (HTTP) instead of the secure site (HTTPS). To change the content source configuration:
- On the relevant Shared Services Administration page (choose the SSP that search is filed under), in the Search section, click Search settings.
- On the Configure Search Settings page, in the Crawl Settings section, click Content sources and crawl schedules.
- There should be a content source already there that is provisioned by default with SharePoint called “Local Office SharePoint Server sites”.
- When you are in the “Edit Content Source ” screen, in the “Start Addresses” section, place: http://unsecurenewsharepointsite, sps3s://regularoldSSLsite/
- Then set the relevant crawl schedules as your organization deems fit.
After you crawl the content source, you will notice that you are again indexing items, which solves half of the dillema. As well, a majority of the URLS are being re-written in the default Core Search Results WebParts, but not all of them!
In order to rewirte the remaining URL’s, you must adjust the XSL being used by the core search results WebPart. Include the following with the managed property that you are using, in this example I am using the sitename property.
Once you have the re-writing in place, you can use the re-written managed properties for something like getting the site that a particular item is on: