Computers, Programming, Technology, Music, Literature

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

with one comment


Download a pdf version of this post here –




Server Certificate Verification during SSL hand shake (cont… from part 1)

Browser Error Messages and Examples

Load Balancing/ Server Farm Scenario

Exporting a Certificate

Import a Certificate

Subject Alternative Name (SAN)/UC Certificate

Extended Validation Certificate




                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 does not describe the process of updating a certificate on its expiration. CSR Creation, Applying for SSL, Installing it on a server, binding it to a website is covered already in the part 1 of the article. This article describes the Server Certificate Verification by client, Importing/Exporting a SSL certificate, introduction to Extended SSL, UCC Certificates and few more interesting screenshots. Though this article might stand on its own, it assumes that you have read the Part 1 already, because some of the things in Part 1 are referred here. 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). If you don’t understand a particular thing, you will be able to relate to it as you move on. Let’s get started!


Server Certificate verification during SSL Hand shake

                Ok! I hope you remember the step 3 in the SSL handshake (part 1 of the article), after the client sends its SSL support information, the server responds the client with a SSL certificate. The client verifies the validity of this SSL certificate and proceeds if the process is successful. If the server certificate is not valid, the client quits the session and displays an error message.

                The browser follows the steps below in order to verify the Server Certificate. If any of these steps fail, the Certificate verification process quits and the browser throws appropriate error message.

Once we have discussed all these steps, I will have a few screenshots wherever applicable and I will be referring to these point numbers in the upcoming sections.

1à Is today’s date within the validity period?

                The client checks the server certificate’s validity period, if the client date and time are outside of that range, the authentication process does not go any further. If the current date and tie are within the certificate’s validity period, the client goes on to step 2. 

2 à Is the issuing Certificate Authority (CA) a trusted CA?

The browser (and the operating system) maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client’s list of trusted CAs, the answer to this question is yes, and the client goes on to step 3. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list. Certificate chaining exists because the CA’s typically improve their sales via re-sellers and partners. The SSL certificates issued by these third parties should chain up (or stack up) to a trusted CA. 

3à Does the issuing CA’s public key validate the issuer’s digital signature?

                This point has its roots in the authentication mechanism used in the public key infrastructure of cryptography. That is, if we receive a message encrypted with a private key of the sender, that implies the sender has signed the message with its private key. Since it is a private key from the sender (and nobody else knows what the private key is), this ensures the authenticity of the message from the sender.

                Now the browser, uses the public key from the CA’s certificate (which it found in its list of trusted CAs in step 2) to validate the CA’s digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA, or if the CA certificate’s public key doesn’t correspond to the private key that was used by the CA to sign the server certificate, the browser does not authenticate the server’s identity. If the CA’s digital signature can be validated, the browser treats the server’s certificate as a valid “letter of introduction” from that CA and proceeds. At this point, the browser has determined that the server certificate is valid. It is the browser’s responsibility to take step 4 before it takes step 5.

4à Does the domain name in the server’s certificate match the domain name of the server itself? This step confirms that the server is actually located at the same network address that is specified by the domain name in the server certificate. Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a Man-in-the-Middle Attack. If the server’s actual domain name matches the domain name in the server certificate, the client goes on to step 5.

                This step is further explained under the heading “Load Balancing/ Server Farm Scenario”. And you might also want to apply for a UC certificate to include all possible domain names and servers that host a particular website. As obvious as it might seem, UCC certificates are expensive and price steps up for every SAN (Subject Alternative Names) that you add to the certificate.

5 à The server is authenticated. The client proceeds with the SSL handshake. If the client does not get to step 5 for any reason, the server that is identified by the certificate cannot be authenticated, and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.

That’s about the Server Certificate authentication process carried at the client side.


Browser Error Messages and Examples

Example 1: Certificate Expired

To fake a certificate expired error, you can try changing the computer’s date to an earlier date or later date. And visit any SSL enabled website, say (Any date that falls 10 years before or after the current date)













Hit Continue to this website (not recommended) to see a distorted PayPal with a certificate expired error.


Ok. Now this is not a problem with the PayPal certificate, as you know it is valid until certain period of time. The certificate issue and expiry date and a bunch other important information could be found at the Details tab of the View Certificate dialog box. Since the client has an unreal date, the client tries to validate the Server Certificate issued by, and when it tries to verify the date, it fails because the client’s date and the SSL Certificate’s issue/validity date is nowhere near, and thus displays a Certificate Expired error. 

Change your date to the current original. Below is with the current date. This might happen sometimes, some malicious program might have changed the date of the user’s computer and they are complaining that the website’s certificate is expired, instead of checking their computer’s date.


Example 2: Certificate was issued by a Trusted CA

Windows Certificate Manager (Start à Run à Certmgr.msc) lists the Trusted Root Certification Authority(s) currently supported by the operating system. If there are any new CA’s to be added to the trusted root, you should import them manually to the Trusted Root Certification Authority or if you want to access a wide range of users across the world, you can get in touch with Microsoft who would push a Certificate to the Trusted Root CA via a Windows update.

 Issuing Certificate to organizations is a business, and CA’s have their re-sellers too. When a certificate is issued by a re-seller, it should chain up to the original CA. And the original CA should be present in under the Trusted Root Certificate Authority Store. If it doesn’t then Step 2 of the Server Certificate Verification at the client fails. That is, any certificate issued by a CA, should have its certificate path chaining to a trusted root CA. Below is a screenshot from certificate manager.



If the CA that the website is presenting in its SSL Certificate is not in the Trusted Root Certification Authority, then the following error message is thrown by the browser. This means the CA that has issued the SSL Certificate to the website is not trusted by the browser.















If you are certain that the CA and the website are authentic, then you can install the CA’s certificate to the Trusted Root Certificate Authority Store. Once the certificate is installed to the Trusted Root Certificate Authority Store, from then on all the SSL Certificates issued by this CA will be considered as trusted by the browser.

                You can install the certificate on to Internet Explorer’s Trusted Root CA by clicking the View Certificate and then Install Certificate button. Follow the Certificate Import Wizard; make sure you import the CA’s Certificate to the Trusted Root Certificate Authority store.


                You will have to go through this big warning message to Import a CA’s Certificate to a Trusted Root CA store. [I was trying to add a CA named “AddTust External CA Root”].
















To view the list of Trusted Root CA’s in IE and to install a CA certificate to a Trusted Root CA in Firefox, Follow these articles. Listing a Trusted Root CA and Add a Trusted CA in Firefox

In, the Certificate issuer is actually DigiCert High Assurance CA -3. But since the certificate chains up to a Trusted CA GTE CyberTrust Global Root, this becomes a valid SSL certificate.


Load Balancing/ Server farm Scenario

                This is going to be a typical anticipation of any enterprise when they host a website for the internet users. The website is accessed via a nameplate URL, which is a DNS entry pointing to a Load Balancer and the Load Balancer might pass on the request to a server/server farm.           

                Let’s imagine that we are going to access a website named TenderApp via the URL; where is mapped to an DNS entry

          And is your company’s load balancer which has multiple nodes hosting the website. Let’s imagine there are four nodes on which TenderApp is hosted. The four servers hosting TenderApp are





Though the website is hosted on four servers and the load balancer takes care of routing the request, the website is available to end users via the where is the domain name that a user views on the browser. And the browser has no idea about the load balancer or the underlying servers. All the browser knows is the website with a domain

So when you apply for a server certificate, and when we create a CSR, the common name should reflect the URL that the browser is going to know. That is the URL that a user will use to access the website. In our TenderApp example, the common name becomes

And in Part 1 of the document, we installed a certificate to a web server via IIS7. And we bound an SSL enabled website to this certificate.

Now we have four servers hosting the TenderApp that is served via the URL

To bind the certificate in all the four servers, what we can do is, create a CSR from a server. Install the Server Certificate on that particular server. Once the certificate is installed, we can export it and then do an import in all others servers. And then bind the website with the Server Certificate.

So we create a CSR from, obtain the Server Certificate; install the Server Certificate on Then export the Server Certificate from Import the certificate on all other servers (which installs the certificate in all other servers).

Export a Certificate

          To export a certificate, follow the steps below.

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à Click on the Server Certificate you want to export and then select Export from the Actions pane.

4à Specify the location to export the certificate. And then type in a password. And hit OK. [This password will be used when you try to import the certificate. So you need to remember it]


5à The certificate gets exported to the location specified. And in my desktop it looks like this.


That completes the certificate export process.

Import a Certificate

          Follow the steps below to import a Server Certificate

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à Select Import from the Actions pane.


4à Locate the exported certificate (.pfx file) and specify the password, leave the checkbox Allow this certificate to be exported checked. Hit OK.



That imports the certificate to the new server. This import process is equivalent to installing a new Server Certificate as we have seen before.

The exported certificate could be imported to all the necessary servers (,,….) and then bound to their respective websites.


Subject Alternative Name (SAN)/UCC Certificate

Example 3: Mismatched Address Error

Look at the screenshot below. A potential Mismatched Address error at . Look at the URL and the Common Name (CN) in the certificate subject. The CN says the certificate is issued to but we are accessing the website using and not We can rephrase this scenario as a subject ( has its domain name certified to a specific common name. And hence the certificate does not pose any other name than this.

This error could be overcome by the use of Subject Alternative Name (SAN) that allows multiple domain names mapped to one SSL Certificate.  So if wants to make its customers happy by not showing them any error, then it needs to apply for a certificate that would work for both and When applying for a SSL Certificate, make sure to include all your possible domain names in the SAN column. Having Subject Alternative Names is the only distinguishing feature of a Unified Communications Certificate (UCC). Here is a little more text on UCC.

It is not required to create a CSR with SAN in it. SAN should be mentioned at the time of applying for an SSL Certificate. Different CA’s allow specifying SAN at different stages when you submit your CSR.















Below is an implementation of a SSL Certificate with SAN for HPParts website. That means, you can access the website using any of those domain names specified in the list of SAN; and you will have a secured communication without an address mismatch error.

HPPS accessed with the primary URL.


                HPPS’s UC Certificate showing its SAN


                HPPS accessed using a domain in the SAN.


                HPPS’s UC Certificate showing its SAN


UCCs are expensive, use them sparingly. SAN from 



Extended Validation Certificate


Extended Validation Certificate follows a more rigorous validation of a CSR. The applying organization’s credibility is verified based on various criteria before an Extended CV is issued. Obviously the price is more. Extended Validation Certificates claim to provide better phishing protection than a regular SSL Certificate.

Starting from IE 8, when IE a browser detects an Extended Validation Certificate, the address bar turns completely green. We have seen and screenshots that used this kind of certificate. The criteria to suffice an Extended Validation Certification are outlined at here sslshopper.


What now?

                That’s about it. I believe the article was interesting. Part 1 and Part 2 covered the basics of an SSL communication with some real time screenshots. Please follow the guidelines provided in the Load Balancing Scenario as that’s how a typical corporate is architected, to say the least. 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:45 am

One Response

Subscribe to comments with RSS.

  1. Great post, and at just the right time for me.


    January 8, 2013 at 8:29 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: