Installing and Securing IIS Servers (Part 2)

Probably sooner or later someone will ask you, ‘You know, I’d like that directory/website to be only password-accessible. Could you do it?’ You could willingly go to the ‘Directory Security’ tab of the website’s (or directory’s) setup menu, turn the ‘Integrated Windows authentication’ or the ‘Basic authentication’ option on. Click OK, and? Perhaps your server has just become ‘slightly more’ vulnerable to attacks. Most likely causes of the problem are:

  • Password eavesdropping or cracking
  • Brute-force password guessing attacks
  • Unsuccessful attempts to guess the password may block the account

Of course, these dangers are trivial. However, this doesn’t change the fact that these are genuine dangers and that is why they should be analyzed. These hints may be helpful:

  • Never use the ‘Basic authentication’ option. It causes the sending of the user’s password through the Internet with no safeguards and may be used later by the nosy guys from the network in which the user’s browser is working at the moment. However, the Internet services managing program warns you that this is not a secure option.

(Fig. 1 – What’s it all about?)

  • If you want to use ‘Digest authentication’ method, your server has to belong to an Active Directory domain where the users’ passwords have to be saved in a decipherable form. Moreover, the password will be vulnerable to ‘replay’ attacks, i.e. those attacks in which the eavesdropper repeats the complete URL with the password,
  • The authentication should not take place in an account set (i.e. in a domain) intended for other tasks. Separating a domain devoted only to online Internet authentications and placing it with your Web Server in an isolated area of the network is a good idea even though it is expensive.
  • Try to limit the access to the sites that allow the IP-authentication of the user. It is not a strong safeguard but it helps to prevent the accounts from being attacked,
  • Don’t grant accounts to all willing people. Otherwise you’ll quickly lose control of who can and who can’t use the restricted-access WWW sites. Create a hard copy of who, when and why has an account and its expiry date,
  • If your service is to be accessible for accounts that can be created without the administrator’s involvement, you have to use application-level authentication, e.g. with the use of a database including a list of accounts which would be used by the ASP site that authenticates the passwords. Of course, such authentication is processed in plain text, so you could consider encoding it with the use of the secure http (HTTPS) protocol. Your decision should depend on the value of the password-protected data stock – Instead of granting an account and a password, you may allow the user access on the basis of their certificate (the electronic signature). Unfortunately, this solution requires HTTPS protocol (i.e. HTTP encrypted by SSL protocol). This way you can log a user into a Windows account and with the use of the own application authorization as well. The inexistence of the password would surely be comfortable and would enhance the security.

This is how to encrypt the WWW user’s connection with the server. Contrary to the well-known opinion, the HTTPS protocol is not the only way of ensuring that the WWW session remains confidential, nor is it a perfect solution to all the security problems. It is however popular, because it has undeniable merits:

  • It makes the eavesdropping of server-client (WWW browser) communication impossible,
  • It allows for unequivocal identification of the server to the client so that the client is sure that he/she communicates with the right server,
  • In adequate circumstances it allows authenticating the client to the server without using passwords (on the basis of a PKI certificate, i.e. the electronic signature installed in the user’s WWW browser).

Unfortunately, this is where the HTTPS’ advantages end. The problems you would have to face when using this protocol are:

  • The necessity of buying a server certificate. The price may be over several hundred euros for a certificate with a one-year expiry date. After having expired it has to be bought anew which requires a similar amount of money to be spent. Of course, there is a possibility of drawing the certificate up by yourself or by a friendly network administrator. However this way would make the user lose his certainty about communicating with the right server. How should he or she know that the certificate is secure if a trusted company has not issued it? Nevertheless, this is a cheap solution, which allows you to keep the remaining advantages of the HTTPS protocol (its confidentiality and the users’ authentication), which why it will be presented in the next article.
  • The need to devote a dedicated IP number for the HTTPS-available WWW service. Using the host-headers for servicing a number of HTTPS sites on one IP number is impossible. You may assign port numbers, which differ from the standard 443. A few years ago that requirement was no problem but now there are very many servers and the volume of the IP protocol address space has not grown. Moreover, increasingly often, companies decide to place their WWW servers at their Internet Providers whose IP address pools are not big enough.
  • Lack of a possibility to monitor the communication. The system, which should protect from attackers eavesdropping, also prevents intrusion detection systems from tracing hack attempts.
  • A heavily loaded WWW server. If the traffic on your website reaches hundreds of thousands HTTP requests, you surely can’t afford an HTTPS service for the whole site. This is caused by the fact that the encryption service (running an SSL session and encoding the data) burdens the CPU very heavily and significantly slows down communication with the client. [1][2]

Of course, one has to bear in mind the fact that in no case does the HTTPS substitute the basic safeguards of a WWW server. Using the HTTPS protocol is not a ‘magical’ way of limiting the hackers’, viruses’ and other unwelcome guests’ access to your website. The connections to the website with the use of the HTTPS protocol may be less popular but that does not exclude the possibility of using them for attacks!

Is in this case is HTTPS worth using? Yes, but you have to be aware of the limitations mentioned earlier and counteract them. An option for HTTPS is VPN – the Virtual Private Network.

These are the differences between these technologies:

  1. Primarily, a VPN user has to obtain a password to the network, secondarily he has to connect to it with the use of appropriate software, like Windows2000-built-in IPSec service. This excludes the high availability of services because you must not give away the password to a secured network to anyone who asks for it. Otherwise, sooner or later, the VPN users’ accounts will run beyond your control and the safeguard will become horizontal, which would be even more dangerous than its inexistence. Contrary to the VPN, the HTTPS protocol allows encoding of data independently from user authentication. Admittedly, it is possible to force the authentication of the other side in the IIS setup, but this setting is optional and unnecessary for the HTTPS to work.
  2. VPN gives access not to a particular service, but to a chosen address or group of addresses on the protected network. Should you decide to use VPN, you have to consider how wide the users’ access to the VPN-safeguarded network should be. This may be a single server, a small group of them, or – sometimes – a larger part of the network. Moreover, you have to consider the ways of dividing the network – will the VPN definitely allow blocking of access to particular IP numbers? The CISCO devices block them taking advantage of the IPSec protocol options. Unfortunately, some programs that establish the connection using the IPSec protocol do not recognize these options. In this case you could efficiently limit the network’s accessibility by installing additional routers, dividing the network into segments.
  3. The high price. Frankly speaking, an ordinary computer equipped with Windows 2000 Server installed, providing RRAS services may become a VPN appliance. In most cases, however, that is not enough. Running the VPN on a firewall allows for securing of the network more precisely but the price of such a device may be higher than the price of the dedicated computer.
  4. Lack of possibility to authenticate a VPN client towards a Web Server with a certificate. Obviously, the VPN connection itself may be using the certificate, which won’t be presented to the server because it couldn’t read it without using the HTTPS. You may run an HTTPS connection inside the VPN but in this situation it would be safer and less expensive to do without the VPN at all.

Another possibility is ‘delegating’ the HTTPS encoding to other devices, so-called SSL accelerators. They take on the service of the incoming HTTPS demands and they transfer ordinary HTTP demands to the WWW server. Due to this, monitoring server traffic with the use of intruder-tracing tools, as well as, relieving the servers of CPU-power-expensive encryption operations is possible. Unfortunately, using the SSL accelerators makes it more difficult (or even impossible) for the Web Server to read the users’ certificates. The other serious disadvantage is the price involved. [3]

In many situations, you could give up encryption completely, but do remember the fact that the transmitted information may be eavesdropped. Infer possible consequences  – not all information in the encrypted connection is worth burdening the processors with extra load J. A hint for webmasters: the javascripts, pictures and style sheets, i.e. all the elements downloaded by the browser for displaying the website, will also be encrypted. The greater their number and volume, the more expensive cryptography becomes – taking into consideration CPU usage and transfer time. Obviously, only some elements of the website may be encoded but such a situation will confuse the users’ trust: should they trust the captions? And not the graphics? Or maybe the DHTML scripts shouldn’t be trusted, either?

Let us finish this theoretical dissertation and start installing the HTTPS safeguards on your website. To do this, you should use a test certificate, issued by VeriSign Incorporated. However this certificate will not make your server credible to your users, because you, yourself may issue it for your own system. Unfortunately, you have to issue a fee for authenticating your own server [4][5]. Let us find the website [6] of VeriSign Incorporated which describes the website security products. Click the ‘Try’ button underneath the product located second from the top.

(Fig. 2. Here is where your adventure with HTTPS starts)

Subsequently, you’ll have to answer a short questionnaire and transfer it by clicking the ‘Submit’ button. After having submitted the questionnaire, you’ll see an information site. Before clicking the ‘Continue’ button try to read it with total comprehension. The next step is generating a certificate request – to obtain it, go to the earlier presented MMC ‘Internet Server Manager’ application (while leaving the Internet Explorer window open all the time), click the right mouse button on the name of your company and open the ‘Properties’ window. Having passed to the ‘Directory Security’ tab, click the ‘Server Certificate…’ button in the lowest of sections, ‘Secure communications’. From the ‘IIS Certificate Wizard’ homepage go to the operation choice and search for the ‘Create a New Certificate’ option. The next screen will allow you to choose only one option: ‘Prepare the request now but send it later.’ Then fill in the fields necessary for the certificate – the name should be the same as the DNS’ name of your website, while the length shouldn’t be smaller than 1024 bits.

 (Fig. 3 Generating the CSR)

On the subsequent screen, fill in the “Organization” and “Organizational unit” boxes (the first box should contain your company name, the second one should bear the name of a department or location respectively). On the next screen, type the full DNS name of your website (in my example this will be, but the reader should naturally enter the fully qualified name of the server as accessible from the Internet or Intranet). Click Next and enter information regarding your organization  – remember to place your country name (PL for Poland etc.), also type the state/province and city or locality. At the last screen, select a location and file name to save your request to – select Desktop of the current user for your convenience. After pressing Next, you will be presented with the identification information that is seen on your server’s certificate – this information will be accessible for any user who has access to the HTTPS connection with your server. If you buy the certificate, make sure that it includes data to be certified as valid by the certificate provider − you can go back to correct data if necessary. After clicking Next you will see the certreq.txt file. Go back to the VeriSign enrolment center and click “Continue”. You will be prompted to submit the Certificate Signing Request (CSR) followed by a large text box to copy and paste the contents of the previously generated certreq.txt file.

(Fig. 4   Submitting a CSR  to VeriSign)

After clicking the “Continue” button, you will be taken to the information of your CSR previously typed in the IIS. You should complete the enrolment form with additional root contact information. After you’ve read the test certificate agreement, click on the “Accept” button. You will be provided with information on certificate processing. After the certificate has been approved, VeriSign will return the signed certificate to you via electronic mail. Before you check your email box, you must install the Test CA Root Certificate on your WWW Server and on any browser that will use HTTPS communications (this is a disadvantage of test and free downloadable certificates − commercially distributed certificates are usually installed by default in Internet browsers and on an IIS server). Select the “Frequently Asked Questions” link and you will again see the VeriSign’s Certification Practice Statement regarding the use of a Test Certificate − you are informed that “VeriSign makes no representation or warranty to any person that any subscriber to which it has issued a test certificate is in fact” and does not verify the certificate user authentication (the next disadvantage of test certificates). Click the “Accept” button to open the box to save the “getcert.cer” file − locate it, for example, on the active user desktop.

(Fig. 5 Getting the VeriSign Test CA Root Certificate…)

Then you can open it in a normal way and see the signing certificate for your server. Now you should install it on your Web Server – to do this, click on the “Install Certificate…” button and click Next on the first page of the “Certificate Import Wizard”. In the next page, select the “Place all certificates in the following store” option and click on the”Browse…” button. You will be presented with the certificate destination selection box  – you should select the “Show physical stores” option and then select “Trusted Root Certification Authorities > Local Computer”.

(Fig. 6 … followed by its installation)

Then continue – on the last page of the wizard click the “Finish” button to quit the wizard. You will get a message box confirming that the certificate was created. If you close the certificate page now and re-run it, you will see that the certificate is highlighted without the cancellation mark – this means that the import of the certificate was successful and from now on your computer will trust this CA certificate and any other signed by the same Authority. 

(Fig. 7  Your website is now secured by a trusted VeriSign Test CA Root Certificate).

Having the test phase completed you must uninstall the Test Root Certificate to avoid having “trusted” communications with other servers that use the same Test CA Root Certificate.

Now you can check your email − VeriSign is expected to send a message about the new certificate for your server within one hour at the latest. At the end of the certificate you will see a portion delimited with “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—-“.

(Fig. 8  You have obtained the certificate!)

To copy the server certificate, add the begin certificate and end certificate lines into a text editor such as Notepad. Save the server certificate as a text file (with a .cer file extension for your convenience) and go back to the “Directory Security” tab of your website configuration page and click the “Server Certificate” button again. This time, select the “Process the pending request and install the certificate” operation. On the subsequent  wizard’s window, select the certificate file you previously saved on the disk and confirm the certificate information. Lastly, click on the “Finish” button. Now you can check the SSL settings for your website. On the “Directory Security” tab, underneath the “Server Certificate” button, you will see two boxes which have been highlighted: “View Certificate” (presenting the same certificate contents as that available for the server’s users) and “Edit” (to change the HTTPS bridging settings in a current website, directory or file). Before you connect to the Web Server via an encrypted connection, you should attach a port and ID to your website. Select the “Web Site” tab, click on the  “Advanced…” button to open a window that gets you to the procedure of IP number attaching to the website (and also for attaching names such as host−headers). The window holds two lists, the upper one containing the unencrypted website data, and the lower one related to SSL secure connections. Click on the Add button underneath the lower list and in the “Advanced Web Site SSL Identification”, select the IP address and type the port number as well (typically 443). Naturally, it can be the same IP address that has been assigned to a unencrypted website. Lastly, you should confirm the changes you’ve made.

(Fig. 9     Connecting your website using VeriSign SSL)

Now you can connect to the Web Server via HTTPS. Remember, that such a connection must comply with the following requirements:

  • Communications between the server and the browser user are secured by the same root certificate (a root certificate, because it authenticates the owners of other certificates) − in the example included; this is VeriSign Test CA Root;
  • The server has been provided with the certificate issued by the authority that is the owner of the said root certificate;
  • The WWW service runs on a secure SSL port and  is accessible from a user’s WWW browser;
  • The user communicates with the server using the same DNS name as that placed in the server’s certificate. Naturally, it is enough if the server name is “dissolved” by the client using an entry in the local Hosts file (for Windows 2000 it is the c:\winnt\system32\drivers\etc\host file) – you can check your certificate without the use of a DNS server.

If everything has been specified properly, on starting the HTTPS connection with your server you should see your Home Page provided with a characteristic small locked padlock indicating a secure connection. 

(Fig. 10   Your HTTPS is now working!)

What is the best way to enable certificate-based user authentication? Use the HTTPS settings. Click on the “Edit” button under “Secure communications” and in the “Directory Security” tab you will see the “Secure Communications” box.

(Fig. 11 The HTTPS settings)

You can select among the following options:

  • Require secure channel (SSL) − this setting implies that the website (or a page/directory) will be accessible over an encrypted connection only. Any attempt to activate an HTTP connection will generate a “403 SSL required” message error. You can also establish a 128-bit minimum encryption strength (in terms of a symmetric key), using the “Require 128-bit encryption” option.
  • Client certificates – it allows one to read or even enforce authentication of the user using his own SSL certificate. Setting to “ignore” causes the IIS not to read the contents of the client certificates. Setting to “accept” will allow it to read the contents of the certificates in the WWW application (i.e. ASP pages) − using the Request.ClientCertificate Collection [7] and certain fields of the Request.ServerVariables Collection [8]. If you have enabled this latter option based on the SSL authentication, you can also select the “require client certificate” option − the users not certificate-authenticated will receive the “403 Client certificate required” message error.
  • Enable client certificate mapping − it allows one to login Windows user accounts using certificates i.e. without the need to send the password to the user. This setting may be of concern, if you intend to secure the server resources using an ACL – for example, restricting access to the website files for selected users. If you intend to use this option you should define the certificate mapping rule − click on the “Edit…” button to open the relevant box.

Two certificate mapping rules are possible:

  • 1-to-1: One-to-one is the mapping of a single user certificate to a single user account (it is enough to use the public part only, for example, taken from an electronically signed message). This certificate can be used to map it to the user account for authentication. A user can now use Secure Socket Layer (SSL) to connect to the web page securely from anywhere, provide his or her client certificate to the web server, and be logged on using his or her own user account. Whenever a user changes his account, you will have to re-configure the   mapping..
  • Many-to-1 : you can set a rule that maps all certificates issued by that CA. This mapping rule means that many certificates can be mapped to a single user account and no configuration change is required whenever the user changes his certificate – it is sufficient that the essential certificate data remains unchanged. You can verify the data provided in the Subject field (certificate owner’s information) and  Issuer (the certificate issuer’s information).  An exemplary Many-to-1 mapping is illustrated in Figure 12.

(Fig. 12   An exemplary Many-to-1 mapping)

Whilst a very simple ASP page to read a certificate is presented in the default.asp file.

(Fig. 13   A certificate-based authentication).

Remember that with user certificates it may be required to install additional certificates on the server − the ones that have been used to sign the user certificates. If you take advantage of free downloadable certificates such as Thawte Freemail [9], you should also download the “Personal Free mail RSA 2000.8.30” certificate, which is a CA Thawte Freemail certificate used to sign and encrypt email – otherwise you will not be able to identify the signer. This operation is neither necessary nor risky – intermediate certificates automatically inherit the trust
settings of their roots that are installed by default in your operating system.

If you want to restrict user certificates to root CA certificates, utilise the lowest option in the  “Secure Communications” window:

  • Enable certificate trust list: here you can select a list of trusted CA certificates. Click on the “New…” button to create a specific list, choosing CA certificates from both local “Trusted Root Certification Authorities” (this is the same list you used to place the Thawte CA Root Test Certificate) and from the file system.

If you use certificate mapping, you will obviously take advantage of Windows accounts – but many applications do not require this. A certificate can be verified and read without mapping of certificates – as is presented in the default.asp listing. In this way, a certificate of the user can be used for example, to authenticate users in the account listing stored in the database – without utilising user passwords! Because a certificate is verified by IIS, it is enough to read the “Flags” field (that should be equal to 1), and “Issuer” and “SerialNumber” (or “Issuer” and “Subject”) – that can be then used as a key for a unambiguous indication of a user in your application account list.

I hope that you will find this brief glance at the HTTPS technology a useful reference. This series will continue with certain simple, but useful, methods for improving IIS 5 performance.

If you would like us to email you when Bronek Kozicki releases another article on, subscribe to our ‘Real-Time Article Update’ by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!

Bronek Kozicki has worked as a Network Administrator for the last eight years. Five years were devoted to Windows NT-based systems. He deals with administering SQL Server databases, applications, network security issues and efficiency of Internet Servers. He writes server solutions (chiefly extensions of the IIS services – the SMTP and the W3SVC) in the C++ language. Besides programming, he is concerned with teaching advanced C++ uses such as: methodology, idioms, programming styles and the modern features of the language. He was a member of WinSecurity Magazine’s editorial board where he was chief editor of the Microsoft Knowledge Base pages. At the moment he works as a Network Administrator in Getin SP S.A., a company providing Internet services. He spends his free time with his wife, going for walks or to the cinema, or reading books, preferably science fiction. He is the world champion in preparing hot chocolate with froth or cappuccino.



About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top