Secure WWW server

On this page:


About secure WWW servers

A secure WWW server:

  • Is capable of identifying itself authoritatively to a browser.
  • Alllows for encrypted communications between the WWW server and browser over the Internet.

A secure WWW server, also called an SSL (Secure Sockets Layer) server, is capable of communicating over the Internet with a WWW browser in a secure manner.

Normally, the contents of any HTML document, image file, sound file, HTML form, or password entry dialog window are communicated between the WWW server and browser "in the clear". This type of transmission is not secure because no attempt is made by the browser to verify (authenticate) the identity of the server specified in the URL. In addition, no attempt is made by the browser or the server to encrypt or encode the information to make it useless to anyone monitoring the transmission.

How to know if your browser is communicating with a secure server

  • Your browser may notify you before displaying the page.
  • A "lock" symbol may appear in "locked" position on your browser.
  • The URL will begin with https:.

When to use the secure WWW server to deliver or collect information at your website

If you would feel uncomfortable entering the requested data into your form, consider whether you really need to collect that data. Additionally, many data elements are protected, either by university policy or law, and must be kept secure. If you are requesting or sending/displaying sensitive data on your page, you must use the secure WWW server to encrypt the data in transit.

For more about institutional data, see About working with institutional data at IU.

Commonly, empty forms are delivered to the user from a non-secure server. Once the user fills in the form, the "action" directive in the form specifies that the contents are to be sent to a secure (https) server for further processing.

It may also be appropriate to use a secure server to deliver a document when all or part of a document's content is sensitive, regardless of whether the document is static or was generated by a CGI program on the fly. You may or may not need to have .htaccess-style access protection on the file.

Issues to consider when using the secure server

Note that data collected via the secure server:

  • Are encrypted while in transit on the Internet (to or from a capable browser)
  • Are not encrypted in transit while being subsequently emailed by a CGI program (e.g., Transform)
  • Can only be processed by Transform if you install Transform in your account.

All page elements add to the amount of data that must be encrypted by the server before transmission, and subsequently decrypted by the browser upon reception. Large amounts of encyption and decryption can introduce delays; therefore, it is best to avoid wws using the secure server to deliver or receive pages/forms to or from the browser that contain large images, incorporate long sound, animation, or video sequences, or that contain large amounts of text.

When using the secure server, you should place any files (e.g., images) related to a delivered page in the directory that contains the HTML file for the page. This is especially true for directories that have an .htaccess file mediating access.

Where in your account to put documents to be delivered in a secure manner

To secure documents, place them in the /w directory (or one of its subdirectories) in your account. If you have no /wwws subdirectory:

  1. Log into your Webserve account, and enter:
      mkdir wwws
  2. Enter:
      chmod 700 wwwws
Note:
To prevent directory browsing, set the wwws directory for execute access only (chmod 700).

How URLs look for a secure WWW server

There are few differences between a URL that addresses a non-secure (http) server and one that addresses a secure (https) server. Following are examples of https-style URLs:

  https://www.indiana.edu/~account
  https://www.iun.edu/~account
  https://www.iuk.edu/~account
  https://www.iue.edu/~account
  https://www.iupui.edu/~account

Using .htaccess files in your /wwws directory

Using an .htaccess file to mediate access to a page in your wwws (secure) directory tree and having a link on that page that refers to a page in your www (non-secure) directory tree with virtually the same .htaccess file present might cause a repeat of the authentication prompt. This is because the browser believes the realm of authentication has changed (wwws to www). For more, see Controlling web page access.

How the secure WWW server accesses documents/programs in your /www directory and vice versa

This can be done only through links that are full URLs, not relative links.

The secure and non-secure servers are purposely configured to be completely independent of each other and to have no knowledge of each other's web spaces.

It is possible for you to create a CGI program for use from your /www (non-secure) directory that accesses files in your /wwws (secure) directory (or vice-versa), but UITS does not recommend this practice.

Using a secure WWW server if you have a virtual host associated with your Webserve account

You can do this in two ways:

  • In a basic, but less versatile approach, you can use the secure server (wwws directory), but you will not be able to use your virtual hostname in the URL. If your virtual hostname is http://vhostname.indiana.edu, your URL will take the form of your actual account name (plus the secure https designation at the beginning of the URL), and will look something like https://www.indiana.edu/~account/.
  • In an alternative, more versatile approach, you can use the secure server (wwws secure directory), and you will be able to use your virtual hostname in the URL. In order to do this, you will need to contact Web Services Support and request an SSL Certificate.

    In addition, the SSL certificate is involved in making the encyption of all data that is transmitted between the web browser and the secure web server possible as long as https:-prefixed URLs using your virtual hostname are being used.

Obtaining an SSL certificate for your website

All Indiana University web servers that display sensitive data to, or accept sensitive data from, must operate in secure mode. Secure web servers are addressed with the prefix https://, while web servers operating in nonsecure mode use http://. In order for a web account to operate in secure mode, the account's administrator must obtain and install an SSL certificate signed by a trusted certificate authority (CA).

The University Information Security Office (UISO) has partnered with the InCommon Certificate Service to provide SSL certificates to the IU community.

To obtain an SSL certificate on Webserve, contact Web Services Support.

Authenticating users and/or controlling access to web pages with a virtual hostname

Refer to the above section regarding use of the secure server with a virtual host. Note that all authentication of IU users must be encrypted.

  • You may use CAS whether you have an SSL certificate or not.
  • If you do not have a virtual host, you must use the method described in Controlling web page access.

This is document bfrv in the Knowledge Base.
Last modified on 2017-10-04 14:09:30.

  • Fill out this form to submit your issue to the UITS Support Center.
  • Please note that you must be affiliated with Indiana University to receive support.
  • All fields are required.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.

  • Fill out this form to submit your comment to the IU Knowledge Base.
  • If you are affiliated with Indiana University and need help with a computing problem, please use the I need help with a computing problem section above, or contact your campus Support Center.

Please provide your IU email address. If you currently have a problem receiving email at your IU account, enter an alternate email address.