Computers, Programming, Technology, Music, Literature

SSL – Managing Certificates in Windows Server 2008 / IIS 7 – Part 1

leave a comment »


Download a pdf version of this post here –






How SSL works?

Applying for a new Server Certificate

Create a new CSR

Submit the CSR and obtain a Server Certificate

Install a new Server Certificate on the Server

Bind a Server Certificate to a website that uses SSL

What now?

References and Further Reading


                SSL – Secure Sockets Layer – is a network protocol that operates on the Presentation Layer of the OSI Infrastructure. SSL aims at providing authenticity and message confidentiality using public key cryptography and symmetric cryptography combination. The standards documentation of the SSL v3 can be found here. This article aims at discussing what is considered a very basic foundation of today’s SSL implementation on a browser client and a web server scenario. And explains the process of managing a SSL Certificate (right from the scratch). By managing I mean creating a new signing certificate request, installing it on the server, mapping it to the website hosted in IIS, exporting/importing the certificate on the new servers. This article does not describe the process of updating a certificate on its expiration. Internet Explorer 9 is used as the browser client to demonstrate a few examples. And the target environment is going to be Windows Server 2008 (R2) and IIS 7(.5). Albeit the concepts and methods discussed here could pertain to any Certificate Authority, it is required that you follow the standards and guideless established by your IT organization. Considering the extensive screenshots included and the length of the content, I am writing a Part 2 of the article. Make sure you read it. To make it interesting I will go over the SSL hand shake process and slowly glide in to reality. If you don’t understand a particular thing, you will be able to relate to it as you move on. Let’s get started!

How SSL works?

                Ok! I hope this section serves as a refresher to many of us. It is going to be theoretical for the next two pages. So you may skip if you don’t like stories. The overview and the information provided here might vary with different ciphers chosen by the browser. With SSL, the client and the server operates on a mutual understanding of encrypting and decrypting a message using a shared session key. There are authentication techniques where the client requires the server to present an SSL Certificate (Server Certificate) and sometimes to beef up the security the Server might request the client to present an SSL Certificate (Client Certificate). We are going to look at the former technique which is widely and commercially deployed among a browser and server scenario while the later applies to more secured communications which is not covered in this article. For the starters, here how an SSL Hand Shake works.

SSL Hand Shake:


                The SSL Hand shake process allows the server or the client to authenticate itself to the target. The client (referred to as browser from now on) identifies a request that demands data communication over SSL. This could be a hyperlinked URL (simply, a URL beginning with https), or a server based redirection/logic or a JavaScript based logic or any possible mechanism available as of today. The browser identifies this as a first step and then requests the server for more information, and proceeds if everything goes well. Here are they explained step by step.


1à The client sends the server, its current SSL settings. The client actually sends the list of encryption algorithm that it supports to the web server and some other session specific data. One of them to mention is a Random challenge string (CRC).

2à The server sends the client, its current SSL settings. The server actually sends its SSL certificate (which has the public key – SKU – in it and other numerous information), its Random Challenge string (SRC). And the cipher algorithm that it has selected from the list of cipher algorithms the client sent.

3à The client uses the information from the server to authenticate the server itself. The process of authenticating the server follows systematic order. This is explained better in the part 2 of the article where I discuss the Server/Farm Scenario and UCC Certificate. If the client is not successful in authenticating the server, it quits and displays an error message. Again a couple of these error messages are discussed in the part 2 of the article. The process proceeds further, if the client authenticates the server successfully.

4à Using the information transferred so far, the client creates a pre-master secret (PMS), encrypts the pre-master secret (PMS) with the public key of the server (SKU) and sends it to the server.

5à The server decrypts the encrypted pre-master secret (PMS) with the server’s private key (SRK) and calculates a master secret.

6à By this time, the client also has the master secret contrived. The client and the server use the same mathematical algorithm for creating the master secret. This algorithm is chosen based on the selected cipher algorithm. This master secret is then used to create a session key/shared key for the current communication.

7à The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. And a separate portion of the message indicating that the client hand shake has ended.

8àThe server sends a message to the client informing it the future messages from the server will be encrypted with the session key. And a separate portion of the message indicating that the sever hand shake has ended.

9à The client and the server use the contrived session key to encrypt and decrypted messages throughout current session unless a re-hand shake is triggered by some interrupt.

  • The strength of the encryption that happens throughout an https session depends on the chosen (negotiated) encryption algorithm and the cipher strength supported by the browser. To identify the cipher strength supported by Internet Explorer, go to About in the Help menu of IE.
  • And there is an order in which Internet explorer negotiates to use a particular encryption algorithm. There’s a way to tweak that too. Have a real good justification if you want to do that. Change the SSL cipher order.  That article applies to Windows 7, Server 2008 as well.
  • This website claims to identify the current algorithm used by the browser when you hit the URL

Note:    Simplified version of a symmetric encryption and a public key encryption


Symmetric Encryption:  The client and the server use a shared (symmetric) key to encrypt and decrypt the message.

Public Key Encryption: The client has a public key (KCU) and a private key (KCR). The server has a public key (KSU) and a private key (KSR). The client encrypts the message with the public key of the server (KSU) and the server decrypts the message with the private key of the server (KSR). This step happens vice versa throughout the entire communication.

I could explain this a bit more, however that is beyond the purview of this article.


Here is an image from Wikipedia simulating the entire SSL hand shake. The image below might vary from the above explanation a little bit, as I have already said; this hand shake process might differ between the chosen ciphers. Anyways, that is the gist of it; any SSL handshake revolves around a similar concept.



 The screenshot below shows hotmail exposing its public key to the browser.  You might want to refer to step 2 of the SSL hand shake explained above.


















Let’s see more screenshots like this in the part of the article. Before we proceed further, we need to understand a CA – Certificate Authority. When I say names like VeriSign, Entrust, GeoTrust, GoDaddy, Thawte, and Comodo – they refer to a CA.  More?  Here.

Applying for a new Server Certificate

                Lets say this is the first time we are going to deploy our website with SSL support. And we don’t have a certificate yet. SSL uses port 443 as the default port just like 80 for HTTP. But you are not limited to 443; you are free to configure (bind) the website with SSL support on any port that is available on the server – based on the organization standard guidelines. Applying for a new Server Certificate involves creation of a new CSR, submitting it to the CA and hence procuring an SSL Certificate. The entire Certificate life cycle can be managed via the Windows Certificate Manager (certmgr.msc), this article uses IIS7 which makes the process simple enough to comprehend and apply at work.


Create a new CSR

                To get a new certificate, we need to create a Certificate Signing Request (CSR) and send it to the CA. Based on the verification process in place the CA authority will review the information provided in the CSR and then issue a Server Certificate.

            What you need to know to create a CSR?

1.       Common Name –

This is the Fully Qualified Domain Name (FQDN) of the server/nameplate/domain name (from the URL to the website).

For instance, if you are accessing the website’s default.aspx through the URL then the common name is

The name of underlying server on which the website is hosted could be anything – just anything – it could be a server farm, but when you apply for a certificate, the end user might not see the direct server name in the URL, instead he’d see a domain name that could be a DNS reference, that could be a load balancing server or the actual server itself. Eventually, the domain name in the URL should be the common name. If this does not comply, then the browser will display “address mismatch” error. You communication might be encrypted and secure (if you are certain), but the certificate issued and the URL that is accessed, if they both are different, then it is an ‘address mismatch’ error. Address mismatch error is demonstrated in part 2 of the article.


2.       Organization –

The complete name of the Organization. Eg: Microsoft Corporation/ AcmeFiction Inc.

3.       Organizational Unit –

The subunit under the app or the dev team that owns the app falls in. Eg: Sales, IT, Research, etc.

4.       City/ Locality –

Eg: Redmond

5.       State/ Province –

Eg: Washington

6.       Country/ Region –

Eg: US, GB, IN


                The above 6 are the principal information that is required in hand, before you could go ahead and create a CSR.

          Now, follow the steps below to create a CSR.

            Steps to Create a CSR:

                                1àClick on the Start menu, go to Administrative Tools, and click on Internet Information Services (IIS) Manager.


                2à Click on the name of the server in the Connections column on the left. Double-click on Server Certificates. [Make sure you have Features View selected in the bottom of the pane, else you won’t be able to see Server Certificates]

















3à In the Actions column on the right pane, click on Create Certificate Request…


                4à Enter all of the following information about your company and the domain you are securing and then click next.

          [The information you enter here is validated and verified by the Certification Authority, so you need be certain of what you enter here. For instance, if you enter Texas in City and Houston in State, then your CSR will be sent back to you for corrections. Follow the guidelines that are specified in the beginning of the article to choose a common name]


Other sample:




Common Name (CN)

The fully qualified domain name (FQDN) of your server. This must match exactly what you type in your web browser or you will receive a name mismatch error.


Organization (O)

The legal name of your organization. This should not be abbreviated and should include suffixes such as Inc, Corp, or LLC.

Google Inc.

Organizational Unit (OU)

The division of your organization handling the certificate. (Most CAs don’t validate this field)


City/Locality (L)

The city where your organization is located.

Mountain View

State/province (S)

The state/region where your organization is located. This shouldn’t be abbreviated.


Country/Region (C)

The two-letter ISO code for the country where your organization is location.



                5à Leave the default Cryptographic Service Provider. Increase the Bit length to 2048 bit or higher. Click Next.

[Note: This bit length has nothing to do with the cipher strength presented by the browser. This bit length is used when encrypting the CSR that is to be submitted to a CA]

2048 bit length for a CSR encryption has become the status quo minimum level of encryption strength.


                6à Click the Browse button (button with the three dots) and enter a location and filename where you want to save the CSR file. Click Finish. Remember this location; we will need to open this file in a notepad, at our next step.



           That’s it! The CSR is complete. Send it over to the CA to get a Server Certificate. 

Submit the CSR (and obtain a Server Certificate)


          Once the CSR is created, we need to submit the CSR to the Certification Authority (like VeriSign, Entrust, Thawte). Multinational corporations have tie ups with CAs like VeriSign, Entrust and they run their own intranet portals, where you could submit the CSR and obtain a certificate. If you are a individual owning a website, get in touch with your website host or the CA for the steps required to obtain the certificate.

          Either way, it is going to as simple as submitting the CSR, and obtaining the certificate through or via a web form or an email. The certificate formats sent are usually one of the file extensions here – .p7b, .pfx, or a .cert.

          You might also be required to provide a SAN (Subject Alternative Name) – which is covered in the part 2 of the article.

Note that this process takes a week or so in general. If you have a privately held organization, and if you are submitting your CSR, then the Certificate Authority validates the information provided in the CSR and it verifies the authenticity of the organization. This process it standardized and the CA ensures that the Common Name is registered by the Organization that is applying for a CSR.


Install the new Certificate on the Server

                Ok, so we created a CSR, we applied for a Certificate and we received the Server Certificate, let’s go ahead and install it to the Server.


            What do we need?

                The Server certificate. (Either a .p7b file, .pfx file or .cer file)

          You can install the certificate on the machine through the Certificate Manager Console or through the IIS. IIS 7 simplifies the process way better compared to IIS 6. So, let’s open up IIS.   

                1à Click on the Start menu, go to Administrative Tools, and click on Internet Information Services (IIS) Manager.

          2à Click on the name of the server in the Connections column on the left. Double-click on Server Certificates.

                3à In the Actions column on the right pane click on Complete Certificate Request…



4à Click the browse button (button with the three dots) and select the server certificate that you received from the certificate authority. If the certificate doesn’t have a .cer file extension, select to view all types. Enter any friendly name you want so you can keep track of the certificate on this server. Click OK.


                5à If successful, you will see your newly installed certificate in the list (The below screenshot is not meant to scale or represent the TenderAppCert example). If you receive an error stating that the request or private key cannot be found, make sure you are using the correct certificate and that you are installing it to the same server that you generated the CSR on. If you are sure of those two things, you may just need to create a new Certificate Request and reissue/replace the certificate. Contact your certificate authority if you have problems with this.


          That completes the installation of a Server Certificate on the machine.

Binding the certificate to a website using SSL

                The website that needs SSL support should be bound with a Server Certificate. Let’s look at how we can bind a website with a certificate.

                1à In the Connections column on the left, expand the sites folder and click on the website that you want to bind the certificate to. Click on Bindings… in the right column.



                2à Click on the Add… button.


                3à Change the Type to https and then select the SSL certificate that you just installed. (or any desired certificate from the pull down list) Click OK.

4àYou will now see the binding for port 443 listed. Click Close.



                Now, we have bound the website (Default Web Site in our case) with a certificate configured to operate on port 443. As I have mentioned earlier, if 443 is not available, you can use other desired and available ports.

          If you have configured the SSL certificate binding for a website and access it via the URL ( IE, you will see a padlock icon by clicking which you can view the Server Certificate that the website presents.

You are restricted to one server certificate per endpoint (ip-port combination) since the server needs to use a particular server certificate for all connections to that endpoint (there are some rfcs about how the client can tell the server which certificate to choose but that is not implemented in iis7) – if a site is bound to multiple end-points, you can have multiple server certificate, one per endpoint.

          A sample from yahoomail and hotmail through IE9.



What now?

                That completes the task of a simple SSL certificate deployment bound to a secure website. There are a few more things to be discussed about the Input/Export wizard and Load Balancing Scenario, Server Certificate Validation and Browser Error messages. Read on the Part 2 of the article. If you find any deviation in the content, please bring it to my attention.

References and Further Reading

  1. Cryptography and Network Security 4th ed, by William Stallings
  2. Computer Networks 3rd ed, by Andrew S Tenenbaum
  4. How SSL Works
  5. Description of the Server Authentication Process During the SSL Handshake
  6. Description of the Secure Sockets Layer (SSL) Handshake
  7. Extended Validation Certificate
  8. Unified Communications Certificate
  9. SSL v3 IETF Draft
  10. Configuring Server Certificates in IIS 7
  11. Windows 2008 – How to Install GoDaddy SSL Certificate – IIS 7



Written by gmaran23

January 4, 2013 at 11:24 am

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: