An SSL-enabled web server is available at a2i. This means that URLs beginning with `https:' may be handled. All web sites hosted at a2i may use our SSL-enabled web server at no additional charge. However, when calculating your hits, each SSL hit will count as 20 scaled hits. To avoid going over your hit allocation you should use SSL selectively, such as for forms that are used to accept confidential information such as passwords. (NOTE: At this time we observe that SSL traffic is quite low, and we are not applying SSL hits against your total hits. We will begin doing at some time in the future, if/when we observe a significant increase in SSL hits.)
The term SSL stands for secure sockets layer, which describes a mechanism for encrypting data transfers on the Internet. In the rest of this document we will use SSL and https essentially as synonymous. Strictly speaking it's possible to use SSL for purposes other than accessing https URLs, but this is relatively uncommon on the Internet today.
To make cgi-bin programs work via SSL, you may create a subdirectory called `secure' within your cgi-bin directory, and put your scripts there.
For example, if a user `joeuser' has a web file called `myfile.html', its normal URL is `http://www.rahul.net/joeuser/myfile.html' . To make this file available to web clients via SSL protocol, the user will move the file into a subdirectory called `secure' and access it with the URL `https://secure.us.com/joeuser/secure/myfile.html' .
If the same user wishes to allow access to a cgi-bin program via SSL protocol, he would put the program in a directory called `secure' in his normal cgi-bin directory. Suppose the original cgi-bin program was accessed as `http://www.rahul.net/cgi-bin/joeuser/someprog' . Then the URL for accessing the program via SSL protocol, in its new location in the subdirectory called `secure', would be `https://secure.us.com/cgi-bin/joeuser/secure/someprog' .
If you wish to allow both `http' and `https' for the same document it's quite easy to do so. The obvious and simple approach is to make two copies of the document. However, this may lead to headaches later, because any revisions will need to be made in both places.
A slightly more convenient approach, suitable for those who don't mind logging into the UNIX shell, is to make a symbolic link so the same document appears in two locations. For example, if user `joeuser' has a document called `takeorder.html' in his main web directory, he can make the same document available via https by following these steps from the UNIX shell.
% mkdir secure (create the 'secure' directory) % cd secure (go into that directory) % ln -s ../takeorder.html . (make a symlink pointing to the file)
Once he has done the above, the file `takeorder.html' resides in his normal web directory, and it is also accessible by the same name from the `secure' subdirectory. So the same file can be accessed as `http://www.rahul.net/joeuser/takeorder.html' and also as `https://secure.us.com/joeuser/secure/takeorder.html'.
You can also make all files in a certain directory available via SSL, by representing the entire `secure' directory by a symlink. Don't create a subdirectory called `secure'. Instead, simply do this from the UNIX shell:
% ln -s . secure
The above UNIX command creates a pointer back to the current directory, in the form of a symlink called `secure'. Now every file in the directory is accessible both ways. Given any file `xxx.html', we may access it as `http://www.rahul.net/joeuser/xxx.html' and also as `https://secure.us.com/joeuser/secure/xxx.html' .
We don't necessarily advise you to make all files available via SSL. Since you are allocated a much smaller number of SSL-enabled web hits, you may easily overrun your allocation if you indiscriminately make files available via SSL.
To top howto page
To a2i communications home page
$Id: ssl.html,v 1.34 2003/01/27 10:57:45 lrdroot Exp $
$Source: /mi/home/guest/www/howto/RCS/ssl.html,v $