博客园_BrainPower

Microsoft SharePoint is an amazing tool for collaboration and information sharing. At AIS, we make extensive use of SharePoint portals to serve up a variety of informational goodies.
For those of us using SharePoint, we love the support for sub-domains for each SharePoint Web Application. It is very common to see SharePoint URLs such as
http://hr.mycompany.com
http://development.mycompany.com
http://portal.mycompany.com
Using Host Headers in IIS, implementing SharePoint Web Applications on a single IIS server using a single IP is a trivial mater. So trivial that the SharePoint Application Management wizard sets it all up for you!
Trivial; until you start to see sub-domains such as
http://payroll.mycompany.com
http://secure.mycompany.com
For secure data, such as payroll, most companies will start thinking about SSL to encrypt the data between the server and the browser. And so begins the trouble.
IIS, by default, only supports binding of an SSL certificate to ONE SharePoint web application (or any website on the server). Under default conditions, you must choose between securing the payroll or the secure site using SSL. You cannot bind the SSL certificates to both.
Of course, there are several well documented methods for binding SSL certificate(s) to multiple host headers. The problem is they require using the arcane command line function appcmd. Doable, but not trivial.
Fear not, there is an easier way!
IIS 7 supports what appears to be an undocumented feature for SSL and Host Headers. You simply preface the SSL certificate's friendly name with an asterisk.
Here is how you do it:
Assumptions
- You have a valid SSL certificate already installed on your IIS server
- The SSL certificate matches your sub-domain URL
- You have access to the IIS Manager
- Coffee is brewing, ready to go when you are done
Instructions
- Open Internet Information Services (IIS) Manager
- Edit the Site Bindings for the website you which to assign an SSL certificate to
  (right click, select Edit Bindings
- Select the HTTPS port and select Edit
- Note that the Host Name (Host Header) field is unavailable for editing
- Launch the Microsoft Management Console (MMC)
  - Select Start –> Run
  - Type in "MMC" and hit enter
  - From the console, select File –> Add / Remove Snap-in
  - Select Certificates from the Add / Remove dialog
  - Select Computer Account when prompt for which certificates the snap-in will manager.
  - Select Local Computer when prompted
  - Click OK to add the Snap-in to the MMC
- Locate your SSL certificate
  - For self-signed (SELFSSL), look in Personal
  - For installed / purchased, look in the appropriate folder the certificate was originally installed in
- Right click on the certificate and select properties
- Edit the Friendly Name field so the name starts with an *
- Repeat steps #1 – 3 above
  
  Note that the Host Name (Host Header) field is now available for editing
Happy Bindings!
(Coffee Time)

本文链接

SSL Host Headers in IIS 7

2011-10-23T15:17:00Z

原文地址: http://www.sslshopper.com/article-ssl-host-headers-in-iis-7.html

SSL Host Headers in IIS 7

SSL Host Headers in IIS 7 allow you to use one SSL certificate for multiple IIS websites on the same IP address. Through the IIS Manager interface, IIS only allows you to bind one site on each IP address to port 443 using an SSL certificate. If you try to bind a second site on the IP address to the same certificate, IIS 7 will give you an error when starting the site up stating that there is a port conflict. In order to assign a certificate to be used by multiple IIS sites on the same IP address, you will need to set up SSL Host Headers by following the instructions below.

What Type of SSL Certificate Do You Need?

Because you can only use one certificate, that certificate needs to work with all the hostnames of the websites that you use it with (otherwise you will receive a name mismatch error). For example, if each of your IIS 7 websites uses a subdomain of a single common domain name (like in the example below), you can get a Wildcard Certificate for *.mydomain.com and it will secure site1.mydomain.com, site2.mydomain.com, etc.

If, on the other hand, your IIS 7 sites all use different domain names (mail.mydomain1.com, mail.mydomain2.com, etc.), you will need to get a Unified Communications Certificate (also called a SAN certificate).

Setting up SSL Host Headers on IIS 7

Obtain an SSL certificate and install it into IIS 7. For step-by-step instructions on how to do this, see Installing an SSL Certificate in Windows Server 2008 (IIS 7.0).
Once the certificate is installed into IIS, bind it to the first site on the IP address.
Open the command prompt by clicking the start menu and typing "cmd" and hitting enter.
Navigate to C:\Windows\System32\Inetsrv\ by typing "cd C:\Windows\System32\Inetsrv\" on the command line.
In the Inetsrv folder, run the following command for each of the other websites on the IP address that need to use the certificate (copy both lines):

appcmd set site /site.name:"<IISSiteName>" /+bindings.[protocol='https',bindingInformation='*:443:<hostHeaderValue>']

Replace <IISSiteName> with the name of the IIS site and <hostHeaderValue> with the host header for that site (site1.mydomain.com)
Test each website in a browser. It should bring up the correct page and show the lock icon without any errors. If it brings up the web page of the first IIS site, then SSL Host Headers haven't been set up correctly.
If you need to set up multiple site to use a single SSL certificate on IIS 6 or Apache, see How To Configure SSL Host Headers in IIS 6. For more information about SSL Host Headers in IIS 7 see IIS 7.0: Add a Binding to a Site and SSL certificates on Sites with Host Headers.
for those that have their HostHeader Blocked for writing need to go to:

Launch the Microsoft Management Console (MMC)
Select Start –> Run
Type in "MMC" and hit enter
From the console, select File –> Add / Remove Snap-in
Select Certificates from the Add / Remove dialog
Select Computer Account when prompt for which certificates the snap-in will manager.
Select Local Computer when prompted
Click OK to add the Snap-in to the MMC
Locate your SSL certificate
For self-signed (SELFSSL), look in Personal
For installed / purchased, look in the appropriate folder the certificate was originally installed in
Right click on the certificate and select properties
Edit the Friendly Name field so the name starts with an *

everything else is ok on this tutorial, great job !!

but is important tha the friendly name starts with an * or else you won't me able to write your host header.

本文链接

Understanding Host Headers in IIS

2011-10-23T15:11:00Z

原文地址: http://www.it-notebook.org/iis/article/understanding_host_headers.htm

Introduction

IIS has the ability to host multiple websites on one single server. To do this, a unique combination of the host header name, IP address and port number must exist. This article will explain what a "host header" is, how it works, and explain some common misunderstandings of the host header concept.

The host header is part of the HTTP message

The client and webserver communicates using the HTTP protocol. The data sent between the client and server is called a HTTP message (see RFC 2616, section 4). The HTTP message has a body section and a header section. The body section may contain the HTML code of the webpage returned from the server to the client as an answer to a GET request. The header section contains information such as Content-Length, Referer, Host (and possibly also much more).

How the client communicates with the webserver

To understand where the HTTP message is examined, it is crucial to understand the communication between the client and server. The communication is (typically) introduced by a user typing the domain name and port number into their browser (Internet Explorer). For example, say that the user want to visit www.ilopia.com, in this case the user would type the URL www.ilopia.com into their browser. Internet Explorer will default to the HTTP protocol and the default port (80) for HTTP.

The browser will now need to resolve the domain name the user has typed into their browser because the client must establish a connection to the IP address and port number. The resolution of the domain name into an IP address can be done by utilizing a DNS server or the hosts file.

Once the domain name has been resolved, the client established a connection to the webserver and then sends a request message. This request message contains the host header, and may look like:

GET /index.htm HTTP/1.1
Host: www.ilopia.com

The server receives the HTTP message and examines it. If a host header is found (a HTTP message may not have a host header), IIS will find out if there is any host header name configured in IIS that matches the host header received in the HTTP message. If there is a host header name that matches the host header, index.htm will be served from this website's home folder.

The last step is that IIS will respond to the request.

Name resolution is not part of IIS

As could be seen in the section "How the client communicates with the webserver" above, the HTTP message (and the host header) is not examined until a connection is established between the webserver and client. So when configuring IIS to use host headers, it is necessary to configure name resolution as well. Name resolution is not part of IIS (IIS is a web server, not a name resolution service). Instead a DNS service is necessary, or for a small network the hosts file may be sufficient.

Behind the scenes

Each website set up in IIS "binds" to an IP address, port number and host header name. Each website's configuration is stored in the metabase property ServerBindings, which has the string format IP:Port:Hostname. An example would look like 192.168.0.1:80:www.gafvert.info. The host header name (www.gafvert.info in the example) and IP (192.168.0.1 in the example) can be omitted.

To determine which website should handle a request, IIS checks if there is a website configured to listen on the IP address and port number the request came in on, and which also matches the host header value sent in the HTTP message. If it finds a website with a ServerBindings property that matches this exactly, the request is routed to that website.

If there is no website with an exact match, IIS checks if there is a website configured to listen on all IP addresses (in IIS Manager called "All Unassigned"), the port the request came in on, and with a configured host header name matching what is sent in the HTTP message. If a match is found, IIS routes the request to that website.

The last step is to see if there is any website with a blank host header configured in IIS, which will then handle the request.

本文链接

__VIEWSTATE

2011-09-25T11:47:00Z

The value of this element is a base64-encoded string that acts as a state repository for the page. Any elements on a page whose contents are not implicitly posted back via the standard form POST mechanism have their values saved to and restored from this hidden field. It is also used to propagate supplemental state for controls梖or example, what prior value was stored in a control so that server-side change notifications can be issued. While the technique of propagating state using hidden input fields is common practice in Web applications, ASP.NET takes it a step further and uses it to unify the server-side control model by ensuring that all elements marked with runat=server retain their state across post-backs.

VIEWSTATE就是发送到client端的当前页面的状态, 但貌似只有在代码中赋予的值(方式2)才会在GET请求时被包含在VIEWSTATE中, 而对于页面中直接指定的值(方式1), 在GET请求中不会被包含在VIEWSTATE中.