How do I... Request and install SSL certificates in IIS 7.0?

<img src="" align="right" border="0" height="85" hspace="5" vspace="5" width="110" />SSL (<a href=";s=0&amp;o=1" target="_blank">Secure Sockets Layer</a>) certificates are perhaps the most common way to protect information being transmitted between a visitor Web browser and your Web site. SSL provides encryption services to information flowing between systems and can protect Web traffic, e-mail, instant messages and a host of other kinds of data transmittals. Scott Lowe shows you how to obtain and install a third-party SSL certificate into Microsoft Internet Information Server 7.0 (<a href=";s=0&amp;o=1&amp;q=iis+7.0" target="_blank">IIS 7</a>) running on Windows Server 2008.

SSL (Secure Sockets Layer) certificates are perhaps the most common way to protect information being transmitted between a visitor Web browser and your Web site. SSL provides encryption services to information flowing between systems and can protect Web traffic, e-mail, instant messages and a host of other kinds of data transmittals.

I'm not going to go into great detail about the inner workings of SSL except to say that it is a critical infrastructure component for any organization that has a desire to protect customer or other confidential information. SSL is widely used by banks, e-commerce companies, and other Web entities that require transmission of sensitive information, such as passwords, social security numbers, etc.

I will show you how to obtain and install a third-party SSL certificate into Microsoft Internet Information Server 7.0 (IIS 7) running on Windows Server 2008. I am running the RC0 version of Windows Server 2008.

This blog post is also available as a TechRepublic gallery and TechRepublic download.

In the most simplistic view, there are four kinds of certificates to which you will be exposed during your SSL installation:

  1. Self-signed SSL certificates: These are certificates that you generate and use to encrypt information passing between a client and your server. These certificates are good insofar as they do allow you to encrypt data, but since they are created on-site, the certificates have not been verified by a third party entity, meaning that the site can't necessarily be trusted.
  2. Third-party SSL certificate: A third-party SSL certificate provides the same encryption capabilities as a self-signed certificate. However, since the certificate is issued by a third party, it is considered a more trusted type of certificate, especially when the certificate chain extends to a trusted root certificate.
  3. Intermediate certificate: Not all SSL certificate vendors are created equal. In order to be fully trusted, any certificate you obtain needs to eventually link to a root certificate that is trusted by your Web browser. However, not all vendors' SSL certificates are natively trusted by root certificates. As such, with these vendors, you need to complete the SSL trust chain by (in addition to installing your SSL certificate) installing an intermediate certificate between a root certificate and your new SSL certificate. If you skip this step, users will continue to get certificate errors until this trust chain is established. The use of an intermediate SSL certificate requires a bit of additional network communication at the initial establishment of an SSL-secure session but beyond that, there is no performance penalty.
  4. Trusted root certificate (or Trusted root certification authorities): A root certificate is the Grand PooBah of the certificate world. In order to complete the trust chain, your individual certificate must, in some way, link to a root certificate.

A third-party SSL certificate is generally considered more trusted than a self-signed certificate since the certificate information is verified by a third party and the certificate ultimately maps to what is called a trusted root certificate.

Note: I am assuming that you will be installing a brand new certificate that you do not yet own and not importing some kind of existing certificate. Further, I assume that you do not have a complex public key infrastructure in-house and that you need to get your certificate from a third party. Finally, I'm making the assumption that you have already installed IIS 7 on your Windows Server 2008 system.

Step 1: Prepare a Certificate Signing Request (CSR)

Regardless of the SSL vendor you use, you first step in the process is to create a Certificate Signing Request (CSR) that will be sent to the SSL vendor of your choice. The CSR is a Base-64 encoded PKCS#10 message (this basically means it's a bunch of gobbledygook that is unreadable by humans) that contains all of the information necessary to identify the person or company applying for the certificate. The request also includes the applicant's public key. This key is the public portion of a combined public key/private key structure that, together, is able to effectively and securely encrypt information.

  • Choose Start | Administrative Tools | Internet Information Services (IIS) Manager
  • In the IIS Manager, choose your server name
  • In the Features pane (the middle pane), double-click the Server Certificates option (Figure A) located under the Security heading.

Figure A

Open the properties page for the site you want to protect
  • You will notice two default certificates already installed on this server. To begin the process of requesting a new certificate, from the Actions pane, choose the Create Certificate Request option as shown below in Figure B.

Figure B

Click the Server Certificate button to begin the process
  • The first screen of the wizard asks for details regarding the new site. The common name should match the fully-qualified domain name for the site. Otherwise, provide information about your site, making sure to spell out the name of your state. (Figure C)

Figure C

Provide information about your site
  • Click Next to continue.
  • The next screen of the wizard asks you to choose cryptography options. The default, Microsoft RSA SChannel Cryptography Provider is fine. A key length of 1,024 bits is the default option and is fine as well. (Figure D)

Figure D

Choose a cryptography provider and key length
  • Click Next to continue.
  • Finally, provide a filename to which to save the certificate request. You will need the contents of this file in the next step, so make sure you know where to find it. (Figure E)

Figure E

Save the CSR

Here's some of the CSR mumbo jumbo associate with this certificate request:








Step 2: Request a certificate from a certificate vendor

Now, with your CSR in hand, visit the Web site of your favorite SSL certificate provider and buy your new certificate. During the registration process, you need to provide the certificate company with information validating you or your company's identity. Some consider this part a hassle, but it really is a vital part of the overall SSL chain. After all, you don't want just anyone receiving a certificate that uses your company name!

The certificate request process varies by certificate company, so I can't really provide the exact steps for the certificate request. What I can tell you is that, at some point, you'll need to open up the text file that contains the certificate request in order to copy and paste the encrypted certificate request in the appropriate field on the order form.

Once you complete the vendor's certificate request (Figure F) form and provide them with payment, you'll need to wait for the SSL certificate to be delivered to you via e-mail.

Figure F

Provide the necessary information for the SSL certificate vendor

Step 3: Save the provided certificate somewhere accessible

What you get back from a certificate vendor depends on the vendor you choose. In the case of the company that I used to get my certificate, they sent back a zip file with three certificates. One of the certificates is named ssltest_westminster-mo_edu.crt. This is the certificate I need for the new Web site. The other two certificates are required if you need to chain the new certificate back to a root certificate. We will not be discussing them in this document.

The new certificate is nothing more than a text file, as was the case with the CSR. However, in this case, the information starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----. In the previous step, the terms were BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST. Extract the contents of this zip file to a location accessible from your Web server.

Step 4: Install the certificate

After making sure that your Web server can access the certificate files, you need to install the new certificate so that it can be used by your Web site.

  • Choose Start | Administrative Tools | Internet Information Services (IIS) Manager.
  • In the IIS Manager, choose your server name.
  • In the Features pane (the middle pane), double-click the Server Certificates option located under the Security heading.
  • To complete the process of requesting a new certificate, from the Actions pane, choose the Complete Certificate Request option.
  • The Complete Certificate Request window opens and asks you to provide the location at which the certificate file can be located (Figure G). Provide this location and also indicate what friendly name you would like to use for the certificate.

Figure G

Tell the wizard where it can find the certificate file and provide a friendly name

The certificate is now installed and ready to be assigned to a Web site.

Step 5: Add an HTTPS binding to a Web site

Now, with the certificate installed, it's time to put it to work. In IIS 7, you need to bind the HTTPS protocol to a Web site and then assign an installed certificate to be used to protect that Web site. Follow these steps:

  • Choose Start | Administrative Tools | Internet Information Services (IIS) Manager.
  • In the IIS Manager, browse to your server name | Sites | Your SSL-based site. You may need to create a new site. In Figure H below, notice that my site is named ssltest. The full Internet path to this site is Since this Windows Server 2008 machine is running in a lab, you will see that it is a member of the Contoso domain, but I have added sites to this server and appropriately configured DNS.

Figure H

A look at a site to which HTTPS will be bound
  • From the Actions pane, choose Bindings. This opens the Site Bindings window shown in Figure I.

Figure I

The Site Bindings window
  • In the Site Bindings window, choose Add. This opens the Add Site Binding window shown in Figure J.
  • From the Site Bindings window, provide the binding type (HTTP or HTTPS, but for this purpose use HTTPS), the IP address that will be used for this site ( for me), and the port that will be used for SSL.
  • Next, choose the SSL certificate that you want to use to protect this site. Note that I have chosen Use the Browse button to locate the right certificate.

Figure J

Provide the appropriate details for the Add Site Binding dialog box
  • Click the OK button. See Figure K for the result.

Figure K

The results of the new binding

Step 6: Test your certificate

Now, test your certificate by browsing to the new site. You should not get any certificate errors. In Figure L note that I have successfully browsed to the new site and that there is a lock icon indicating that SSL is active. Figure M is a look at the certificate as detailed in the Web browser.

Figure L

The site is being protected by SSL

Figure M

The certificate is valid


Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive w...


I have a wildcard SSL certificate * How do I install it to IIS 7 since you don't have the CSR. I figured it out... My problem was a wildcard SSL certificate was installed on Server A and I was trying to install it on Server B. It turns out I only had the public key so it would not install. I had to export the SSL certificate from server A and then I could install it on Server B.


We have a single web server and several web "sites" on it (we have as many as 20 at any given time. Each web site has a different ssl ip address. I wanted to get a product like WebInspect, but they charge per IP address, not per server. Is there a way to set up one IP address for all websites?


whats the advantages of this SSL?? And what is the Use of it??


Great work, i appreciate you, i like this kind of work and article writing style.Keep it up


How to configure virtual websites running on a single IP with different certificates for different domain names?

Grayson Peddie
Grayson Peddie

Hi. I am developing a home automation website for controlling my lights/scenes, adding/remove timers, etc. Even with an membership provider (like in Project-> Administration Page, if I remember teh name correctly) and a login control (not allowing to add new users), is it practical to use SSL for encrypting data when sent to a server?


SSL Certificate is an ideal solution to secure your eCommerce website and their transaction. Using SSL Certificate, you can gain trust and confidence in online spectators towards your website. SSL Certificates products are available in two resource one for domain validate and other one for organization validate. To know more about SSL Certificates, visit,


A website SSL certificate binds an identity to the fully qualified domain name, not the IP address or port number. So if your websites are built using fully qualified domain names like "" and "", these are different domains and require separate certs. If you configure them as "" and "", then these share a common domain, and can use the same cert.


I can speak with reference IIS 6, but if it's even close to IIS 7, then you can request a separate certificate for each virtual server. The key to it is to make sure that each virtual server uses a different SSL port; set that on site properties first (I like the 8081+ range since they are close to the standard secondary ports to HTTP), then it is just like requesting a certificate for any other server, except that when enterting the request, enter the FQDN for the common name. You can also substitute the IP name that will be used most. For example on local intranets, you may only choose to enter only the hostname for the common name because users won't typically enter the FQDN when accessing the server.


if they share an IP, they'll have to share a single certificate.


If you take "practical" to mean easy, then no, especially if you do not have your own CA. Depending on your ASP .NET delivery implementation, it is possible to sniff out parts of your security as it passes over the network. The CA is fairly easy to set up, but when you create your first Root CA Certificate, give it a long life like 10-20 years, so that if you do get it all working, it won't quit too soon (I made my first one expire in two years and everything buggered by the time I finished everything). That said, it can be a good exercise in building and maintaining secure applications. Here are some fairly good references: For IIS, the Web server's parent virtual directory that contains the application and forms is where you'll apply SSL changes, like in Scott's instructions. Create a separate virtual directory for your application. Since I use IIS 6, I set the Require Secure Channel (SSL) flag in the Directory Security, Secure Communications, Edit property. It's probably similar in 7, although I've never experienced it. In .NET, I typically use Forms authentication, and deliver the ASP form using SSL, and after checking the POST environment in the application, I only process those forms that originate from my server and not a from a form that someone has managed to save locally, especially HTML ones.