Secure Web Server for Tru64 UNIX
Administration Guide
Printed in the US
Published: December 2006
©Copyright 2006 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial
Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under
vendor'sstandard commercial license. The information contained herein is subject to change without notice. The only warranties for HP products
and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as
constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein..
UNIX isaregistered trademark of The Open Group
Table of Contents
About ThisDocument......................................................................................................... 9
1Intended Audience.................................................................................................................................. 9
2Document Organization.......................................................................................................................... 9
3Typographic Conventions........................................................................................................................ 9
4Related Information................................................................................................................................. 9
5HPEncouragesY our Comments ............................................................................................................. 10
1 Overview ....................................................................................................................... 11
1.1 Accessing the Secure Web Servers ........................................................................................................ 11
1.1.1 Choosinga Web Server ................................................................................................................ 12
1.1.1.1 Secure Web Server 1.3.......................................................................................................... 13
1.1.1.2 Secure Web Server 2.0.......................................................................................................... 13
1.1.1.3 Tomcat Java Servletand JavaServer Pages Container .............................................................. 14
1.1.2 Managing the Apache Web Servers ............................................................................................... 14
1.1.2.1 Migration Utilities for the Secure Web Server ........................................................................ 15
1.1.2.2 Tuning Tru64 UNIX for the Secure Web Server ...................................................................... 16
1.1.3 Managing the Administrator Password ......................................................................................... 16
1.2 WebServer Administration Functions .................................................................................................. 17
1.3 DynamicModules............................................................................................................................... 17
1.4 TomcatJava Servletand JavaServer Pages Container ............................................................................. 17
1.5 SSLandtheSecure Web Server............................................................................................................ 17
2 Managing the Secure Web Server ............................................................................ 19
2.1 ChangingConfiguration Parameters..................................................................................................... 19
2.1.1 Changing Server Tuning Parameters ............................................................................................. 21
2.1.2 Changing Access Control Entry Parameters .................................................................................. 22
2.1.3 Changing Listening Port and IP Address Parameters ..................................................................... 24
2.1.4 Changing Virtual Host Parameters for the Public Web Servers ........................................................ 25
2.1.5 Changing URL Default Parameters for the Public Web Servers ....................................................... 29
2.1.6 Changing HTML Directory Alias Parameters for the Public Web Server .......................................... 30
2.1.7 Changing CGI Directory Alias Parameters for the Public Web Server .............................................. 31
2.1.8 Changing Logging and Reporting Parameters ............................................................................... 31
2.2 ChangingPublic Web Server User Accounts ......................................................................................... 33
2.3 Displaying Public Web Server Status .................................................................................................... 34
2.4 Displaying Public Web Server Information ............................................................................................ 35
2.5 Viewing WebServer Reports and Log Files ........................................................................................... 35
2.6 Refreshing the Administration Web Server Log Files ............................................................................. 37
2.7 Startingand Stopping the Secure Web Server ........................................................................................ 37
2.8 Changingthe Password for the Administration Web Server ................................................................... 38
2.9 AllowingRemote Access to the Administration Web Server ................................................................... 38
2.10 Dynamically Adding and Removing Server Modules ........................................................................... 40
3UsingDynamic Modules ............................................................................................. 43
3.1 Secure WebServer Support for Apache Dynamic Modules ..................................................................... 43
3.1.1 Standard Modules Provided as DSO Modules ............................................................................... 43
3.1.2 Nonstandard Modules Provided as DSO Modules ......................................................................... 43
3.2 Activating the Apache DSO Modules ................................................................................................... 44
3.2.1 Usingthe LoadModule Directive .................................................................................................. 44
3.2.2 Usingthe AddModule Directive ................................................................................................... 44
3.2.3 Verifying the Configuration File ................................................................................................... 44
3.2.4 Activating an Apache DSO Module —Example............................................................................ 45
Table of Contents 3
4 Implementing the Tomcat Java Servletand JavaS erver Pages Container.............. 47
4.1 TomcatOverview................................................................................................................................ 47
4.2 Using Tomcatasa Standalone Public Web Server .................................................................................. 47
4.3 LocatingTomcat Directories ................................................................................................................. 48
4.4 Selectinga Java Environment ............................................................................................................... 48
4.5 StartingTomcat................................................................................................................................... 48
4.5.1 Starting and Stopping Tomcat from the Administration Utility ....................................................... 48
4.5.2 Restarting Tomcat ina Non-TruCluster Environment ..................................................................... 49
4.5.3 Restarting Tomcat ina TruCluster Environment ............................................................................ 49
4.5.4 TomcatLog Files......................................................................................................................... 50
4.6 Accessing the Tomcat Administration and Manager Applications .......................................................... 50
4.7 Accessing the Tomcat Examples ........................................................................................................... 51
4.8 LocatingAdditional Information .......................................................................................................... 51
5 Enabling the Secure Socket La yer Protocol ............................................................... 53
5.1 SSLConcepts...................................................................................................................................... 53
5.2 EnablingSSL Support from the Web Server Administration Utility ......................................................... 53
5.3 Generatinga Private Key ..................................................................................................................... 54
5.4 Generatinga Certificate Request .......................................................................................................... 55
5.5 Generating and Installinga Test Certificate ........................................................................................... 57
5.6 Installinga Digital Certificate ............................................................................................................... 58
5.7 ViewingCertificate Details .................................................................................................................. 59
5.8 Enablingand Disabling SSL fora Web Server ........................................................................................ 60
5.9 Testing YourSSL Connection ............................................................................................................... 61
5.10 Specifying Public Web Server Access to HTTP and HTTPS Connections ................................................ 61
5.11 Migrating Your Netscape Digital Certificate to the Secure Web Server ................................................... 62
5.11.1 Prerequisites for Migration ......................................................................................................... 62
5.11.2 Migrating the Netscape Digital Certificate ................................................................................... 62
AS ecureWebServer 1.3 Components and Modules ................................................ 65
BSecureWebServer 2.0 Components and Modules ................................................ 67
Glossary ............................................................................................................................ 69
Index ................................................................................................................................. 71
4
Table of Contents
List of Figures
1-1
Secure WebServer Main Menu ........................................................................................................... 12
1-2
Secure WebServer Administration Menu ............................................................................................ 12
2-1
Change Configuration Parameters Menu for Public Web Server 2.0....................................................... 20
2-2
Change Tuning Parameters Form ........................................................................................................ 21
2-3
Change Access Control Entries Form ................................................................................................... 22
2-4
Change Listening Ports and IP Addresses Form ................................................................................... 24
2-5
Change Public Web Server 1.3 Virtual Hosts Form ................................................................................ 25
2-6
Modify Public Web Server 1.3 Virtual Hosts Form ................................................................................ 26
2-7
Change Public Web Server URL Defaults Form .................................................................................... 29
2-8
Change Public Web Server HTML Directory Aliases Form .................................................................... 30
2-9
Change Public Web Server CGI Directory Aliases Form ........................................................................ 31
2-10
Change Public Web Server Logging and Reporting Parameters Form .................................................. 32
2-11
Manage the Public Web Server Form ................................................................................................. 34
2-12
Reports and Log Files for the Public Web Server ................................................................................ 35
2-13
Manage the Administration Web Server Menu ................................................................................... 36
2-14
Reports and Log Files for the Administration Web Server Menu ......................................................... 36
2-15
Start/Stop the Administration Web Server Form ................................................................................. 37
2-16
Change the Password for All Administration Servers Form ................................................................ 38
2-17
Change Administration Web Server Configuration Parameters Menu .................................................. 39
2-18
Modify Administration Web Server Access Control Entry Form .......................................................... 39
2-19
Dynamically Add/Remove Server Module Form ................................................................................ 41
4-1
Manage the Tomcat Java Servletand JSP Engine Form .......................................................................... 49
4-2
Start/Stop the Tomcat Java Servletand JSP Engine Form ....................................................................... 49
5-1
Manage SSLforthePublic Web Server Menu ....................................................................................... 54
5-2
Generatea Private Key —Results....................................................................................................... 55
5-3
Generatea Certificate Request Form .................................................................................................... 56
5-4
Certificate Request Success Notice ....................................................................................................... 57
5-5
Test Certificate Installation Success Notice ........................................................................................... 57
5-6
Manage SSLMain Menu with Additional Options ............................................................................... 58
5-7
Installa Certificate Text Field .............................................................................................................. 59
5-8
Certificate File in Readable Format ...................................................................................................... 60
5-9
Enable SSLConfirmation Page ............................................................................................................ 61
5-10
SSL Connections Error Message ........................................................................................................ 61
5
6
List of Tables
1-1
Command-Line Commands for Managing the Secure Web Server 1.3.................................................... 14
1-2
Command-Line Commands for Managing the Secure Web Server 2.0.................................................... 15
1-3
Command-Line Commands for Managing the Tomcat Web Server ........................................................ 15
2-1
Configuration Files for Secure Web Servers .......................................................................................... 19
2-2
Server Tuning Parameters and Associated Directives ............................................................................ 21
2-3
Access Control Parameters and Associated Directives .......................................................................... 23
2-4
Listening Port/IP Address Parameters and Associated Directives .......................................................... 25
2-5
Virtual Hosts Parameters and Associated Directives ............................................................................. 27
2-6
URL Default Parameters and Associated Directives .............................................................................. 30
2-7
HTML Directory Alias Parameters and Associated Directives ............................................................... 31
2-8
CGI Directory Alias Parameter and Associated Directive ...................................................................... 31
2-9
Logging and Reporting Parameters and Associated Directives .............................................................. 33
2-10
Activity Reports for the Secure Web Servers ...................................................................................... 36
4-1
Tomcat LogFiles................................................................................................................................ 50
A-1
Secure WebServer 1.3 Components ..................................................................................................... 65
A-2
Standard Secure Web Server 1.3 Modules ............................................................................................ 65
A-3
Secure WebServer 1.3-Related Modules ............................................................................................ 66
A-4
Additional Modules Provided with the Secure Web Server ................................................................... 66
B-1
Secure WebServer 2.0 Components ..................................................................................................... 67
B-2
Standard Secure Web Server 2.0 DSO Modules ..................................................................................... 67
B-3
Secure WebServer 2.0-Additional Modules ....................................................................................... 68
7
8
About ThisDocument
This document describes the administration tasks for configuring and managing the Secure Web Server
forT ru64 UNIX™ (powered by Apache).
1 Intended Audience
This document is intended for the system administrator who manages Internetservices on a Tru64 UNIX
AlphaServer system.
2 Document Organization
This document is organized as follows:
Chapter1
Provides an overview of the Secure Web Server.
Chapter2
Describes the general administration tasks for managinga Secure Web Server.
Chapter3
Explains how to implement dynamic modules.
Chapter4
Explains how to implement the Tomcat Java Servletand JSP Engine.
Chapter5
Describes how to enable the Secure Socket Layer (SSL) to provide secure Internet
connections toy our server.
Appendix A
Lists the Secure Web Server 1.3 components and modules.
AppendixB
Lists the Secure Web Server 2.0 components and modules.
This manual also containsa glossary and an index.
3TypographicConv en ti ons
This document uses the following typographical conventions:
%, $, or#
A percent sign represents the Cshellsystem prompt. A dollar sign represents the system
prompt for the Bourne, Korn, and POSIX shells. A number sign represents thesuperuser
prompt.
audit (5)
Amanpage. The manpagenameis audit , and it is located in Section 5.
Ctrl+x
A key sequence. A sequence such as Ctrl+x indicates that you must hold down the key
labeled Ctrl while you press another key or mouse button.
Key
The name of a keyboard key. Return and Enter both refer to the same key.
User input Commands and other text that you type.
Variable
The name of a placeholder in a command, function, or other syntax display that you
replace with an actual value.
4Related Information
Consult the following documentation for information on installing, configuring, and administering Internet
solutions on Tru64 UNIX operating systems.
Inter net Express Documentation
For information on installing, configuring, and administering Open Source and other Web server-related
software, seethe Documentation Bookshelf provided with HPInternet Express. (HP includes the Internet
Express CD-ROMs with Tru64 UNIX AlphaServer systems.)
•Reading documentation using the Administration utility:
After installation of the Secure Web Server subset (IAEAPCH), the Internet Express Documentation
subset (IAEDOC), and the Internet Express Administration utility (IAEADM subset), you can access
the Administration utility for Internet Express and read the documentation following the link from
theWebpageat:
1Intended Audience 9
http:// hostname.domain :8081.
•Reading documentation using the public Web server:
You can also read the documentation without the Administration utility using the public Web server
(ifyouchoseto configure one) to access the documentation index page at
http:// hostname.domain /documents/bookshelf.html. If this URL does not work, verify
that theW ebserver configuration file, /usr/internet/httpd/admin/conf/httpd.conf,
contains the following line:
Alias /documents/ "/usr/internet/docs/IASS/"
You can read the installed documentation directly from the file system usinga Web browser running
on the same system by using the file URL: file:/usr/intern et/docs/IASS/bookshelf.html.
•Reading documentation from the Internet Express Installation and Documentation CD-ROM:
You can access the Documentation Bookshelf on the Internet Express CD-ROM. The documentation
is available in the following formats:
—HTML
—PDF
Tru64 UNIXOperating System Documentation
The Documentation Overview describes the documentation that comes with the HPTru64 UNIX operating
system. The Tru64 UNIX documentation main page can be accessed from the following URL:
http://h30097.www3.hp.com/docs/
Tru64 UNIXB estPractices Documentation
Tru64 UNIXBest Practices describe specific tasks for Internetaswellas other topics. You can find these
documents at the following URL:
http://h30097.www3.hp.com/docs/best_practices/
5HPEncourages Your Comments
HP encourages your comments concerning this document. We are committed to providing documentation
that meets your needs. Send any errors found, suggestions for improvement, or compliments to:
feedback@fc.hp.com
Please include the following information along withy our comments:
•Thefulltitleof the document
•Thesection numbers and page numbers of the information on which you are commenting
•The versions of Tru64 UNIX and Internet Express that you are using
•If known, the type of processor that is running Tru64 UNIX
10
About ThisDocument
1 Overview
The SecureWeb Server (powered by Apache) is an implementation of the Apache Software Foundation's
(ASF) Apache HTTP server for Tru64 UNIX. It containsa packaged, integrated and tested version of many
of the popular components of the Apache Web server (mod_ssl, PHP, fastcgi, and others) and the modules
that are used with it. In addition, the Apache Software Foundation'sTomcatJavaServlet and JavaServer
Pages (JSP) are provided to handle Java based dynamic content.
Note:
For InternetExpress Version 6.0 and later, two versions of the Secure Web Server are offered: Secure Web
Server 1.3 (based on Apache Version 1.3) and the Secure Web Server 2.0 (based on Apache Version 2.0).
At installation, you can choose either version for the public Web server. (The Administration Web Server
continues touse the Secure Web Server 1.3.) See Section 1.1.1: Choosinga Web Server for more information.
The SecureWeb Server integrates other features beyond the core modules supplied by ASF, including:
•Supportfor Dynamic Shared Objects (DSO).
•Supportfor SSL connections (HTTPS) usinga DSO module.
•Supportfor APXS, which allows third party modules to be built against and used with an installed
Secure WebServer.
•Supportfor SUexec, once it is enabled in the server (an additional configuration is required to enable
it).
•Supportforthe Atallahardware accelerator cards.
•Supportforthe Tomcat Java Servletand Java Server Pages (JSP) container.
In addition, all modules provided with the Apache code base are built-in or provided as adynamic shared
object (DSO).
The SecureWeb Server provides a Web-based administration interface that allows an administrator to
perform common management tasks on the Web server. You access these administration pages from the
Web ServerAdministration utility (see Section 1.1: Accessing the Secure Web Servers ).
The SecureWeb Server is available on the Associated Products CD-ROM, included with the Tru64 UNIX
operating system distribution, and is also available with Internet Express for Tru64 UNIX. HP includes
theInternet Express CD-ROM with Tru64 UNIX AlphaServer systems. If you need the Internet Express
CD-ROM, you can contact your HP representative. The part number for the Internet Express product is
QB-3NCAA-SA. The Secure Web Server is also available for download from the HPW ebsite:
http://www.tru64unix.compaq.com/internet/
1.1 Accessing the Secure Web Servers
The SecureWeb Server provides the following servers for managing Internetservices:
•Public—The public Web server is an instance of the Secure Web Server, listening on Port 80, that
can be configured as a general purpose Web server and used by anyone. The installation procedure
lets you select this port for the Apache Version 2.0 or Apache Version 1.3. If you choose to install both
Apache versions for public Web servers, you can use Port 80 for one server instance only and must
select a different port for the other.
•Administration—The Administration Web Server is an instance of the Secure Web Server that listens
on Port 8081. It provides an administration interface for the Secure Web Servers accessible froma
Web browser.
The URLtakesthe form:
http:// host.domain.name : port
where host.domain.name represents the fully qualified host name of the local system (the system on
whichInternet Express is installed) and port represents the port Web server is listening on (either Port
80 or8081).
1.1 Accessing the Secure Web Servers
11
The Administration Web Server is initially accessible from the local system only. To allow access froma
remote system when running the Secure Web Server, see Section 2.9: Allowing Remote Access to the
Administration Web Server .
To access the Secure Web Servers, follow these steps:
1. From an HTML-based Web browser (such as Netscape Navigator Version 4.5 or later, Microsoft
Internet Explorer Version 4.0 or later, or Mozilla), enter the URL, including the proper port. When
you access the Administrationserv er, you are prompted fora user name and password.
2. Entera user name and password. The default user name for Web server administration is admin.
During installation, the system administrator sets a password to be used for the Web server
administration accounts. To change the password for the Administration Web Server, see Section 1.1.3:
Managing the Administrator Password . Figure 1-1 shows the Secure Web Server main menu when
you first log in.
Figure1-1 Secure Web Server Main Menu
When you choose Web Server Administration from the main menu, the Web Server Administration menu
is displayed, listing the available servers and providing a link for changing server passwords. Figure 1-2
shows theW eb Serv er Administration menu. In addition to the links for the Administration Web Server
and Public WebServer, when you install Apache Version 2.0, an additional link, Manage the Public Web
Server 2.0, is displayed.
Figure1-2 Secure Web Server Administration Menu
When you access the Web server, you are given access to privileged files and can perform system
management tasks until exiting the browser. Do not leave an administration session unattended. Limit
access to the admin account to those individuals authorized to perform Internetsystem management
tasks.
1.1.1 Choosinga Web Server
For InternetExpress Version 6.0 and later, you have the choice of installing any of three Web servers:
Apache Version 2.0, Apache Version 1.3, and a standalone Tomcat server.
12
Overview
Each Webserverhas strengths and weaknesses that you should evaluate prior to choosing which server
to install. It is possible to install all of the server options and configure them to respond to different ports.
If the port you choose is other than the default HTTP port (port 80), then you must include the port number
intheURLofthe request.
The following sections evaluate each of the Web server options.
1.1.1.1 Secure Web Server 1.3
The SecureWeb Server 1.3 is the traditional Web server powered by the Apache Version 1.3 code base.
This server has a long history of reliability and the largest selection of Apache modules (see Appendix A:
Secure WebServer 1.3 Components and Modules ).
Use this Webserverunder the following conditions:
•Youarerunning applications where the existing Web content depends on Apache modules that have
not been ported to the Apache Version 2.0 API.
•Youarerunningan older version of Apache Version 1.3 and you need to minimize transitional risks
(i.e., upgrading to anew er version of Apache).
The SecureWeb Server 1.3 offers the following strengths:
•The SecureWeb Server 1.3 offers a proven code base, and provides robust and fault tolerant service.
•Most Apachemodulesw ere written for the Apache Version 1.3 code base, therefore most existing
modules will work properly. As the Secure Web Server 1.3 is not multithreaded, it does not have
problems with modules that use libraries that are not thread safe.
•The PHPmodule provided in Apache Version 1.3 contains the most features.
•The SecureWeb Server 1.3 is easily configured to support SSL connections.
•The SecureWeb Server 1.3 is supported asa TruClustermulti-instance application.
The SecureWeb Server 1.3 has the following weaknesses:
•Itdoesnotsupport IPv6.
•The ApacheVersion 1.3 code base is no longer inactive development by the Apache Software
Foundation.
•JSPandJavaServlet requests must be forwarded to Tomcat.
1.1.1.2 Secure Web Server 2.0
The SecureWeb Server 2.0 is powered by the new Apache Version 2.0 code base. Apache Version 2.0 isa
major revision of the Apache code base that provides for running applications in a multithreaded
environment.
Use the Secure Web Server 2.0 for new installations where there are no dependencies on Apache modules
that are not yet available for the Apache Version 2.0 code base. (See Appendix B: Secure Web Server 2.0
Components and Modules fora list of the Apache Version 2.0 modules.)
Migrating existing Web servers based on Apache Version 1.3 to Apache Version 2.0 is normally a straight
forward process for most installations. The main configuration file, httpd.conf, requires very little
modification to work with the new Apache architecture. The major issue with migration is the availability
of Apache modules where a subset of modules do not yet support the Apache Version 2.0 API.
The SecureWeb Server 2.0 offers the following strengths:
•Thenewcodedesign uses threads and is intended to provide for more efficient delivery of content.
•The SecureWeb Server 2.0 supports IPv6.
•The ApacheSoftw are Foundation is actively dev eloping this code base.
•The SecureWeb Server 2.0 is easily configured to support SSL connections.
•The SecureWeb Server 2.0 is supported asa TruClustermulti-instance application.
The SecureWeb Server 2.0 has the following weaknesses:
•Existing Apache modules based on the Apache Version 1.3 API require porting to the new module
API. Currently, only a small number of modules have been ported. In addition, because Apache
Version 2.0 usesmultithreaded programming, all Apache modules (and the libraries they depend
on) must also be thread safe.
•The PHPmoduledoesnot include some features that are present in servers based on Apache Version
1.3 duetothread-safety issues of the libraries used by the optional features.
1.1 Accessing the Secure Web Servers
13
•JSPandJavaServlet requests must be forwarded to Tomcat.
•The SecureWeb Server 2.0 currently does not support FrontPage, and Auth_ldapextensions.
1.1.1.3 Tomcat Java Servletand JavaS erver Pages Container
The TomcatJava Servletand JavaServer Pages container (i.e., Tomcat server) was originally used as a
service for handling requests forwarded by another Web server. The current version of Tomcat isa
full-featured Web server. Choose the Tomcat server when your applications primarily supply Java-based
dynamic content in the form of Java Servletand JavaServer Pages (JSP) with the supporting static Web
content.
The Tomcatserverhas the following strengths:
•Itprovidesthe fastest handling of Java Servletand JSP requests.
•Whenusedwiththe Fast Java Virtual Machine and adequate resources, the Tomcat server provides
comparable performance to the Apache Web servers.
•Using the Tomcatserverstandalone provides significant improvements to response time, compared
to requests forwarded through an Apache Web server to Tomcat.
The Tomcatserverhas several weaknesses:
•Although traditional CGI and Server Side Includes (SSI) are supported (requires Java 1.3 or later),
they are disabled by default. Traditional CGI and Server Side Includes (SSI) are not considered
strengths ofTomcatandare recommended primarily for transitional use during the development of
aW ebapplication. CGI and SSI can bypass any Java-based security settings that are configured into
the Java Security Manager.
•The Tomcatserverdoes not support common Apache extensions such as PHP.
•Configuring Tomcat to support SSL connections is a complicated process, requiring installation and
configuration of Java components that are not included with this kit. Information on configuring
Tomcat to support SSL connections can be found at the Tomcat Web site:
http://jakarta.apache.org/tomcat
•The Tomcatserverruns as a single instance ina TruCluster.
•By default, the Tomcat server does not support running as anon-privileged user when listening on
privileged ports (less than 1024). This kit provides a program that allows Tomcat to avoid this
restriction, starting Tomcat as the root user, and then switching to an unprivileged user after opening
ports.
1.1.2 Managing the Apache Web Servers
All installed Web servers are configured to restart when the system reboots. It is also possible to start and
restart the serv ers from the command line.
You can configure the Web servers to make them disabled. A disabled Web server will not be started on
system reboot and will not start when the startup script is invoked. This feature allows a system
administrator to better manage the migration of the Secure Web Server from Version 1.3 to Version 2.0 by
configuring them touse the same ports while allowing only one version to run.
Table 1-1 lists the commands for managing the Secure Web Server 1.3.
Table1-1 Command-Line Commands for Managing the Secure Web Server 1.3
Command
Action
/sbin/init.d/httpd_public start
Start the server
/sbin/init.d/httpd_public stop
Stop the server
/sbin/init.d/httpd_public restart
Restart the server
/sbin/init.d/httpd_public cluster-start
Start the server on all Cluster
Members
/sbin/init.d/httpd_public cluster-stop
Stop the server on all Cluster
Members
/sbin/init.d/httpd_public cluster-restart
Restart the server on all Cluster
Members
14
Overview
Table1-1 Command-Line Commands for Managing the Secure Web Server 1.3 ( continued )
Command
Action
/sbin/rcmgr -c set APACHE1 ENABLE
Enable the server
sbin/rcmgr -c set APACHE1 DISABLE
Disable the server
/sbin/rcmgr -c get APACHE1
Check server status
Table 1-2 lists the commands for managing the Secure Web Server 2.0.
Table1-2 Command-Line Commands for Managing the Secure Web Server 2.0
Command
Action
/sbin/init.d/hpapache2 start
Start the server
/sbin/init.d/hpapache2 stop
Stop the server
/sbin/init.d/hpapache2 restart
Restart the server
/sbin/init.d/hpapache2 cluster-start
Start the server on all Cluster
Members
/sbin/init.d/hpapache2 cluster-stop
Stop the server on all Cluster
Members
/sbin/init.d/hpapache2 cluster-restart
Restart the server on all Cluster
Members
/sbin/rcmgr -c set APACHE2 ENABLE
Enable the server
/sbin/rcmgr -c set APACHE2 DISABLE
Disable the server
/sbin/rcmgr -c get APACHE2
Check server status
Table 1-3 lists the commands for managing the Tomcat Web server.
Table 1-3 Command-Line Commands for Managing the Tomcat Web Server
Command
Action
caa_start tomcat
Start the server in a TruCluster
environment
/sbin/init.d/tomcat start
Start the server
caa_stop tomcat
Stop the server in a TruCluster
environment
/sbin/init.d/tomcat stop
Stop the server
/sbin/rcmgr -c set TOMCAT ENABLE
Enable the server
/sbin/rcmgr -c set TOMCAT DISABLE
Disable the server
/sbin/rcmgr -c get TOMCAT
Check server status
1.1.2.1 Mig ration Utilities for the Secure Web Server
This section describes the following utilities for migrating theiPlanet Web Server to the HP Secure Web
Server for Tru64 UNIX:
•certmig—MigratesiPlanet 4.xcertificatesto the Secure Web Server. This utility, an extension of
thePK12UTIL utility provided by the Mozillacommunity, uses Network Security Services (NSS)
libraries to convertiPlanet certificates, key translations, and certificate chains to those of the Apache
Web Server.
•test_certmig.sh—Providesawrapper around certmigfor importing and extracting the list
certificates in aniPlanet 4.1.xCertificate database.
•mkcert.sh—Generates private keys, certificate signing requests, and certificates.
•cache_util.pl—Helps optimize file caching by reviewing the most commonly accessed files in
logs/access_log
and by creating a caching file list. This file caching utility is bundled with HP
Apache2.0.
1.1 Accessing the Secure Web Servers
15
1.1.2.2 Tuning Tru64 UNIX for the Secure Web Server
Proper system tuning can haveasignificant impact on the performance of the Secure Web Servers. The
Secure WebServersoftw are includes thekerneltuner
shell script that sets the primary tuning
recommendations for Internetserver performance. These recommendations are described in the Tuning
Tru64 UNIXfor Internet Services manual, available from the following URL:
http://h30097.www3.hp.com/docs/internet/TITLE.HTM
Additional system performance tuning settings are also described in this document.
Note:
Because Internetserver configurations differ, a recommended setting may not provide optimal performance
for all configurations. Carefully plan your Tru64 UNIX system performance tuning settings.
Thekerneltuner utility is installed in the bin subdirectory under the Web server root directory for
each Secure WebServer Public Web server. Run this utility as root. For example:
# su root
# cd /usr/opt/hpapache2/bin
# ./kerneltuner
The above example runs thekerneltuner utility in interactive mode. In this mode, the root user can
choose which system tuning recommendations will be configured. Optionally, a kerneltuner script can
configure all the system tuning recommendations without interaction from the user by running it with
the kerneltunerutilitywiththe-scommandlineoption:
# /usr/opt/hpapache2/bin/kerneltuner -s
You do not have to run the kerneltuner utility for each Secure Web Server you installed. Instead, run the
utility once on each system or TruClustermember where the Secure Web Server software is installed.
For the primary tuning settings to take effect, reboot your system. You can reboot the system after running
thekerneltuner utility, or you can wait fora more convenient time.
1.1.3 Managing the Administrator Pass word
During installation of the Secure Web Server, a single Web administration user is created for accessing all
Administration Web Server instances. Theusernameis admin. The administrator password is set to the
password that you entered during installation.
If you know the administrator password, you can change it using the Web Server Administration utility
( Section2.8: Changing the Password for the Administration Web Server ).
If you received y our Secure Web Server softwarepreinstalled from HP or if you have forgotten your
administrator password, the /usr/internet/httpd/bin/dbmmangecommand lets you create, view,
add, and update the contents of the Administrator user database.
To run the dbmanage command and change the administrator password, follow these steps:
1. Loginastheroot user, then run the following command:
# /usr/internet/httpd/bin/dbmmanage /usr/internet/httpd/userdb/admin adduser admin
2. Thedbmanage command initializes the database (if needed) and prompts you fora password for
Web user administrator, admin. If the user administrator already exists, the following message is
displayed:
Sorry user 'admin' already exists !
If you receive this message, rerun thedbmanage command as follows (note that adduserisnow
update):
# /usr/internet/httpd/bin/dbmmanage /usr/internet/httpd/userdb/admin update admin
16
Overview
The command promptsyoufora password and updates the database.
3. After updating the database, if the Administration Web Server is already running, you should not
have to restart it. If you need to restart the Administration Web Server, run the following command:
# sbin/init.d/httpd_admin restart
1.2 Web ServerAdministrati on Functions
All SecureWeb Server administration functions are performed using Port 8081. All activity is recorded in
the associated log files ( Section 2.5: Viewing Web Server Reports and Log Files ).
Management tasks available from the Secure Web Server administration menus include:
•Changing configuration parameters, including tuning parameters, access control entries, listening
ports and addresses, virtual hosts, URL defaults, HTML directory aliases, CGI directory aliases, and
logging and reporting parameters.
•Managing user accounts, displaying status, and viewing information for the public Web server
•Changing passwords for the Administration Web Server
•Allowing remote access to the Administration Web Server
•Viewing server activity reports, access log files, and error log files, and refreshing these files
•Starting and stopping the Secure Web Servers
These tasks are described in detail in Chapter 2 .
1.3 DynamicModules
Dynamic modules, also called Dynamic Shared Objects (DSO) or shared libraries, are loaded into the server
process space only when necessary to assure that overall memory usage is reduced. You can use DSO
modules to customize the Secure Web Server. Chapter 3 describes how to activate the Apache DSO modules.
Appendix A lists the standard Apache Version 1.3 modules and Appendix B lists the standard Apache
Version 2.0 modules provided with this release.
1.4 TomcatJava Servletand JavaS erver Pages Container
Tomcat, provided with the Secure Web Server, isa Java Servletand JavaServer Pages (JSP) container
developed by the Apache Software Foundation'sJakartaproject. The Tomcat engine is most commonly
used with commercial grade Web servers such as Apache and can also be used as a standalone Web server.
Tomcat is provided as an optional Secure Web Server subset that, when installed, allows the public instance
of the Secure Web Server to be configured to seamlessly pass requests for Java Servletand JSP pages to
the Tomcat container.
Chapter4 describes how to start Tomcat, use the Tomcat examples, and locate Tomcat directories and
files.
1.5 SSLandtheSecure Web Server
The SecureWeb Servers have built-in support for the Secure Socket Layer (SSL) on port 443. The HTTPS
protocol is the most widely-used method for performing secure transactions on the Web. The protocol is
supported by most Web servers and clients.
SSL providesprivacy, guaranteed through encryption. Although information can be intercepted by a third
party, the perpetrator cannot read the information without a private encryption key. If the information
received will not decrypt properly, the recipient can determine whether the information has been tampered
with during transmission.
SSL alsoprovides authentication through digital certificates that are generated for SSL, although the source
of digital certificates might not always be credible foronlinepayment transactions. Secure Web Server
SSL encryption uses a secret key nested within public key encryption and authenticated through digital
certificates.
Chapter5 describes the administration functions that you perform to enable SSL on your server:
1.2 WebServer Administration Functions 17
•Generatingapriv ate key.
•Generatinga request fora digital certificate.
•Generating and installing a test certificate, installing an actual certificate, and then viewing its details.
•Enabling (or disabling) SSL capabilities.
•Testing your SSL connection.
•Limiting access to HTTPS connections.
•Special considerations for enabling SSL on public Web servers.
18
Overview
2 Managing the Secure Web Server
This chapter describes the administration tasks available from the Web Server Administration utility that
allow you to manage the Secure Web servers.
Access the Web Server Administration utility by logging into the Administration Web Server that listens
on port 8081. The Secure Web Servers currently installed and managed by the administration utility are
listed on the top-level Web Server Administration form. When you install additional versions of the Secure
Web Server, they are added to the Web Server Administration form. Choosing a Web server on the Web
Server Administration form displays the administration tasks for that server. The administration tasks for
each Web server differ based upon the Web server version and the Web server type: administration or
public.
Administration tasks that apply only to the management of the Administration Web Server:
•Changethe password for the Administration Web Server ( Section 2.8: Changing the Password for
the Administration Web Server )
•Allow remote access to the Administration Web Server ( Section 2.9: Allowing Remote Access to the
Administration Web Server )
Administration tasks that apply only to management of the Public Web server:
•Display public Web server status ( Section 2.3: Displaying Public Web Server Status )
•Display public Web server information ( Section 2.4: Displaying Public Web Server Information )
•Dynamically add or remove server modules ( Section 2.10: Dynamically Adding and Removing Server
Modules )
Administration tasks that apply to both Administration and public Web servers:
•Change configuration parameters for the Secure Web Servers ( Section 2.1: Changing Configuration
Parameters )
•Change public Web server user accounts ( Section 2.2: Changing Public Web Server User Accounts )
•Viewserver activity reports or the access and error log files for the Web servers ( Section 2.5: Viewing
Web ServerReports and Log Files )
•Refreshtheaccess log and error log files for the Web servers ( Section 2.6: Refreshing the Administration
Web ServerLog Files )
•Startandstopthe Web servers ( Section 2.7: Starting and Stopping the Secure Web Server )
•Enableandmanage the Secure Socket Layer (SSL) with the Secure Web Server ( Chapter 5 ).
2.1 ChangingConfigurati on Parameters
A configuration parameter is specified by a directive and is stored in one of the configuration files listed
in Table 2-1 .
Table2-1 Configuration Files for Secure Web Servers
Configuration File
Server
/usr/internet/httpd/admin/conf/httpd.conf
Administration Web Server
/usr/opt/hpapache2/conf/httpd.conf
Public WebServer 2.0
/usr/internet/httpd/conf/httpd.conf
Public WebServer 1.3
You can specify the following types of configuration parameters:
•Server tuning parameters ( Section 2.1.1: Changing Server Tuning Parameters )
•Access control entries ( Section 2.1.2: Changing Access Control Entry Parameters )
•Listening ports and addresses ( Section 2.1.3: Changing Listening Port and IP Address Parameters )
•Virtual hosts ( Section 2.1.4: Changing Virtual Host Parameters for the Public Web Servers )
•URL defaults ( Section 2.1.5: Changing URL Default Parameters for the Public Web Servers )
•HTML directory aliases ( Section 2.1.6: Changing HTML Directory Alias Parameters for the Public
Web Server )
2.1 ChangingConfiguration Parameters 19
•CGI directory aliases ( Section 2.1.7: Changing CGI Directory Alias Parameters for the Public Web
Server )
•Loggingand reporting parameters ( Section 2.1.8: Changing Logging and Reporting Parameters )
Figure2-1 shows the menu for changing the configuration parameters for the Public Web Server 2.0.
Figure2-1 Change Configuration Par am eters Menu for Public Web Server 2.0
The SecureWeb Server configuration files are read in the following order:
•httpd.conf
•ssl.conf (Secure Web Server 2.0 only)
•srm.conf
•access.conf
Note:
By default, the access.conf andsrm.conf configuration files do not contain any directives. While they
remain supported in the Secure Web Server 1.3, all directives are defined inhttpd.conf. Directives either
exist in the httpd.conf file itself or are included in it by use of the Include directive.
If you specify the same directive in more than one configuration file, the first directive found takes
precedence.
In the tables in the following sections, a directive enclosed in angle brackets can be defined using multiple
lines and must be delimited bya <directive> ... </directive> pair, where directive is the directive
name. The following example shows the proper syntax fora multiple-line directive:
<Limit GET POST>
order deny,allow
deny from all
allow from host1.domain.namedomain2.name
</Limit>
Through the Change Configuration Parameters menu for each server, the Web Server Administration
utility allows you to set many of the frequently used configuration parameters described in this section.
If you want to take advantage of more specialized functionality, you must manually edit the Secure Web
Server configuration files listed in Table 2-1 . Avoid modifying the configuration parameters that are
handled by the Administration utility when manually editing these files.
20
Managing the Secure Web Server
Fora complete listing of configuration file directives, seethe Apache Web site for the appropriate directiv es
for theW ebserver version:
For the Secure Web Server 1.3:
http://www.apache.org/docs/mod/directives.html
For SecureWeb Server 2.0:
http://httpd.apache.org/docs-2.0/mod/directives. html
2.1.1 Changing Server Tuning Parameters
To change the serv er tuning parameters:
1. From the Web Server Administration menu, choose the link to the Web server that you want to
change. You can change the configuration parameters on either the Public or Administration Web
servers. For example, choose Manage the Public Web Server 2.0 to change the tuning parameters of
the Public Webserver 2.0.
2. From the Managethe Public Web Server 2.0 menu, choose Change Configuration Parameters.
3. From the Change Public Web Server 2.0 Configuration Parameters menu, choose Change Server
Tuning Parameters. Figure 2-2 shows the Change Tuning Parameters form for the Public Web server
2.0. A Change Tuning Parameters form is also available for the Public Web Server 1.3, but it has
different tuning parameters than the Public Web Server 2.0. A Change Tuning Parameters form is
also available for the Administration Web Server. (See Figure 2-13 .)
Figure2-2 Change Tuning Par ameters Form
4. On the Change Server Tuning Parameters form ( Figure 2-2 ), change one or more of the parameters.
Table 2-2 shows which Web Server directive is associated with each parameter field on the Change
Tuning Parameters form and the type of value expected. Parameters that apply only to Public Web
Server 2.0 are specified for 2.0 only.
Table2-2
Server Tuning Par ametersand Associated Directives
Description
Directive
Parameter
Minimum number of unused server child
processes to maintain
MinSpareServers number
Minimum Spare Servers
Maximum number of unused server child
processes left running before additional
child processes are killed
MaxSpareServers number
Maximum Spare Servers
2.1 ChangingConfiguration Parameters 21
Table2-2
Server Tuning Par ametersand Associated Directives ( continued )
Description
Directive
Parameter
Initial number of server child processes
StartServers number
Start Servers
Upper limit on configurable number of
processes
ServerLimit number
Server Limit (for 2.0 only)
Upper limit on the configurable number of
threads per child process
ThreadLimit number
Thread Limit (for 2.0 only)
Maximum number of server processes for
client connections
MaxClients number
Maximum Connections
Number of requests handled before child
process is terminated
MaxRequestsPerChild number
Maximum Requests/Connection
The number of threads created by each
server child process
ThreadsPerChild number
Threads PerChild (for 2.0 only)
Maximum number of idle threads
MaxSpareThreads number
Maximum Spare Threads (for 2.0 only)
Minimum number of idle threads available
to handle request spikes
MinSpareThreads number
Minimum Spare Threads (for 2.0 only)
Time (seconds) tow ait for response before
terminatinga connection
Timeout number
Connection Timeout (secs)
Whether or not to hold open a connection
after the initial connection is lost
KeepAliveon|off
Enable Keepalive
Time (seconds) tow ait for subsequent
connection ona KeepAlive connection
KeepAliveTimeout number
Keepalive Timeout (secs)
Number of times to reuse a connection
MaxKeepAliveRequests number
Maximum Keepalive Retries
2.1.2 Changing Access Control Entry Parameters
You can change access control entries for any of the installed Web Servers. The steps in this section describe
how to change the access control entry for the Public Web server 2.0. The steps are similar for the other
Web servers.
1. From the Change Public Web Server 2.0 Configuration Parameters form, choose Change Access
Control Entries. Figure 2-3 shows the Change Access Control Entries form for the Administration
Web Server. This form is also available for the Public Web servers.
Figure 2-3 Change Access Control Entries Form
2. By default, each Web server has one main access control entry controlling access to the document
root directory of the server. In general, this entry should be the only entry you might want to change,
though many access control entries are listed. The access control entries for each Web server'sdocument
root areas follows:
•/usr/internet/httpd/admin/htdocs (Administration Web Server)
•/usr/internet/httpd/htdocs (Public Web server 1.3).
•/usr/opt/hpapache2/htdocs (Public Web server 2.0)
22
Managing the Secure Web Server
You can also change access control entries for the following locations (for the public Web servers only):
•/server-status
•/server-info
You can add an access control entry fora directory or location you have created for the Web server.
Table 2-3 shows which Secure Web Server directive is associated with each parameter field on the Change
Access Control Entries form and the type of value expected.
Table 2-3 Access Control Par ametersand Associated Directives
Description
Directive
Parameter
path , name , and filename can contain
wildcards.
<Directory path >|
<Location name >|
<Files filename >
Type and Specification
Specify one of the following Limit Access
Methods:
•GET—Standard HTML access;
parameters can be passed as part of
theURL.
•POST—Form access; parameters are
passed separately.
•GET POST
•All Methods
Whenyouchoose All Methods (the
default), the Limit directive is not
specified in the access.conf file for this
Type and Specification (directory, location,
or file).
<Limit method >
Limit AccessMethods
Specifies the order in which to process the
deny fromandallow fromdirectives.
order1 deny,allow|
order allow, deny
Precedence
List of fully or partially qualified host or
domain names, separated by spaces. You
cannot use wildcards and you must use
completeDNS fields (for example,
domain.comdoesnotmatch
mydomain.com).
allowfrom1 all|
allow from host_list
Hosts Allowed Access
List of fully or partially qualified host or
domain names, separated by spaces. You
cannot use wildcards and you must use
completeDNS fields (for example,
domain.comdoesnotmatch
mydomain.com).
denyfrom1 all|
deny from host_list
Hosts DeniedAccess
To authenticate only specific users, set
User Authentication to For Selected Users,
and select one or more users from the
Selected Users list. (These users are
defined in the file specified by the
AuthDBMUserFile directive. To add a
user to this list, use the Change Web
Server UserAccounts form.)
To authenticate all users, set User
Authentication to For All Valid Users.
If no Webserver user accounts exist,
Authentication is disabled.
require user_list
User Authentication and Selected Users
Portion of the string displayed in the
Username/Password dialog box that
prompts for user name ("Enterusername
for name at host:port :").
AuthName string
Authentication Prompt Name
When the Enable CGI Script Execution
check box is selected, allows CGI scripts
to be executed from within the specified
directory.
Options ExecCGI2
CGI Execution
1
The Administration utility expects this directive to be defined within the context of the Limit directive.
2
The Administration utility expects this directive to be defined within the context of the Directory directive.
2.1 ChangingConfiguration Parameters 23
In the following example, the Limit directive allows access to the specified domains and hosts only:
<Limit GET POST>
order deny, allow
deny from all
allow from host1.domain1.namedomain2.name
</Limit>
In the following example, access is allowed to everyone except the specified hosts and domains:
<Limit GET POST>
order allow, deny
allow from all
deny from host1.domain1.namedomain2.name
</Limit>
2.1.3 Changing Listening Port and I PA ddress Parameters
Normally, aWebserver listens for HTTP requests on all known IP addresses on a system. The default (or
primary) port, port 80, is used for each address. The Change Listening Ports and Addresses form allows
you to limit the IP addresses and portsa Web server listens toby allowing you to enter specific addresses
and ports for the serv er. If your system has been configured to support the IPv6 protocol, IPv6 style
addresses can be entered in this form as well. However, IPv6 addresses can be used only with the Secure
Web Server2.0 public Web server. IPv6 style addresses should not be used in the Change Listening Ports
and Addresses form for the Secure Web Server 1.3.
From the Change Public Web Server 2.0 Configuration Parameters form ( Figure 2-1 ), choose Change
Listening Ports and Addresses. Figure 2-4 shows the Change Listening Ports and Addresses form for
Public WebServer 2.0. A similar form is also available from the Change Administration Web Server
Configuration Parameters form. (See Figure 2-13 .)
Figure2-4 Change Listening Ports and I PA ddresses Form
Table 2-4 shows which Secure Web Server directive is associated with each parameter field on the Change
Listening Ports and Addresses form and the type of value expected.
24
Managing the Secure Web Server
Table2-4 Listening Port/IPA ddress Par ametersand Associated Directives
Description
Directive
Parameter
Specifies one or more ports or IP addresses to listen
on
Listen [IP address:]port
Active IPAddress and Active
Port (Primary and Additional)
Defines the SERVER_PORT environment variable
used by CGIscripts.
Port port
Active IPAddress and Active
Port (Primary only)
For example, if your system has eight IP addresses configured, but you want the public Web server to
listen on only two of those ports, you can explicitly define these two addresses as the Active IP Addresses
for the server. Optionally, you can specifya different port for each address. (Port 80 is normally used.)
If you want to listen to all known IP addresses on more than one port (for example, Ports 80 and 81),
specify Active Port 80 and Active Port 81 and leave the Active IP Address field blank for both ports.
2.1.4 Changing Virtual Host Parameters for the Public Web Servers
You can specify virtual host parameters for the public Web servers only.
1. From the Change Configuration Parameters form for either the Public Web Server 1.3 or Public Web
Server 2.0 (for example, see Figure 2-1 ), choose Change Virtual Hosts. Figure 2-5 shows the Change
Public WebServer 1.3 Virtual Hosts form.
Figure 2-5 Change Public Web Server 1.3 Virtual Hosts Form
The first time you access the Change Virtual Hosts form ( Figure 2-5 ), the only choice is to add anew
virtual host. Thereafter, each virtual host you add is displayed on this form in the Existing Virtual
Hosts list box.
Note:
Before you create each virtual host, you must create a Listen directive in the Public Web Server for
the virtual host using the Change Listening Ports and Addresses form. If no Listen directive is specified
for the virtual host, the Public Web Server will not respond to client requests that match the host
names, IP addresses, and ports specified in its virtual host directives. See section Section 2.1.3: Changing
Listening Port and IP Address Parameters for information on creating Listen directives for the Public
Web Server.
To add anew virtual host:
a. Enter the host names and/or IP addresses (with optional port values) into the New Virtual Host
field on the form as they would appear inavirtualhost Web server directive.
b. Click on Add. The Add Public Web Server Virtual Host form is displayed. (This form is similar
to the Modify Public Web Server Virtual Host form in Figure 2-6 ).
c. Specify the type of virtual host (Name-based or IP-based) and any additionaldirectiv es for the
new virtual host:
2.1 ChangingConfiguration Parameters 25
When the value for the Virtual Host Name field matches the hostnamesand IP address
values you entered, a Name-based virtual host is created.
•
•Whenyousetthe value of the Virtual Host Name field to NONE, an IP-based virtual host
is created.
d. Click on Submittoaddthe new virtual host to the Public Web Server.
2. To change the configuration for an existing virtual host, select the virtual host from the list box and
click on Modify. The Modify Public Web Server Virtual Hosts form is displayed ( Figure 2-6 ).
Figure 2-6 Modify Public Web Server 1.3 Virtual Hosts Form
Table 2-5 shows which Secure Web Server directive is associated with each field on the Modify Public
Web ServerVirtual Hosts form ( Figure 2-6 ) and the type of value expected.
When afield on this form is left blank or when the"use default value"option is selected for the field, the
directive associated with the field is not included in (or removed from) the virtual host. In this case, the
virtual host inherits the value of the associated directive from the global-specified value of the directive
for the Public Web Server:
•Ifnoglobalvalue is specified for the associated directive, the directive'sdefaultvalueis used as the
value of the directive in the virtual host.
•Ifthedefault value for the directive is"unspecified" (for example, as with Script Alias), the directive
does not apply to the virtual host when the field in the form is left blank.
26
Managing the Secure Web Server
Table 2-5 Virtual Hosts Par ametersand Associated Directives
Description
Directive
Parameter
Name of the Name-based virtual host. When this
directive is not set to NONE, the value should
always match the Host Name or IP Address and
Port Numberofthe virtual host. Setting the value
to NONE creates an IP-based virtual host by not
setting the NameVirtualHost directive.
NameVirtualHost hostname[:port] | IP
address[:port]
Virtual HostName
Host name or IP address of the virtual host; port
number is optional.
VirtualHost hostname[:port] | IP
address[:port]
Host NameorIP
Address and Port
Number
The amount of time the server supporting the
virtual host will w ait for the following events: the
total amount of time it takes to receivea GET
request, the amount of time between receipt of
TCP packetsona POST or PUT request, the
amount of time betweenACKson transmissions
ofTCPpacketsin responses, the default value of
this directive is 300 second.
Timeout seconds
Connection Timeout
The number of seconds the server supporting the
virtual host will w ait fora subsequent request
before closing the connection. Once a request has
been received, the timeout value specified by the
Timeout directive applies.
Setting KeepAliveTimeout to a high value may
cause performance problems in heavily loaded
servers. The higher the timeout, the more server
processes will be kept occupied waiting on
connections with idle clients.
The default value of this directive is 15 seconds.
KeepAliveTimout seconds
Keepalive Timeout
Provides for long-lived HTTP sessions that allow
multiple requests to be sent over the same TCP
connection. These connection types are the default
forHTTP1.1 clients.
To enable KeepAlive connections, set KeepAlive
toOn.
The default value of this directive is On.
KeepAlive[On|Off |use default value]
Enable Keepalive
Limits the number of requests allowed on a
persistent connection (KeepAlive On) for the
virtual host.
The default value of this directive is 100.
MaxKeepAliveRequests number
Maximum KeepAlive
Retries
Configures thew ay the server serving the virtual
host determines its own name and port.
With UseCanonicalName set to On, the server will
use the hostname and port specified in the Server
Name directive. With UseCanonicalName set to
Off, the server will form self-referential URLs
using the hostname and port supplied by the
clients Host: header. Set UseCanonicalName to
DNS forusewith mass IP-based virtual hosting
when you need to support older client systems
that do not provide a Host: header.
The default value for this directive is On.
UseCanonicalName[On|Off|DNS|use default
value]
Use Canonical Name
Host name; used in URL parsing.
ServerName hostname
Server Name
Sets the alternate names for the virtual host.
ServerAlias hostname [ hostname ]...
Server Alias
Full path of the directory containing the default
Webhomepagefor the specified Host Name or IP
Address.
The default value for this directive is
/usr/local/apache/htdocs.
DocumentRoot path
Document Root
2.1 ChangingConfiguration Parameters 27
Table 2-5 Virtual Hosts Par ametersand Associated Directives ( continued )
Description
Directive
Parameter
Dynamically configures the location of the
document root fora given virtual host based on
the value of server name. If interpolated-directory
is set to none, then VirtualDocumentRoot is
turned off. This directive cannot be used in the
same context as the VirtualDocumentRootIP
directive.
This directive applies only to the Secure Web
Server 2.0.
VirtualDocumentRoot interpolated-directory
Virtual Document Root
Dynamically configures the location of the
document root fora given virtual host based on
the value of the serv er IP address. If
interpolated-directory is set to none, then
VirtualDocumentRootIP is turned off. This
directive cannot be used in the same context as
the VirtualDocumentRoot.
This directive applies only to the Secure Web
Server 2.0.
VirtualDocumentRootIP interpolated-directory
Virtual Document Root
IP
Allows CGIscripts to be stored in the local file
system other than under the Document Root. URLs
witha (%-decoded) path beginning with URL-path
will be mapped to local files beginning with the
second argument, which is a full pathname on the
local file system.
ScriptAlias URL-path file-path|
directory-path
Script Alias
Dynamically configures the location of the CGI
directory fora given virtual host based on the
value of the server name. If interpolated-directory
is set to none then VirtualScriptAlias is turned
off. This directive cannot be used in the same
context as the VirtualScriptAlia sIP directive.
This directive applies only to the Secure Web
Server 2.0.
VirtualScriptAlias interpolated-directory |
none
Virtual Script Alias
Dynamically configures the location of the CGI
directory fora given virtual host based on the
value of the server IP address. If
interpolated-directory is set to none then
VirtualScriptAlia sIP is turned off. This directive
cannot be used in the same context as the
VirtualScriptAlias directive.
This directive applies only to the Secure Web
Server 2.0.
VirtualScriptAlia sIP interpolated-directory |
none
Virtual Script Alias IP
E-mail address of the Web system administrator.
ServerAdmin e-mail address
Server AdminMail
Address
Adjusts the verbosity of the messages recorded in
the ErrorLogfile for the virtual host. When set to
use default value, the LogLevel directive is not set
for the virtual host, and the value is inherited from
the global server value.
The default value of this directive is warn.
LogLevelemerg | alert | crit | error |
warn | notice | info | debug | use
default value
Log Level
Full or relative path to error log file. Relative paths
are specified from the Web server'srootdirectory.
The default value of this directive is
logs/error_log
.
ErrorLog path
Error Log
28
Managing the Secure Web Server
Table 2-5 Virtual Hosts Par ametersand Associated Directives ( continued )
Description
Directive
Parameter
The LogFormat directive can take one of two
forms. In the first form, where only one argument
is specified, this directive sets the log format that
will be used by logs specified in subsequent
TransferLogdirectiv es.
The second form of the LogFormat directive
associates an explicit format with a nickname. This
nickname can then be used in subsequent
CustomLogdirectiv es. When a nickname is
specified, this directive does not affect subsequent
TransferLogdirectiv es.
The default value of this directive is"%h%l%u
%t"%r"+.
LogFormat format |nickname[ nickname ]
Log Format
Full or relative path of the transfer (access) log file.
Relative paths are specified from the Web server
root directory.
TransferLog path
Transfer Log
Full or relative path and format of a log file for the
virtual host. Relative paths are specified from the
Web server root directory.
CustomLog path
Custom Log
Fora comprehensive document on virtual host support, seethe following Web sites:
http://www.apache.org/docs/vhosts/index.html (for Secure Web Server 1.3)
http://httpd.apache.org/docs-2.0/vhosts (for Secure Web Server 2.0)
2.1.5 Changing URL De fault Parameters for the Public Web Servers
This section describes the steps to change the URL Default Parameters for Public Web Server 1.3. The steps
for Public WebServer 2.0 are similar. You can specify the URL default parameters for the public Web
server only.
1. From the Change Public Web Server 1.3 Configuration Parameters form ( Figure 2-1 ), choose Change
URL Defaults. Figure 2-7 shows the Change Public Web Server 1.3 URL Defaults form.
Figure2-7 Change Public Web Server URL Defaults Form
2. From the Change Public Web Server URL Defaults form ( Figure 2-7 ), specify the default HTML
directory and defaulthomepage (index page) for users on your system. By convention, the default
HTML directory is public_html
and the default homepage is index.htmlon UNIX systems.
When the Recognize.cgi Files As CGI Scripts parameter is enabled, files with the .cgiextensionin the
user'sdefault HTML directory (or in a directory where CGI script execution is enabled) are executed as
CGI scripts.
Table 2-6 shows which Secure Web Server directive is associated with each field on the Change URL
Defaults form and the type of value expected.
2.1 ChangingConfiguration Parameters 29
Table 2-6 URLDefault Parameters and Associated Directives
Description
Directive
Parameter
Path relative toauser'shomedirectory for the user's
HTML homedirectory. The default is public_html.
UserDir path
User'sHTMLHome Directory
One or more file names, separated by spaces, that
define the default page displayed when an HTTP
request specifiesa directory path only (withoutafile
name).
DirectoryIndex filename list
Directory Index Page Name
When this field is enabled, the comment character
in this line is remov ed from thehttpd.conf file.
When this field is disabled, the line is commented
out.
AddHandlercgi-script.cgi
Recognize.cgi Files As CGI
Scripts
2.1.6 Changing HTML Directory Alias Parameters for the Public Web Server
You can specify the HTML Directory Alias parameters for the public Web servers only. This section
describes the steps to change the HTML Directory Aliases for the Public Web server 1.3. The steps are
similar for the Public Web server 2.0.
From the Change Public Web Server 1.3 Configuration Parameters form ( Figure 2-1 ), choose Change HTML
Directory Aliases. Figure 2-8 shows the Change Public Web Server 1.3 HTML Directory Aliases form.
Figure 2-8 Change Public Web Server HTML Directory Aliases Form
URL pathsarerooted only by aliases, not by actual directories. The system-defined aliases areas follows:
•icons—Defines the directory to search for browser-specific icons.
When an HTTPrequest specifiesa directory other than the user'sHTMLhome directory ( Table 2-6 ),
the icons used in the resulting display to identify subdirectories and files are obtained from the
directory associated with the icons alias.
•copyrights—Defines the directory in which the copyright information is installed.
•documents—Defines the directory in which the book files are installed.
Normally, these aliases should not be changed or deleted. However, you can specify anew HTML alias
for any directory by providing an alias name and the full path name of the directory you want to associate
with the alias.
To add anew HTML alias:
1. On the Change HTML Directory Aliases form, enter the new alias name in the New Alias Name field
and click on Add.
2. On the AddHTML Directory Aliases form, specify the full pathnamefor the directory associated
with the new alias in the Actual Directory field.
3. Click on Submit.
The WebServer Administration utility displaysa confirmation message indicating that the
configuration file has been successfully updated.
4. Click on Submittohavethe public Web server on the indicated port reread its configuration file.
Wait a few seconds before using the navigation bar.
30
Managing the Secure Web Server
When you determine that an alias is no longer useful, you can remove it by selecting the alias name from
the Existing Alias Names list box and clicking on Delete.
Table 2-7 shows which Secure Web Server directive is associated with each field on the Change Public
Web ServerHTML Directory Aliases form and the type of value expected.
Table2-7 HTML Directory Alias Par ametersand Associated Directives
Description
Directive
Parameter
Alias Specification (New Alias Name) specifies the alias part of
the directive and Actual Directory specifies the path .
Alias alias path
Alias Specification and Actual
Directory
2.1.7 Changing CGI Directory Alias Parameters for the Public Web Server
You can specify the CGI Directory Alias configuration parameters for the public Web server only.
1. From the Change Public Web Server Configuration Parameters form ( Figure 2-1 ), choose Change
CGI Directory Aliases. Figure 2-9 shows the Change Public Web Server 1.3 CGI Directory Aliases
form.
Figure 2-9 Change Public Web Server CGI Directory Aliases Form
2. Specify an alias name and the full path name of the directory you want to associate with the alias.
Table 2-8 shows which Secure Web Server directive is associated with each field on the Change Public
Web ServerCGI Directory Aliases form ( Figure 2-9 ) and the type of value expected.
Table 2-8 CGIDirectory Alias Par ameterand Associated Directive
Description
Directive
Parameter
Alias Specification (New Alias Name) specifies the
alias part of the directive and Actual Directory
specifies the path .
ScriptAlias alias path
Alias Specification and Actual
Directory
2.1.8 Changing Logging and Reporting Parameters
Use the Change Logging and Reporting Parameters form to specify the following:
•Thehostname associated with an IP address in the log file. (Server performance can decrease when
you enable host name lookup.)
•E-mail address for mail intended for the server administrator (if not specified anywhere else in the
configuration files).
•The URLofthe HTML page to display when the browser receives any of the following error codes:
Note:
Although both servers are capable of generating the following errors, the Change Logging and
Reporting Parameters form for different versions of the Secure Web Server display different lists of
errors. Errors that appear only in the Secure Web Server 2.0 Change Logging and Reporting Parameters
form are specified for Version 2.0 only.
2.1 ChangingConfiguration Parameters 31
—Bad Gateway—The server, when acting as a gateway or proxy, received an invalid response
from a server (Version 2.0 only).
—Bad Request—Usually caused by a malformed URL (Version 2.0 only).
—Unauthorized—Usually caused by an incorrect user name or password.
—Forbidden—Access to the directory, location, or file is explicitly prohibited or the file is protected.
—File NotFound—File or path name alias does not exist.
—Gone—The requested resource is no longer available at the server (Version 2.0 only).
—Method No tAllowed—File or path name alias does not exist (Version 2.0 only).
—Not Implemented—The server does not support the functionality required to fulfill the request
(Version2.0 only).
—Precondition Failed—The preconditiongiv en in one or more of the request-header fields
evaluated to false (Version 2.0 only).
—Request Timeout—The client did not produce a request within the time that the server was
prepared tow ait (Version 2.0 only).
—Request Entity Too Large—The request entity is larger than the server is willing or able to
process (Version 2.0 only).
—Service Unavailable—The server is temporarily overloaded or maintenance is required (Version
2.0 only).
—Server Error—Usually caused by a malformed HTTP header generated bya CGI script.
—Variant Also Varies—The HTTP variant also varies; the status is not yet defined. (Version 2.0
only).
From the Change Public Web Server 2.0 Configuration Parameters form ( Figure 2-1 ), choose Change
Logging and Reporting Parameters.
Figure2-10 shows the Change Logging and Reporting Parameters form for the Public Web Server 2.0. The
form for the Public Web Server 1.3 is has fewer server responses. (See Table 2-9 .) This form is also available
for the Administration Web Server.
Figure2-10 Change Public Web Server Logging and Reporting Par am eters Form
Table 2-9 shows which Secure Web Server directive is associated with each field on the Change Logging
and Reporting form ( Figure 2-10 ) and the type of value expected.
32
Managing the Secure Web Server
Table 2-9 Logging and Reporting Par ametersand Associated Directives
Description
Directive
Parameter
When set toon, the server performs
DNS lookupsonIP addresses to
include host names in logging records.
HostnameLookups on|off
Enable Hostname Lookups
E-mail address displayed with some
error pages.
ServerAdmin e-mail address
Server AdminMail Address
Specifies a page or text string to
display upon receivinga"bad
password"error. If specified, the URL
for 401errorsmustbe local. (The
http://host.domain.name prefix
is not permitted.)
ErrorDocument 401 URL | string
"Unauthorized"Error Response URL
Specifies a page or string to display
upon receivinga"no authorization"
or"file access"error.
ErrorDocument 403 URL | string
"Forbidden"Error Response URL
Specifies a page or text string to
display upon receivinga"file not
found"error.
ErrorDocument 404 URL | string
"File NotFound"Error Response URL
Specifies a page or text string to
display upon receiving an internal
error or CGIformat error (most likely
related to a problem with HTTP
header information).
ErrorDocument 500 URL | string
"Server Error"Error Response URL
2.2 ChangingPublic Web Server User Accounts
You can establish Secure Web Server user accounts to control access to the public Web servers. You can
enable a different level of access to each combination of user name and password that you specify. The
password you specify fora Web server user account is nota UNIX system password; that is, you will not
find these passwords in the /etc/passwdfile.
The first time you access the Change Web Server User Accounts menu, the only option is to add anew
Web server user account. Thereafter, each user account you create is displayed on this menu in the Existing
Web ServerUsers list box, allowing you to change the password for the account or delete the account.
To add a Webserveruser account to control access to the public Web server:
1. On the WebServer Administration menu, choose the public Web ser veryouwantto manage.
Figure2-11 shows the Manage the Public Web Server 1.3 menu and available options.
2.2 ChangingPublic Web Server User Accounts
33
Figure2-11 Manage the Public Web Server Form
2. From the Managethe Public Web Server 1.3 menu, choose Change Web Server User Accounts.
3. On the Change Public Web Server User Accounts form, enter the account name in the New Web
Server Userfield.
4. Click on Add. The Add Public Web Server User Account form is displayed.
5. Entera password in the New Password field.
6. Verify the password for the user by typing the same password in the Verify Password field.
7. Click on Submit.
The WebServer Administration utility displaysa confirmation message indicating that the new user
account has been successfully created. You can use the navigation bar at the top of the page to return
to the Change Public Web Server User Accounts form.
To change a user'spassword, select the user name from the Existing Web Server Users list box and click
on Modify. Specify anew password, verify the password, and click on Submit.
To delete a user account, select the user name from the Existing Web Server Users list box and click on
Delete.
2.3 Displaying Public Web Server Status
To display the status of Public Web Server 1.3, from the Manage the Public Web Server 1.3 menu, choose
Display WebServer Status. Similarly, to display the status of Public Web Server 2.0, from the Manage the
Public WebServer 2.0 menu, choose Display Web Server Status.
The WebServer Status page allows you to see how welly our server is performing. The current server
statistics are displayed in an easy-to-read form.
The DisplayServer Status and Display Server Information links under the Manage the Public Web Server
menu return a"Forbidden server"error if you try to access them fromaremote Web browser after opening
up access controls to remote systems on the Administrationserv er. To avoid this problem, open access
controls on the Location/server-info
and Location/server-status entries for the public Web
server in the Change Access Control Entries form under Change Configuration Parameters.
For more information on the data displayed on the Web Server Status page, go to one of the following
Apache Website URLs:
http://www.apache.org/docs/mod/mod_status.html (for Secure Web Server 1.3)
http://httpd.apache.org/docs-2.0/mod/mod_status. html (for Secure Web Server 2.0)
34
Managing the Secure Web Server
2.4 Displaying Public Web Server Information
To display information for the public Web server, on the Manage the Pubic Web Server menu (1.3 or 2.0),
choose Display Web Server Information.
The WebServer Information page displaysa comprehensive overview of the server configuration, including
all installed modules and directives in the configuration files.
The DisplayServer Status and Display Server Information links under the Manage the Public Web Server
menu return a"Forbidden server"error if you try to access them fromaremote Web browser after opening
up access controls to remote systems on the Administrationserv er. To avoid this problem, open access
controls on the Location/server-info
and Location/server-status entries for the public Web
server in the Change Access Control Entries form under Change Configuration Parameters.
For more information on the data displayed on the Web Server Information page, go to one of the following
Apache Website URLs:
http://www.apache.org/docs/mod/mod_status.html (for Secure Web Server 1.3)
http://httpd.apache.org/docs-2.0/mod/mod_status. html (for Secure Web Server 2.0)
2.5 Viewing WebS erver Reports and Log Files
During its normal operation, the Web server puts information in two log files. The access log keeps track
of requests for use of this server and the information requested. The error log maintains a record of errors
that occurred since the log file was last refreshed. You should periodically save and recreate these log files
so they do not get too large. See Section 2.6: Refreshing the Administration Web Server Log Files .
To view the access log file or error log file fora Web server:
1. From the Web Server Administration menu, choose the Manage form for the version of the server
whose logy ouwant to view (for example, the Public Web Server 1.3). In this case, the Manage the
Public WebServer 1.3 menu is displayed. See Figure 2-11 .
2. From the Managethe Public Web Server 1.3 menu, choose View Server Reports and Log Files. The
Report and Log Files for the Public Web Server 1.3 menu is displayed ( Figure 2-12 ).
Figure2-12 Reports and Log Files for the Public Web Server
3. Choose the item corresponding to the log file you want to view.
The entries in the chosen log file are shown 100 lines at a time with the most recent entries first. You
can use the navigation bar at the top of each page to return to the Report and Log Files menu.
To generate the activity reports for anyone of the Web Server instances:
1. From the Web Server Administration menu, choose the server for which you want to generate activity
statistics; for example, the Administration Web Server. The Manage the Administration Web Server
menu is displayed ( Figure 2-13 ).
2.4 Displaying Public Web Server Information
35
Figure2-13 Manage the Administration Web Server Menu
2. From the Managethe Administration Web Server menu, choose View Server Reports and Log Files.
The Reportand Log Files for the Administration Web Server menu is displayed ( Figure 2-14 ). This
menu contains more reports than listed on the Reports and Log Files for the Public Web Server menu.
Figure2-14 Reports and Log Files for the Administration Web Server Menu
3. From the Reports and Log Files for the Administration Web Server menu, click on Generatea Summary
Report.
For your convenience, a link to the Analog HTML documentation is also provided at the bottom of
the page; look for This analysis was produced by analogx.xx, where x.xx indicatesthe
version number.
The activity reports are generated using analog, an Open Source utility that analyzes log files. The
analog configuration file is located in /usr/internet/httpd/admin/analog/analog.cfg.
Table 2-10 describes the various activity reports that you can generate for the public and administration
instances of the Secure Web Server:
Table2-10 Activity Reports for the Secure Web Servers
Description
Report
For the time period shown at the top of the page, the following statistics are shown: the total requests that
were completed, failed, and redirected; the number of distinct hosts served; the number of corrupt log file
entries; and the total bytes transferred.
Summary Report
Shows how many requests were processed by month.
Monthly Report
Shows how many requests were processed each day since the last time the server was started.
Daily Summary
Report
Shows how many requests were processed each hour.
Hourly Summary
Report
36
Managing the Secure Web Server
Table2-10 Activity Reports for the Secure Web Servers ( continued )
Description
Report
Shows all domains with any traffic, sorted by amount of traffic.
Domain Report
Shows all directories to depth 1 with at least 0.01%of the traffic, sorted by amount of traffic.
Directory Report
For more information, visit the analog Web site:
http://www.analog.cx
2.6 Refreshing the Administration Web Server Log Files
To refresh the access log, the error log, or both, follow these steps:
1. From the Secure Web Server Administration menu, choose the server for which you want to refresh
the log files; for example, the Administration Web Server. The Manage the Administration Web Server
menu is displayed. (See Figure 2-13 .)
2. From the Managethe Administration Web Server menu, choose Refresh Server Log Files.
3. On the Refresh Server Log Files form, select the check box corresponding to the log file you want to
refresh. You can select one file or more files.
4. Click on Submit.
For each log file you select, the Web Server Administration utility makes a backup copy of the log
file and creates an empty file to replace it. The Web Server Administration utility also restarts the
httpdserver daemon.
2.7 Startingand Stopping the Secure Web Server
To stop or restart the Secure Web Server instances:
1. From the Web Server Administration menu, choose the ser veryouwantto start or stop; for example,
the Administration Web Server. The Manage the Administration Web Server menu is displayed
( Figure2-13 ).
2. From the Managethe Administration Web Server menu, choose Start/Stop the Administration Web
Server.
If the server is running, the Web Server Administration utility shows you the current status of the
server and offers the following operations:
•Stop—Shuts down the server daemon listening on the port shown in the title of the form. Use
this operation to prevent the server from responding to requests.
•Restart—Restarts the server daemon listening on the port shown in the title of the form. Use
this operation to enable any change to the server configuration files.
Figure2-15 shows the Start/Stop the Administration Web Server form when the server is running.
Figure2-15 Start/Stop the Administration Web Server Form
If the server is not running, the utility offers the following control operations:
2.6 Refreshing the Administration Web Server Log Files 37
•Start—Starts the server daemon listening on the port shown in the title of the form.
•Restart—Stops and restarts the server daemon listening on the port shown in the title of the
form. Use this operation to enable any change to the server configuration files.
3. Click on the button corresponding to the operation you want to perform. The Web Server
Administration utility confirms the request and performs the operation.
The Start/Stop form for Public Web Server 1.3 or Public Web Server 2.0 offers the following additional
control operation:
Save Options—Saves the Web server daemon command line options. The options are displayed in the
text field labeled"Start with options"in the Start/Stop form. Changing the options displayed in the"Start
with options"text field changes the options that will be saved. These options take affect the next time the
Web server is started. Clicking on the Start or Restart button in the form also saves the displayed options.
2.8 Changingthe Pass word for the Administration Web Server
To change the password used for the Administration Web Server:
1. From the Web Server Administration menu, choose Change the Password for All Administration
Servers. The Change the Password for All Administration Servers form is displayed ( Figure 2-16 ).
Figure2-16 Chang et he Password for All Administration Servers Form
2. Enter the new password in the New Password field and again in the Verify New Password field.
3. Click on Submit. The new password takes effect immediately.
If you decide not to change the password, cancel the operation by clicking on one of the following:
•The Clearbuttonatthe bottom of the form
•Oneofthelinkson the navigation bar at the top of the form togo to another Administration menu
2.9 AllowingRemote Access to the Administration Web Server
The installation procedure installs the Administration Web Server on port 8081 and initially allows access
to the server from the local system only.
Note:
Usinga Webserverona remote system to manage user accounts and other system services poses a security
risk. That is, unless the Secure Socket Layer (SSL) is enabled on your Web server, all data, including
passwords, is transmitted between the Web server and the browser in clear text. Thisunencrypted data
is subject to interception by network snooping.
Carefully evaluate the security risks toy our system before you enable remote access to the Administration
utility or other serv er administration. See Chapter 5 for information on setting up your Web server with
SSL.
To allow access to the Administration Web Server from remote systems:
38
Managing the Secure Web Server
1. From the Web Server Administration menu, choose Manage the Administration Web Server. The
Manage the Administration Web Server menu is displayed ( Figure 2-13 ).
2. From the Managethe Administration Web Server menu, choose Change Configuration Parameters.
The ChangeAdministration Web Server Configuration Parameters menu is displayed ( Figure 2-17 ).
Figure2-17 Change Administration Web Server Configuration Par am eters Menu
3. From the Change Administration Web Server Configuration Parameters menu, choose Change Access
Control Entries ( Figure 2-3 ).
4. On the Change Access Control Entries menu, select Directory
/usr/internet/httpd/admin/htdocsfromthe Existing Access Control Entries list box, then
click on Modify. The Modify Administration Web Server Access Control Entry form is displayed
( Figure2-18 ).
Figure2-18 Modify Administration Web Server Access Control Entry Form
2.9 AllowingRemote Access to the Administration Web Server
39
5. In the Hosts Allowed Access field, enter one of the following:
• host.domain.name fora specific host
• .domain.name fora specific domain
•allforanyremote host
For more information on the Allow command, seethe Apache documentation at the following Web
site:
http://www.apache.org/
6. Click on Submit.
The WebServer Administration utility displaysa confirmation message.
7. On the confirmation page, click on Submit to reload the Administration Web Server configuration
file.
2.10 Dynamically Adding and Re moving Server Modules
This section describes how to dynamically add or remove server modules. Appendix A lists the standard
Apache Version 1.3 modules and Appendix B lists the standard Apache Version 2.0 modules provided
with this release.
To dynamically add or remove server modules, follow these steps:
1. From the Secure Web Server Administration menu, choose the server for which you want to refresh
the log files; for example, the Administration Web Server. The Manage the Administration Web Server
menu is displayed. (See Figure 2-13 .)
2. From the Managethe Administration Web Server menu, choose Manage Public Web Server 2.0.
3. On the Manage Public Web Server page, choose Dynamically Add/Remove Server Modules.
A form ( Figure 2-19 ) is displayed that shows the available server modules.
40
Managing the Secure Web Server
Figure2-19 Dynamically Add/Remove Server Module Form
4. To add a server module, check in the corresponding check box. To removeasever module, uncheck
the corresponding check box.
5. Click on Submit.
Not all modules can be added or removed. If the add/remove operation reports an error, check the module
error log.
2.10 Dynamically Adding and Removing Server Modules
41
42
3UsingDynamic Modules
Dynamic modules provide a means of allowing developers and third parties to extend the capabilities of
the Secure WebServer. When properly configured in the server configuration file, these modules will be
loaded into theW ebserv erat startup time. As the Secure Web Server is powered by Apache, modules
conforming to the Apache DSOAPI can be use with the Secure Web Server.
The SecureWeb Server can be customized using dynamic modules provided from Apache and other
sources. Fora complete list of the Secure Web Server 1.3 modules (DSO and integrated), see Appendix A .
See Appendix B fora complete list of the Secure Web Server 2.0 modules.
This chapter provides the following information:
•Secure WebServersupport for dynamic modules ( Section 3.1: Secure Web Server Support for Apache
Dynamic Modules ).
•Activating the Apache dynamic modules ( Section 3.2: Activating the Apache DSO Modules ).
3.1 Secure WebS erver Support for Apache Dynamic Modules
Apache dynamic modules can be obtained from many sources. These include:
•Modules that are part of the Apache distribution.
•Modules from the Apache Module Register on the Web: http://modules.apache.org . The Module
registry contains alist of modules that are available for use with Apache based servers. These modules
derive from a variety of sources, and can often be easily built and used with the Secure Web Server.
•Custom-written modules from various sources. Occasionally, aWebsitehas special needs that cannot
be easily addressed using the existing Secure Web Server functionality of and are not readily available
from existing modules. In these cases, aWebsitecan create custom modules based on the Apache
DSOAPI thatextends the functionality of the Secure Web Server.
The SecureWeb Server integrates many Apache modules and provides many other modules as dynamic
shared objects (DSO). The DSO modules are not integrated because they are not usually part of the default
configuration of an Apache server. Section 3.1.1: Standard Modules Provided as DSO Modules lists the
standard Apache modules provided as DSO modules. Section 3.1.2: Nonstandard Modules Provided as
DSO Modules lists nonstandard DSO modules provided in the Secure Web Server kit. (Nonstandard DSO
modules are modules not from the Apache Foundation.)
Administrators can build Apache modules for use with the Secure Web Server. The standard Apacheapxs
utility (/usr/internet/httpd/bin/apxsor/usr/opt/hpapache2/bin/apxs) is provided with
the Secure WebServerto assist you during compilation and installation of the Apache modules.
Instructions for compiling modules using theapxsutility are usually included with the source code for
that particular module. Instructions can also be found in the standard Apache documentation on the Web:
http://www.apache.org .
Standard Apache documentation is also included with the Secure Web Server in the IAEAPDOCxxx subset,
installed in/usr/internet/httpd/apdocs. Standard Apache 2.0 documentation is installed in
/usr/hpapache2/manual.
3.1.1 Standard Modules Provided as DSO Modules
The SecureWeb Server provides several standard Apache modules as DSO modules. These are modules
that are included in source form as part of the Apache Version 1.3 source distributions and Apache Version
2.0 sourcedistribution. Although there are many modules that are included in the distributions, many of
them are not included in the default server configuration. The optional modules are provided in the form
ofDSOmodulesso they can be activated if needed. Table A-2 lists and describes the modules for the
Secure WebServer 1.3. Table B-2 lists and describes the modules for the Secure Web Server 2.0.
3.1.2 Nonstandard Modules Provided as DSO Modules
In addition to the standard Apache modules, the Secure Web Server provides DSO modules from sources
outside the Apache Foundation.
Table A-3 and Table A-4 provide alist of nonstandard modules for the Secure Web Server 1.3. Table B-3
provides alist of nonstandard modules for the Secure Web Server 2.0.
3.1 Secure WebServer Support for Apache Dynamic Modules
43
3.2 Activating the Apache DSO Modules
To activate an Apache DSO module, you must modify the httpd.confserverconfiguration file, as
follows:
1. Adda LoadModule directive.
2. Add an AddModuledirective, if the ClearModuledirectiveisused.
3. Add additional module configuration-specificdirectiv es.
4. Restart the server for the configuration changes to take effect.
Usually, an Apache DSO module will not perform any useful function until the module-specific
configurationdirectiv es activate the module'sfunctionality. The module-specific documentation explains
the module configurationdirectiv es. For Apache DSO modules provided with the Secure Web Server,
refer to either the Apache documentation provided with the Secure Web Server kit, or the documentation
available on the Apache Web site:
http://httpd.apache.org
3.2.1 Usingthe LoadModule Directive
The LoadModule directive enables dynamic module loading by the Web server. This directive must occur
before any other configuration directive for the module being loaded.
The LoadModule directive has the following form:
LoadModule module_identifier filename
The module_identifier variable is the internal module definition variable name, that is documented
in the module documentation.
The filename parameter is the loadable module on disk that the server will load. The filename can be
an absolute path ora path relative to the server root as defined by thehttpd.conf file.
If the ClearModuledirective is present, it signals the server that the list of loaded modules needs to be
reordered. The ClearModule directive begins the process by clearing the internal list of modules, thus
providing the configuration file with a complete list of all modules (integrated and DSO). Each module is
readded to the module list with an AddModule directive ( Section 3.2.2: Using the AddModule Directive ).
3.2.2 Usingthe AddModule Directive
The AddModule directive is used by the Web server to build alist of modules in order of precedence. The
directive is only needed if the ClearModule directive is used to zero out the module list. If the ClearModule
directive is not used, then the module precedence is in the order that they were loaded.
The AddModule directive has the form:
AddModule source_file
The source_file is the filename of the compilation unit that contained the module declaration. To
determine the proper filename touse, seethe module-specific documentation.
3.2.3 Verifying the Configuration File
After adding the configurationdirectiv es to the httpd.conf file, the file syntax can be reviewed prior
to restarting the server. The following command directs the server to verify the specified configuration
file:
For SecureWeb Server 1.3:
# /usr/internet/httpd/bin/httpd -t -f /usr/internet/httpd/conf/httpd.conf
For SecureWeb Server 2.0:
# /usr/opt/hpapache2/bin/httpd -t -f /usr/opt/hpapache2/httpd.conf
44
Using Dynamic Modules
3.2.4 Activating an Apache DSO Module—Example
The example in this section shows how to activate the mod_usertrack Apache DSO module, which uses
Cookies to track users. To activate the module, use the httpd.conf configuration file for the default
public server/usr/internet/httpd/conf/httpd.conf and follow these steps:
1. Define the LoadModule directive as follows:
LoadModule usertrack_module libexec/mod_usertrack.so
2. If the ClearModuledirective is defined, add the module to the module list with an AddModule
directive:
AddModule mod_usertrack.c
3. Define the module-specificdirectiv es, for example:
CookieName OurTestCookie
CookieTracking on
4. Track the generated cookies by using a directive for another Apache module (that is, one that is
integrated in the Secure Web Server). This directive will cause the cookies to be logged into a file
called clickstream, in the logs directory relative to the server root. For example:
CustomLog logs/clickstream "%{cookie}n %r %t"
3.2 Activating the Apache DSO Modules
45
46
4 Implementing the Tomcat Java Servletand JavaS erver
Pages Container
This chapter contains the following information:
•Overview ofTomcat ( Section 4.1: Tomcat Overview )
•Using Tomcat asastandalone public Web server ( Section 4.2: Using Tomcat as a Standalone Public
Web Server )
•Locating Tomcat directories ( Section 4.3: Locating Tomcat Directories )
•Selectinga Java environment ( Section 4.4: Selectinga Java Environment )
•Starting Tomcat ( Section 4.5: Starting Tomcat )
•Accessing the Tomcat administration and manager Web-based applications ( Section 4.6: Accessing
the Tomcat Administration and Manager Applications )
•Accessing the Tomcat examples ( Section 4.7: Accessing the Tomcat Examples )
•Locating additional information ( Section 4.8: Locating Additional Information )
4.1 TomcatOverview
Tomcat is a Java Servletand JavaServer Pages (JSP) container provided through the Apache Software
Foundation Jakarta project. The Tomcat container is most commonly used with commercial grade Web
servers such as Apache. It can also be used as a standalone Web server.
Tomcat is provided with the Secure Web Server as an optional subset (IAETOMCAT xxx , where xxx is the
version number of the Secure Web Server release). When this subset is installed:
•Thepublic instance of the Secure Web Server can be configured to seamlessly pass requests for Java
Servletand JavaServer Pages to the Tomcat engine. With the Secure Web Server handling the direct
interaction with the browser, it can provide additional functionality that Tomcat cannot provide by
itself, such as IPv6 support and Apache modules used for access control.
•Tomcatcanbe configured to act as a standalone Web server. For sites with primarily Java-based
dynamic content, this option generally improves performance and response time.
•Tomcat maybe configured to act simultaneously a standalone Web server and asarequest handler
from the Secure Web Server.
The Tomcatsubset createsa Cluster Application Availability (CAA) resource when it is used ina TruCluster
environment. Tomcat is configured as a single instance resource so that it can take advantage of sessions
and other capabilities ofa Java Servlet environment. The public instances of the (multi-instance) Secure
Web Serverare configured to communicate with the Tomcat instance and will handle the failoverofthe
Tomcat resource.
For more information on developing and installing servlets and JSPs, see Section 4.8: Locating Additional
Information . After installing or updating an application, the Tomcat container and the public Web server
may need to be restarted. For information on starting Tomcat, see Section 4.5: Starting Tomcat .
4.2 Using Tomcatasa Standalone Public Web Server
Tomcat maybe installed as a standalone public Web server. When you install Tomcat in this manner, the
server is configured to respond to HTTP requests on a specified port. Tomcat was previously used
exclusively asabackendtoan Apache-based Web server. It has now evolved intoafull-featured Web
server.
AW ebserveris normally run as anon-privileged user to reduce potential security risks. The Secure Web
Server has provisions for switching to the user httpdafterit has opened its ports. To perform the same
actions with Tomcat, you must run a program called jsvcwhenev er the Web server port configured is
less than 1024. Thejsvcprogramis part of the Tomcat source distribution. This installation will
automatically use thejsvcprogram, if needed, when Tomcat is started with the /sbin/init.d/tomcat
script orby using the Manage the Tomcat Java Servletand JSP Engine link from the Web Server
Administration menu (see Section 4.5.1: Starting and Stopping Tomcat from the Administration Utility ).
4.1 TomcatOverview 47
4.3 LocatingTomcat Directories
After installation, Tomcat resides in the /usr/internet/httpd/tomcat directory. Applications (Java
Servletsand JSPs) are installed under the /usr/internet/httpd/tomcat/webappsdirectory.
Tomcat-specific configuration information is installed in the /usr/internet/httpd/tomcat/conf
directory.
4.4 Selectinga Java Environment
In some cases, multiple Java Development Environment kits (JDK) might be installed on a system. You
can customize the Java environment used to power the Tomcat container by specifying which Java
Development Environment kit (JDK) touse and by adding optional parameters to the java command.
Customizing the Java environment is also useful when special tuning of the Java Runtimeisdesired.
Tomcat first uses values specified in the /usr/internet/httpd/tomcat/bin/setenv.sh initialization
file. If no values are specified in this file, Tomcat uses the Java system default. When you first install the
Tomcat subset, it creates the /usr/internet/httpd/tomcat/bin/setenv.sh initialization file (if it
does not already exist) so that Tomcat will use the newest version of the JDK that is present at installation.
If you want touse a different version of the JDK, change the JAVA_HOME and JAVA_CMD variables defined
in the initialization file. The JAVA_HOME and JAVA_CMD variables should always reference the same JDK;
if they do not, Tomcat will fail to operate properly. The JAVA_CMD variable should be quoted to allow for
the addition of arguments.
The following example shows a /usr/internet/httpd/tomcat/bin/setenv.sh initialization file
with additional java command arguments:
JAVA_HOME=/usr/opt/java/131
JAVA_CMD="$JAVA_HOME/bin/java -classic"
export JAVA_HOME JAVACMD
4.5 StartingTomcat
Section4.5.1: Starting and Stopping Tomcat from the Administration Utility describes how to start, stop,
and restart Tomcat as a standaloneserv er from the Web Server Administration utility.
Starting or restarting Tomcat is different if you are running your Secure Web Server ina TruCluster
environment. Section 4.5.2: Restarting Tomcat in a Non-TruCluster Environment describes how to restart
Tomcat using the tomcat startup script when it is not ina TruCluster environment. Section 4.5.3: Restarting
Tomcat in a TruCluster Environment describes how to restart Tomcat using the caa_start and
cluster_restart
scripts when runningTomcatin aTruCluster environment.
Section4.5.4: Tomcat Log Files gives the location of the Tomcat log files.
The SecureWeb Server startup script is designed to detect the presence of Tomcat and start the Web server
with additional command-line directives that enable the communication with Tomcat and cause the
dynamic configuration files generated by Tomcat to be used.
The Tomcatengine creates a number of configuration files each time it is started. These configuration files
containdirectiv es that determine the information the Secure Web Server will serve and the requests that
should be directed to the Tomcat engine.
Note:
To take full advantage of the changes in Web contexts, the Secure Web Server configuration must be
changed to map the new contexts and then the web server must be restartedwhenev er you change the
Tomcat configuration.
4.5.1 Starting and Stopping Tomcat from the Administration Utility
You can start, stop, and restart thestandalone Tomcat server from the Web Server Administration utility.
To start the Tomcat server:
48
Implementing the Tomcat Java Servletand JavaServer Pages Container
1. On the WebServer Administration menu, choose Manage the Tomcat Java Servletand JSP Engine.
The Managethe Tomcat Java Servletand JSP Engine form is displayed.
2. On the Managethe Tomcat Java Servletand JSP Engine form, click on Start/Stop the Manage the
Tomcat JavaServlet and JSP Engine ( Figure 4-1 ). Tomcat starts the server and displays a message
that the server is running.
Figure4-1 Manage the Tomcat Java Servletand JSP Engine Form
To stop and restart the Tomcat server:
1. On the Managethe Tomcat Java Servletand JSP Engine form, click on Start/Stop the Manage the
Tomcat JavaServlet and JSP Engine ( Figure 4-1 ). The Start/Stop the Manage the Tomcat Java Servlet
and JSPEngineform is displayed ( Figure 4-2 ).
Figure4-2 Start/Stop the Tomcat Java Servletand JSP Engine Form
2. Click on stop to stop the server. Tomcat displays a message that the server is stopped.
3. To restart the server, click on restart. Tomcat displays a message that the server is again running.
4.5.2 Restarting Tomcat ina Non-TruCluster Environment
To start Tomcatandthe Secure Web Server that is not part ofa TruCluster environment:
1. If Tomcatis running, use the stop command to stop the server:
# /sbin/init.d/tomcat stop
And this command to restart the server:
# /sbin/init.d/tomcat restart
2. Start the Tomcatserver using the start command:
# /sbin/init.d/tomcat start
3. Restart the public instance of the Secure Web Server using the restart command:
# /sbin/init.d/httpd_public restart
4.5.3 Restarting Tomcat ina TruCluster Environment
To restart Tomcat and the Secure Web Server ina TruCluster environment:
4.5 StartingTomcat
49
1. If Tomcatis running, use thecaa_stop command to stop the server:
# caa_stop tomcat
And this command to restart the server:
# /sbin/init.d/tomcat restart
2. Start the Tomcat Server using thecaa_start command:
# caa_start tomcat
3. Restart (on all cluster members) the public instance of the Secure Web Server using the
cluster-restart
command:
# /sbin/init.d/httpd_public cluster-restart
4.5.4 TomcatLog Files
Tomcat records log files in the/usr/internet/httpd/logs directory. Table 4-1 lists the log files Tomcat
creates and providesa description of each file.
Table4-1 Tomcat Log Files
Description
Log File
Tomcat startup log
tomcat_startup.log
Tomcat general log
catalina.out
Access requests log, shared with the Secure Web Server
access_log
Failed access requests log, shared with the Secure Web Server
error_log
The process IDoftheTomcat process.
tomcat.pid
4.6 Accessing the Tomcat Administration and Manager Applications
Tomcat provides Web-based applications for administering the Tomcat deployment and for managing
thelifecycleof Web applications running within the Tomcat container. To access the Tomcat Web-based
administration features:
1. On the WebServer Administration menu, choose Manage the Tomcat Java Servletand JSP Engine.
The Managethe Tomcat Java Servletand JSP Engine form is displayed. This menu allows you to start
or stop the Tomcat Java Serveletand JSP Engine (see Section 4.5.1 ) and perform the following
Web-based administration functions:
•Accessthe Tomcat administrationserv er-An Open Source Web-based server for administering
the Tomcat Server, server resources (for example, data sources, mail sessions), and server user
definitions (i.e., users, groups, and roles).
•Manage Tomcat Web applications -An Open Source management tool for managing
Tomcat-based Web applications.
2. To access the Tomcat administration serv er, click on Access the Tomcat Administration Server. For
Internet Express users, the administratorusername and password is identical toy our Internet Express
username (admin) and password.
If the Internet Express or Secure Web Server Administration Server is not installed, you must manually
create the Tomcat Administratorusername and password. Refer to the Configuring Manager
Application Access section on the following URL for instructions on how to createa Tomcat
Administratorusername and password:
http:// Tomcatstandalone Web server
name :8082/tomcat/tomcat-docs/manager-howto.html
3. To manage Tomcat Web Applications, click on Manage Tomcat Web Applications.
By default, access to these management applications is limited to browsers running on the local host and
requires that users successfully authenticate before being granted access. The local host restriction is
established by access control valves in the/usr/internet/httpd/tomcat/conf/server.xmlfile.
To modify this restriction:
50
Implementing the Tomcat Java Servletand JavaServer Pages Container
•Edittheserver.xmlfiletochange the list of allowed hosts, or
•Delete the Valve element entirely to remove host-based restrictions.
•Restart Tomcat for the changes to take effect. Seethe specific instructions in Section 4.5.1: Starting
and Stopping Tomcat from the Administration Utility for restarting Tomcat in anon-cluster or cluster
environment.
Note:
The default restriction requires that a browser on the local host must access the management applications
usingURLsthat begin with http://localhost/. If you attempt to access the applications with URLs
that begin with http:// actual_hostname_of_local_host /, it will be rejected.
User authentication is provided by a custom realm that allows a user who successfully authenticates as
the Secure WebServer administration user to be mapped to the Tomcat user roles admin and manager.
These roles are required to access the administration and Web application management utilities. If this
initial authentication attempt fails, the realm then attempts to authenticate via Tomcat'sdefaultuser
authentication database, defined by the /usr/internet/httpd/tomcat/conf/tomcat-users.xmlfile.
To change the behavior of this custom realm, modify the
/usr/internet/httpd/tomcat/conf/server.xmlfileas necessary and then restart Tomcat.
4.7 Accessing the Tomcat Examples
The Tomcatsubset includes Web applications for the Tomcat documentation and example Java Servlets
andJavaServerP ages. The Web applications are installed in the
/usr/internet/httpd/tomcat/samples directory. The Web applications are deployed by default
and are accessed by specifying the name of your host domain, as follows:
http:// yourhost.domain /tomcat/
To prevent the Web applications from being deployed, perform the following task:
Edit the/usr/internet/httpd/tomcat/conf/server.xmlfileand comment out or remove the
following entries:
<Context path="/tomcat"
docBase="/usr/internet/httpd/tomcat/samples/ROOT.war"
reloadable="false" debug="0" />
<Context path="/tomcat/examples"
docBase="/usr/internet/httpd/tomcat/samples/examples.war"
reloadable="false" debug="0" />
<Context path="/tomcat/docs"
docBase="/usr/internet/httpd/tomcat/samples/tomcat-docs.war"
reloadable="false" debug="0" />
<Context path="/tomcat/webdav"
docBase="/usr/internet/httpd/tomcat/samples/webdav.war"
reloadable="false" debug="0" />
4.8 LocatingAdditional Information
Additional information about Tomcat can be found in the following locations:
•The JakartaProject Web site: http://jakarta.apache.org
•Tomcat documentation Web site: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html
4.7 Accessing the Tomcat Examples
51
52
5 Enabling the Secure Socket La yer Protocol
To enhance the security of communications bet weeny our Web browser and administrative instances of
the Secure WebServer, the Secure Web Servers have built-in support for the Secure Socket Layer ( SSL )
protocol. This chapter describes how SSL provides secure Internet connections and how touse Internet
Express to enable SSL on your server.
5.1 SSLConcepts
The SSLprotocolisa widely used method for performing secure transactions on the Web. This protocol
is supported by most Web servers and clients including Netscape Navigator and Microsoft Internet
Explorer.
SSL providesprivacy, guaranteed through encryption. Although information can be intercepted by a third
party, the perpetrator cannot read the information without the private encryption key ( session key ). If the
information is received and will not decrypt properly, the recipient can determine that the information
has been tampered with during transmission. Authentication is provided through digital certificates
generated forSSL, though the source of digital certificates might not always be credible foronlinepayment
transactions.
SSL encryption uses a secret key nested within public key encryption , authenticated through certificates.
Secret key encryption provides faster access than public-key encryption alone. Initially, the client and
server exchange public keys, and then the client generates a session key fora specific transaction. The
client encrypts the session key with the server'spublickeyand sends the information to the server. Then,
and for the remainder of the transaction, the client and the server use the session key for private key
encryption.
Completinga transaction with an SSL-enabled server follows this general procedure:
1. A client sends a request fora document to be transmitted using the https: protocol by prefixing the
URL withhttps://.
2. The server sends the client its certificate.
3. The client verifies that the certificate was issued by a trusted Certificate Authority (CA). If the client
does not verify theCA, it gives the user the option to continue or to terminate the transaction.
4. The client compares information in the certificate with informationreceiv ed concerning the site;
specifically, the domain name and the public key. If the information matches, the client accepts the
site as authentic.
5. The client tells the server what ciphers (encryption algorithms) it uses to communicate.
6. The client generatesa session key using the agreed-upon cipher.
7. The client encrypts the session key with the server'spublickeyand sends the information to the
server.
8. The server receives the encrypted session key and decrypts the information with the session key.
9. The client and the server then use the session key for the remainder of the transaction.
For additional information about SSL, seethe mod-ssl Web site:
http://www.modssl.org/docs
5.2 EnablingSSL Support from the Web Server Administration Utility
Using the WebServ er Administration utility, you can manage support for SSL connections. Follow these
steps:
1. On the Secure Web Server Administration menu, select the Web server for which you want to enable
(or disable) SSL support, for example, the public Web server. The Manage the Public Web Server
menu is displayed (see Figure 2-11 ).
2. Choose Manage SSL for the Public Web Server. The SSL menu options are displayed ( Figure 5-1:
Manage SSLforthePublic Web Server Menu ), initially showing the following options:
•Generateaprivate key ( Section 5.3: Generatinga Private Key )
•Generatea certificate request ( Section 5.4: Generatinga Certificate Request )
5.1 SSLConcepts 53
•Generate and install a test certificate ( Section 5.5: Generating and Installinga Test Certificate )
•Installa certificate ( Section 5.6: Installinga Digital Certificate )
3. Proceed to generate a private key ( Section 5.3: Generatinga Private Key ) and request a digital certificate
( Section5.4: Generating a Certificate Request ).
Note:
The steps for managing SSL that are described in this chapter use public Web server examples. Steps
for managing SSL for the Administration Web Server are identical.
Figure5-1 Manage SSL for the Public Web Server Menu
When you enable SSL for the first time, you must generate a private key and then generatea certificate
request. A Certificate Authority (CA), such as VeriSign ( http://www.verisign.com ), processes the request
and provides you with an official digital certificate. While waiting for your official digital certificate, you
can generate and install a test certificate. These steps are described in "Generatinga Private Key" through
Section5.5: Generating and Installing a Test Certificate .
For information on setting up an Apache Web server with SSL without using the Secure Web Server
Administration utility, visit the Apache Web site at the following URL:
http://www.apache.org/
5.3 Generatinga Private Key
SSL usesonasymmetric key encryption to encode and decode data that is transmitted to and from the
Web server. SSL key encryption requires two keys: a private key and a public key. The private key resides
ontheWebserver system and must be kept secure. Before you can perform other steps to setup an SSL
connection, you must generate a private key.
To generate a priv ate key, perform these steps:
1. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
2. Choose Generatea Private Key. The Generatea Private Key menu is displayed, informing you whether
a private key already exists.
3. Click Submit to generateaprivate key. When you generateaprivate key, the key is saved to following
file for each serv er:
/usr/internet/httpd/ server /conf/ssl.key/server.key
Where server is the name of the ser veryouare modifying for SSL, as follows:
•Public Webservers:
/usr/internet/httpd/conf/ssl.key/server.key
•Administration Web Server:
/usr/internet/httpd/admin/conf/ssl.key/server.key
54
Enabling the Secure Socket Layer Protocol
If a private key already exists, the existing key is saved inaseparate server. n .key file where n is
an integer incrementing from 1.
Figure5-2 shows that a private key has been generated for the public Web server and the location of the
server.key file. Note that you can generatea certificate request directly from this page, from which you
can display the Generatea Certificate Request form. See Section 5.4 for complete steps for generating a
certificate request.
Figure5-2 Gen er atea Private Key—Results
5.4 Generatinga Certificate Request
After you have generated a priv ate key ( Section 5.3 ), you can generate a certificate request that provides
information about your company and private key toa Certificate Authority (CA). From this request, an
X.509 certificate signing request (CSR) is created.
To generate a certificate request, perform these steps:
1. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
2. Choose Generatea Certificate Request. The Generatea Certificate Request form is displayed
( Figure5-3 ).
5.4 Generatinga Certificate Request 55
Figure 5-3 Gen er atea Certificate Request Form
3. Enter your company data in the text fields.
A two-character country code is required by your CA. For the country code, enter an official ISO
standard two-character country code as defined in ISO Standard 3166-1 :
http://www.iso.org/iso/en/ISOOnline.frontpage
For the Common Name field, use the fully qualified domain name of your server (for example,
www.server.wyxcorp.com).
4. Click on Submit. From the information you provided, an X.509 certificate signing request (CSR) is
created. The certificate request displays in your browser window and is saved in the
/usr/internet/httpd/ server /conf/ssl.csr/server.csrfile, where server is the name
of the server you are modifying. For the Web Server Public Instance, the certificate request file is
saved in/usr/internet/httpd/conf/ssl.csr/server.csr.
5. To complete the certificate request process, copy information from the browser window or copy the
contents from the CSR file and send the information (along with required paperwork and payment)
to a Certificate Authority (CA) such as VeriSign ( http://www.versign.com ). The highlighted text in
Figure5-4 shows the information that you send toy our CA.
Note that you can generate a test certificate directly from this page. See Section 5.5 for complete steps
for generatingatest certificate.
56
Enabling the Secure Socket Layer Protocol
Figure5-4 Certificate Request Success Notice
5.5 Generating and Installing a Test Certificate
Before you receive y our official certificate, you can generate a self-signed certificate and test establishing
secure connections from your server.
To generate and install a test certificate, perform these steps:
1. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
2. Choose Generate and Installa Test Certificate. The Generate and Installa Test Certificate form is
displayed.
3. Click on Submit. The test certificate is saved in the
/usr/internet/httpd/ server /conf/ssl.crt/server.crtfile, where server is the name
of the server you are modifying. When you generate and install an official certificate, it is saved in
the same file.
For example, for the public Web server, the test certificate or official certificate is stored in
/usr/internet/httpd/conf/ssl.crt/server.crt. If you hadaprevious certificate, the new
certificate overwrites the server.crtfile. However, existing certificates are saved under anew name.
Figure5-5 shows the message displayed when successfully installing the test certificate.
Figure 5-5 Test Certificate Installation Success Notice
5.5 Generating and Installinga Test Certificate 57
With a test certificate in place, you can now try enabling SSL on the server.
4. On the Generateand Install Test Certificate form ( Figure 5-5 ), click on the Manage SSL button to
enableSSLusing the installed test certificate. The Manage SSL for the Public Web Server form will
be displayed as shown in Figure 5-9 . See Section 5.8 for instructions on enabling and disabling SSL
fora Web server using this form.
When you generate a test certificate, it is automatically installed. The Manage SSL main menu changes to
show two additional options, as shown in Figure 5-6 .
Figure 5-6 Manage SSLM ain Menu with Additional Options
With a test certificate in place, you can now try connecting to the SSL-enabled system. Note that when
you make an SSL connection to a server using a self-signed test certificate, you are warned that the certificate
is signed by an untrusted source. The system gives you the option to accept the certificate and connect to
theWebserver.
To view the contents of the certificate, see Section 5.7: Viewing Certificate Details .
5.6 Installinga Digital Certificate
When you receive a digital certificate from your Certificate Authority, you must then install it to the proper
location.
To install a certificate, perform these steps:
1. Determine that the certificate you received is compatible with the private key you created in Section 5.3:
Generatinga Priv ate Key . The key and certificate must be compatible for the certificate to install
properly.
2. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
3. Choose Installa Certificate. The Installa Certificate form is displayed.
4. Cut and paste the contents from the official certificate into the Installa Certificate text field, shown
in Figure5-7 .
58
Enabling the Secure Socket Layer Protocol
Figure5-7 Installa Certificate Text Field
5. Click on Submit. The certificate file is copied to the
/usr/internet/httpd/ server /conf/ssl.crt/server.crtfile, where server is the name
of the system you are modifying.
If you generated and installed a test certificate ( Section 5.5: Generating and Installinga Test Certificate ),
the test certificate file (server.crt) is overwritten with the official certificate file and is saved under
anew name (for example, server.2.crt).
After successfully installing the certificate, the Manage SSL main menu provides two additional options
that let you:
•View certificate details ( Section 5.7: Viewing Certificate Details )
•Enableordisable SSL capabilities ( Section 5.8: Enabling and Disabling SSL fora Web Server )
These options also appear on the Manage SSL main menu when you generate and install a test certificate
( Figure5-6 ).
5.7 Viewing Certificate Details
The ViewCertificate Details option enables you to display certificate information in a readable format.
This certificate file includes information you provided when you requested the certificate ( Section 5.4:
Generatinga Certificate Request ), information from the CA, and information about your public key.
1. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
2. Choose View Certificate Details. The certificate stored in
/usr/internet/httpd/ server /conf/ssl.crt/server.crtisdisplayedin readable format.
Figure5-8 shows the information in an example certificate.
5.7 ViewingCertificate Details 59
Figure 5-8 Certificate File in Readable Format
5.8 Enablingand Disabling SSL fora Web Server
After obtainingapriv ate key and an official certificate, you can enable (or disable) SSL capabilities for
your Web server. When you enable SSL, the Web server'sruntime configuration file
(/usr/internet/httpd/server/conf/.httpdrc) is revised to instruct the Web server touse SSL
when it restarts. Enabling SSL affects the public and administrationserv ers as follows:
•Forthepublic Web server instance, you can connect to the secure Port 443 using the https: prefix.
Note that you also can continue connecting to Port 80 using anon-secure connection using the http:
prefix.
•Forthe Administration Web Server instance, the port defined for each server is changed. You can
only connect as a secure port using thehttps: prefix and the same port number. Once you connect
to one of the administrationserv ers, the Administration utility manages the connection to the other
servers, using the proper type of connection.
To enable (or disable) SSL capabilities fora Web server:
1. From the server administration menu, choose Manage SSL for the desired server. For example, from
the Manage the Public Web Server menu, choose Manage SSL for the Public Web Server. The Manage
SSLforthePublic Web Server menu is displayed.
2. Choose the Enable button or the Disable button at the bottom of the form to enable or disable SSL
for the server, respectively.
Figure5-9 shows the confirmation page after SSL has been enabled on the server.
60
Enabling the Secure Socket Layer Protocol
Figure 5-9 Enable SSL Confirmation Page
5.9 Testing Your SSLC onnection
Testy our secure connection after enabling SSL for public and administrationserv ers, as follows:
•Fora public Webserver, the standardhttps: port is 443. When you specifya URL as
https://www.xxx. com/, for example, it automatically uses Port 443. Also test access to the
nonsecure public server Port 80 by using httpd: after enabling SSL. (See Section 5.10 for additional
considerations when enabling SSL for public Web servers.)
•For an administrationserv er, the same port is used for all connections, regardless of whether SSL is
enabled. With SSL enabled, you can only access this server usinghttps://www.xxx. com:8081/.
Usinghttp: will produce an error message asking you to specifyhttps: ( Figure 5-10 ). The
administrationserv er menus determine which protocol touse, http: orhttps: , and will advise
you when you first connect.
Figure5-10 SSL Connections Error Message
Note:
After enabling SSL and changinga connection from nonsecure to secure, you might not be able touse the
Back button of your browser to navigate to pages viewed prior to enabling SSL. Similarly, disabling SSL
and changing a connection from secure to nonsecure might affect use of the Back button. This happens
because the saved prefix might no longer be valid.
5.10 Specifying Public Web Server Access to HTTP and HTTPS
Connections
After enabling SSL for the Web Server Public Instance, the data hierarchy you created (by default,
/usr/internet/httpd/htdocs) will be accessible either using the standardhttp: protocol or the
SSL-enabledhttps: protocol.
To limit access just tohttps: connections, perform these steps:
5.9 Testing YourSSL Connection
61
1. From the Secure Web Server Administration menu, choose Manage the Public Web Server.
2. Choose Change Configuration Parameters.
3. Choose Change Listening Ports and Addresses and remove Port 80 from the list of active ports and
make Port 443the primary port.
4. Click Submit to update the configuration file and restart the public Web server.
If you want the public Web server to respond to bothhttp: requests on Port 80 andhttps: requests on
Port 443while maintaining separate data hierarchies, you must manually change the public Web server
configuration file /usr/internet/httpd/conf/httpd.conf. Anyhttps: directories must be defined
within the SSLVirtualHost directive. (In the configuration file, search for the line<VirtualHost
_default_:443>.)
Directory, Location, or File directives placed within the SSLVirtualHost directive, as well as Alias and
ScriptAliasdirectiv es placed within the SSLVirtualHost directive, can only be accessed when SSL is
enabled and when https: connections are used. By changing the value of the DocumentRoot directive
within the SSLVirtualHost directive, you can specify a default location specific tohttps: connections.
5.11 Migrating Your Nets cape Digital Certificate to the Secure Web
Server
This section describes how to migratea Netscape Web Server digital certificate to the Secure Web Server,
which will then allow you to migrate Netscape (iPlanet) Web Server SSL users to an SSL-enabled Secure
Web Server.
5.11.1 Prerequisites for Migration
Before you can migrate your Netscapedigital certificate to the Secure Web Server, you must first access
theNetscape Web Server'sprivatekey. You use this key as the Secure Web Server'sprivatekeywhen
installing the digital certificate. You must also saveacopyofthe Netscape Web Server'sdigital certificate
in order to install it in the Secure Web Server.
The SecureWeb Server must have the same Common Name and IP address as the Netscape Web Server.
This data was used when creating the Certificate Signing Request that you sent toy our Certificate Authority
when requesting the digital certificate. The Common Name is usually the same as the fully qualified host
name of the server.
5.11.2 Migrating the Nets cape Digital Certificate
Follow these steps to migrate your Netscape Web Server private key and digital certificate to the Secure
Web Server:
1. Loginasrootonthe system where you installed both Web servers and start the Netscape
Communicator 4.XW ebbrowser:
# su root
# /usr/bin/X11/netscape &
2. Create a backup copy of the Web browser certificate file and the private key database file in the root
user's$HOME/.netscape directory:
# cp -pf /.netscape/key3.db /.netscape/key3. db.orig
# cp -pf /.netscape/cert7.db /.netscape/cert7.db.orig
3. Copy the Netscape Web Server digital certificate file and private key database file from the Web
server root to the/.netscape directory, overwriting the Web browser certificate file and key database
file:
# cp -pf Netscapeserver root /alias/ serverkeydatabase name -key3.db/
.netscape/key3.db
# cp -pf Netscapeserver root /alias/ servercertificatedatabase name -cert7.db /
.netscape/cert 7.db
62
Enabling the Secure Socket Layer Protocol
4. Export the Web Server private key database toa PKCS#12 (PFX) format certificate file using Netscape
Communicator, as follows:
a. Under the Communicator pulldown menu, select the Security Info option in the Tools menu.
(Alternately, click on the padlock icon in the bottom left hand corner of the Web browser.) The
Security Info dialog box is displayed.
b. Select the Yours option under Certificates in the Security Info dialog box. The Server-Cert
certificate appears in the displayed list.
c. Select the Server-Cert certificate and click on the Export button.
Note:
You must use the same pass wordyouusedfor the Netscape Web Server key database when
prompted to enter the passwords for accessing and exporting the certificate.
d. Export the certificate to the PKCS#12 format certificate file by entering the name of the file (for
example, cert.p12) in the Save As pop-up menu, then click on OK.
5. Extract the private key from the PKCS#12 format certificate file (cert.p12) using the OpenSSLpkcs12
command. Save the private key toa PEM-format private key file, using the same pass wordyou
entered for the import password and PEM pass phase:
# /usr/internet/httpd/bin/openssl pkcs12 -nocerts -in/
.netscape/cert.p12 -out /.netscape/key.pem
Enter Import Password: password
MAC verified OK
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase: password
6. Remove the PEM pass phase from the private key file using the OpenSSLrsa command:
# /usr/internet/httpd/bin/openssl rsa -in /.netscape/
key.pem -out /.netscape/keyout.pem
read RSA key
Enter PEM pass phrase: password
writing RSA key
7. Create the Secure Web Server Private Key directory and copy the private key file to the server.key
file into the directory:
# mkdir -p /usr/internet/httpd/ server name /conf/ssl.key
# chown root:system /usr/internet/httpd/ server name /conf/ssl.key
# chmod 640 /.netscape/keyout.pem
# chown root:nobody /.netscape/keyout.pem
# cp -pf /.netscape/keyout.pem /usr/internet/httpd/
server name /conf/ssl.key/server.key
Note:
The server name directory should be omitted when creating the private key file for the Public Web
Server instance.
8. Copy back the original Web browser certificate file and key database file overwriting the Web Server
certificate file and key database file, then remove the files you created:
5.11 Migrating Your Netscape Digital Certificate to the Secure Web Server
63
# cp -pf /.netscape/key3.db.orig /.netscape/key3. db
# cp -pf /.netscape/cert7.db.orig /.netscape/cert7.db
# rm -f /.netscape/cert. p12 /.netscape/key.pem /.netscape/keyout.pem
9. Using the copy of the Netscape Web Server certificate yourecievedback from your Certificate
Authority, install the digital certificate into the Secure Web Server using the Install a Certificate form
provided in the Secure Web Server Administrationserv er (see Section 5.6 ).
64
Enabling the Secure Socket Layer Protocol
AS ecureWebServer 1.3 Components and Modules
Table A-1 lists the major components of the Secure Web Server 1.3 kit, along with a URL for more
information about each component.
Table A-2 lists the Apache source distribution standard modules that are provided with the Secure Web
Server 1.3. Modules are either provided built into the httpdimageor as Dynamic Shared Objects.
Table A-3 lists modules that are part of the mod_ssldistribution that is integrated in the Secure Web
Server 1.3 kit.
Table A-4 lists other modules provided with the Secure Web Server.
Table A-1SecureWebServer 1.3 Components
URL
Description
Component
http://www.apache.org
Apache HTTPServer.
Apache HTTPD
http://www.openssl.org
An OpenSourcetoolkit that
implements the Secure Sockets Layer
(SSLVersion2/Version 3) and
Transport Layer Security (TLSV ersion
1) protocols, as well asacomplete,
general purpose cryptography library.
mod_ssl
http://www.php.net
A server-side, cross-platform HTML
embedded scripting language.
PHP
http://www.fastcgi.com
A language-independent, scalable,
open extension to CGI that provides
high performance without the
limitations of server-specific APIs.
fastcgi
http://www.rudedog.org/auth_ldap/
An LDAPauthentication module for
Apache.
auth_ldap
http://www.analog.cx
A popular log file analyzer.
Analog
Table A-2 Standard Secure Web Server 1.3 Modules
Description
DSOorIntegrated
Module
Provides access control based on client host name or IP address.
Integrated
mod_access
Executes CGIscripts based on media type or request method.
Integrated
mod_actions
Maps different parts of the host file system in the document tree,
andURL redirection.
Integrated
mod_alias
Sends files that contain their own HTTP headers.
Integrated
mod_asis
Provides user authentication using text files.
Integrated
mod_auth
Allows "anonymous"user access to authenticated areas.
DSO
mod_auth_anon
Provides user authentication using Berkeley DB files.
DSO
mod_auth_db
Provides user authentication using DBM files.
Integrated
mod_auth_dbm
Generates automatic directory listings.
Integrated
mod_autoindex
Support for HTTP headermetafiles.
DSO
mod_cern_meta
Invokes CGIscripts.
Integrated
mod_cgi
Provides MD5authentication.
DSO
mod_digest
Provides basic directory handling.
Integrated
mod_dir
Applies Expires: headers to resources.
DSO
mod_expires
Adds arbitrary HTTP headers to resources.
DSO
mod_headers
Provides the image map file handler.
Integrated
mod_imap
Provides server-parsed documents.
Integrated
mod_include
65
Table A-2 Standard Secure Web Server 1.3 Modules ( continued )
Description
DSOorIntegrated
Module
Provides server configuration information.
Integrated
mod_info*
Provides a log of user agents.
DSO
mod_log_agent
Provides user-configurable logging replacement for
mod_log_common.
Integrated
mod_log_config
Provides a log document references.
DSO
mod_log_referer
Determines document types using file extensions.
Integrated
mod_mime
Determines document types using"magic numbers".
DSO
mod_mime_magic
Experimental file caching; maps files into memory to improve
performance.
DSO
mod_mmap_static
Negotiates content.
Integrated
mod_negotiation
Provides caching proxy abilities.
DSO
mod_proxy
Provides powerful URI-to-filename mapping using regular
expressions.
DSO
mod_rewrite
Sets environment variables based on client information.
Integrated
mod_setenvif
Provides support for loading modules at run time.
Integrated
mod_so *
Automatically corrects minor typos in URLs.
DSO
mod_speling
Displays server status.
Integrated
mod_status
Generates unique request identifier for every request.
DSO
mod_unique_id
Provides user home directories.
Integrated
mod_userdir
Provides user tracking using Cookies (replacement for
mod_cookies.c).
DSO
mod_usertrack
Provides support for dynamically configured mass virtual hosting.
DSO
mod_vhost_alias
Table A-3SecureWebServer 1.3-Related Modules
Description
DSOorIntegrated
Module
Provides SSLconnections.
DSO
mod_ssl
Provides support for variables in configurationdirectiv es.
DSO
mod_define
Table A-4 AdditionalModul es Provided with the Secure Web Server
Description
DSOorIntegrated
Module
Provides support for authentication with an LDAP database.
DSO
mod_auth_ldap
Supports connections to FastCGIprocesses.
DSO
mod_fastcgi
Provides support for Microsoft'sFrontPage extensions.
DSO
mod_frontpage
Provides the PHP processing engine.
DSO
mod_php4
Provides an interface to Java Servletengines.
DSO
mod_jk
Provides an interface to Java Servletengines.
DSO
mod_jk2
66
Secure WebServer 1.3 Components and Modules
BSecureWebServer 2.0 Components and Modules
Table B-1 lists the major components of the Secure Web Server 2.0 kit, along witha URL for more information
about each component.
Table B-2 lists the Apache 2.0 source distribution standard modules that are provided with the Secure
Web Server2.0. Modules are either provided built into the httpdimageor as Dynamic Shared Objects.
Table B-3 lists other modules provided with the Secure Web Server 2.0.
TableB-1 Secure Web Server 2.0 Components
URL
Description
Component
http://www.apache.org
Apache HTTPServer.
Apache HTTPD
http://www.fastcgi.com
A language-independent, scalable,
open extension to CGI that provides
high performance without the
limitations of server-specific APIs.
fastcgi
http://www.php.net
A server-side, cross-platform HTML
embedded scripting language.
PHP
TableB-2 Standard Secure Web Server 2.0 DS OM odules
Description
Module
Provides access control based on clienthostname, IP address, or other characteristics of
the client request.
mod_access
Provides for executing CGI scripts based on media type or request method.
mod_actions
Provides for mapping different parts of the host file system in the document tree and for
URL redirection.
mod_alias
Sends files that contain their own HTTP headers.
mod_asis
Provides user authentication using text files.
mod_auth
Allows "anonymous"user access to authenticated areas.
mod_auth_anon
Provides for user authentication using DBM files.
mod_auth_dbm
Automatically generates directory indexes similar to the UNIX lscommandorthe Win32
dirshellcommand.
mod_autoindex
Provides content cache, keyed to URIs.
mod_cache
Provides CERN httpdmetafile semantics.
mod_cern_meta
Executes CGIscripts.
mod_cgi
Executes CGIscripts using an external CGI daemon.
mod_cgid
Specifies character set translation or recoding.
mod_charset_lite
MD5 authentication
mod_digest
Provides Distributed Authoring and Versioning (WebDAV) functionality.
mod_dav
Compresses content before it is delivered to the client.
mod_deflate
Provides for"trailing slash"redirects and for serving directory index files.
mod_dir
Provides a simple echo server to illustrate protocol modules.
mod_echo
Modifies the environment which is passed to CGI scripts and SSI pages.
mod_env
Generates Expires HTTP headers according to user-specified criteria.
mod_expires
Passes the response body through an external program before delivery to the client.
mod_ext_filter
Caches astatic list of files in memory.
mod_file_cache
Customizes HTTP request and response headers.
mod_headers
Provides server-sideimagemap processing.
mod_imap
67
TableB-2 Standard Secure Web Server 2.0 DS OM odules ( continued )
Description
Module
Provides for serv er-parsed HTML documents (Server Side Includes)
mod_include
Providesa comprehensive overview of the server configuration.
mod_info
Logs requests made to the server.
mod_log_config
Logs input and output bytes per request.
mod_logio
Associates the requested filename'sextensionswith the file'sbehavior (handlers and
filters) and content (mime-type, language, character set and encoding).
mod_mime
Determines the MIME type of a file by looking at a few bytes of its contents.
mod_mime_magic
Provides for content negotiation.
mod_negotiation
Runs the HTTP/1.1 proxy/gateway server.
mod_proxy
Provides a rule-based rewriting engine to automatically rewrite requested URLs.
mod_rewrite
Allows the setting of environment variables based on characteristics of the request.
mod_setenvif
Loads executable code and modules into the server at start-up or restart time.
mod_so
Attempts to correct mistaken URLsthatusers might have entered by ignoring capitalization
and by allowing up to one misspelling.
mod_speling
Provides strong cryptography using the Secure Sockets Layer (SSL) and Transport Layer
Security (TLS) protocols.
mod_ssl
Provides information on server activity and performance
mod_status
Allows CGIscripts to run as a specified user and group.
mod_suexec
Provides an environmentvariable with a unique identifier for each request.
mod_unique_id
Defines user-specific directories.
mod_userdir
Providesclickstream logging of user activity on a site.
mod_usertrack
Provides support for dynamically configured mass virtual hosting.
mod_vhost_alias
Table B-3 Secure Web Server 2.0-Additional Modules
Description
DSOorIntegrated
Module
Supports connections to FastCGIprocesses.
DSO
mod_fastcgi
Provides the PHP processing engine.
DSO
mod_php4
Provides an interface to Java Servletengines.
DSO
mod_jk
Provides an interface to Java Servletengines.
DSO
mod_jk2
68
Secure WebServer 2.0 Components and Modules
Glossary
Apache Web
Server
A freely available UNIX-based Web server. It is currently the most commonly used server on
Internet connected sites. HP'simplementation of the Apache Web Server is called the Secure
Web Serverfor Tru64 UNIX. For Internet Express Version 6.0 and later, two versions of the
Apache WebServerare offered: 1.3 and 2.0.
certificate
authority
A third party organization that confirms the relationship betweenapartyto the https transaction
and that party'spublickey. Certification authorities maybe widely known and trusted
institutions for Internet-based transactions. Where httpsisused on a company'sinternalnetwork,
an internal department within the company may fulfill this role.
digital certificate A token which underpins the principle of trust in SSL-encrypted transactions. The information
withina certificate includes the issuer (the Certificate Authority that issued the certificate), the
organization that owns the certificate, the public key , the validity period (usually one year) of
the certificate, and the host name for which the certificate was issued. It is digitally signed by
the Certificate Authority so that none of the details can be changed without invalidating the
signature. See also certificate authority , digital signature .
digital signature A use of public key cryptography to authenticatea message. Digital signatures use a private
key to indicate that the signature was made by the owner of that key. See also public key
cryptography , private key .
distinguished
name
Also called DN. Asequenceof relative distinguished names (RDNs). See also relative
distinguished name .
DN
See distinguished name .
DNS
Domain NameSystem. A general-purpose, distributed, replicated data query service chiefly
used on the Internet to translate host names into Internet addresses. See also fully qualified
domain name .
Domain Name
System
See DNS .
dynamic module A module that provides the means for building program codeina format that can be loaded
into the address space of an executable program at run time. Dynamic modules are loaded into
the server process space only when necessary and assure that overall memory usage is reduced.
firewall
Hardware and softw are that lies between two networks, such as an internal network and an
Internetservice provider. Thefirewall protects your network by blocking unwanted users from
gaining access and by disallowing messages to specific recipients outside the network.
FQDN
See fully qualified domain name .
fully qualified
domain name
Also called FQDN. The full name of a system, consisting of its local host name and its domain
name. A fully qualified domain name is usually precise enough to determine an Internetaddress
for any host on the Internet.
HTTP
Hyper TextTransfer Protocol. The protocol used betweena Web browser and a server to request
a document and transfer its contents. The specification is maintained and developed by the
World WideWeb Consortium. See also HTTPS .
HTTPS
Ordinary HTTP exchanged over an SSL -encrypted session.
port
Alogical channel in a communications system.
private key
The part of the key in a public key system that is kept secret and is used only by its owner. This
is the key used for decrypting messages, and for making digital signatures . Compare with
public key .
public key
The part of the key in a public key system which is distributed widely and is not kept secure.
This is the key used for encryption (as opposed to decryption) or for verifying signatures.
Compare with private key .
public key
cryptography
Public key cryptography usesakeyfor encryption and a different key for decryption. Although
the keys are related, it is not possible to calculate the decryption key from only the encryption
key in any reasonable amount of computation time. Inmost practical systems, the public key
69
system is used for encodinga session key which is used with asymmetric system to encode
the actual data. RSA is an example of a public key algorithm.
RDN
See relative distinguished name .
relative
distinguished
name
Also called RDN. One or more attribute/value pairs stored on an LDAP server that uniquely
identify an entry from its sibling in an object tree.
secret key
Part of asymmetric cipher in which the same key is used for encryption and decryption. SSL
encryption usesasecret-key nested withina public key and authenticated through certificates.
Secret-key encryption provides faster access than public-key encryption alone. See also public
key cryptology .
Secure Socket
Layer
See SSL .
session key
A key used for one message or set of messages. In atypical system, a random session key is
generated for use with asymmetric algorithm to encode the bulk of the data. Only the session
key is communicated using public key encryption. See also public key cryptology .
SSL
Secure Socket Layer. A protocol dev eloped by Netscapefor encrypted transmission over TCP/IP
networks. SSL sets up a secure end-to-end link over which http or any other application protocol
can operate. The most common application of SSL is https for SSL-encrypted HTTP.
TCP/IP
Transmission Control Protocol/Internet Protocol. Ethernet protocols incorporated into 4.2 BSD
UNIX. While TCP andIPspecifytwo protocols, the combined term is used to refer to the entire
Department of Defense protocol suite, including Telnetand FTP.
Telnet
The Internetstandard protocol for remotelogins. UNIX BSD includes the telnetprogram, which
uses the protocol, and acts as a terminal emulator for remotelogin sessions.
VeriSign
A dominant certificate authority on the Internet, though many of its certificates are signed as
RSADataSecurity. Early versions of Microsoftand Netscapebrowsers had RSA Data Security
configured as the only trusted certificate authority. This mandated that users who want touse
certificates on the internetmust obtain them from VeriSignanduseserv er software accredited
byVeriSign. Current versions of the Microsoftand Netscapebrowsers allow users to add new
certificate authorities. As older versions of the browsers are replaced, new certificate authorities
(suchasThawte) have emerged.
virtual host
An alias name assigned to an FTP server.
Web server
A server process, running ata Web site, that sends out Web pages in response to HTTP requests
from remote browsers.
70
Glossary
Index
Symbols
/sbin/init.d/tomcat script, 47
A
access log
refreshing, 37
viewing, 35
access.conf configuration file, 20
activity reports
generating, 35
AddModule directive, 44
administration account
default ports, 11
administrator password
managing, 16
Apache1.3 module
standard, 65
Apache2.0 modules
additional, 68
standard, 67
Apache Server
choosing, 12
enabling and disabling, 14
managing different versions, 14
starting and stopping, 14
C
certificate ( see digital certificate)
certificate request
generating, 55
Cluster Application Availability (CAA) resource, 47
configuration file, 19
verification, 44
configuration parameters
access control entries, 22
addingHTML directory aliases, 30
address, 24
CGI directory aliases, 31
changing, 20
deletingHTML directory aliases, 31
HTML directory aliases, 30
listening port, 24
logging and reporting, 31
tuning, 21
URL defaults, 29
virtual hosts, 25
D
daemons
httpd, 37
digital certificate, 17
installing, 58
viewing details, 59
DSO module ( see dynamic module)
dynamic module, 17
activating, 44
activating an Apache DSO, 45
nonstandard Apache, 43
standard Apache, 43
support for, 43
using, 43
usingAddModule directive, 44
usingLoadModule directive, 44
verifying configuration file, 44
Dynamic Shared Objects (DSO) ( see dynamic module)
E
encryption, 17, 53
private key, 54
public key, 17
error log
refreshing, 37
viewing, 35
H
httpd.conf configuration file, 20
httpd_public restart command, 49
J
Java
selecting environment, 48
Java Development Environment kit (JDK), 48
Java Servlet, 17, 47
JAVA_CMD variable
changing, 48
JAVA_HOME variable
changing, 48
JavaServerpages, 17, 47
jscvprogram, 47
JSP Engine, 47
L
LDAP authentication
performing usingSSL, 53
LoadModule directive, 44
log file
Tomcat, 50
M
mod-sslmodules, 66
N
Netscape
SSL, 17
Netscape Server certificate
migrating, 62
migration prerequisites, 62
migration steps, 62
P
password
71
administrator, 16
changing for Secure Web Server, 38
private key
generating, 54
SSL, 53
public Web server
access to HTTPandHTTPS, 61
displaying information, 35
displaying server status, 34
R
remote access, 38
S
secure connection
testing usingSSL, 61
Secure Socket Layer ( see SSL)
Secure WebServer
( see also Secure Web Server 1.3)
( see also Secure Web Server 2.0)
accessing, 11
additional modules-Version 1.3,66
administration functions, 17
components and modules -Version 1.3,65
components and modules -Version 2.0,67
configuration files, 19
controlling, 37
features, 11
managing, 19
overview, 11
remote access to, 38
restarting public, 37
stopping public, 37
support utilities, 15
tuning, 16
Secure WebServer 1.3
mod-sslmodules, 66
standard modules, 65
Secure WebServer 2.0
additional modules, 68
standard modules, 67
security ( see SSL)
server activity reports, 35
server reports
generating, 35
shared library ( see dynamic module)
srm.conf configuration file, 20
SSL, 53
authentication, 17
concepts, 53
considerations for public Web servers, 61
disabling, 60
enabling, 60
enabling from Administration utility, 53
overview, 17
performing encryption, 53
steps for enacting, 53
startup script
detecting Tomcat, 48
T
test certificate
generating, 57
installing, 57
Tomcat, 47
additional information, 51
administration, 50
examples, 51
locating files and directories, 48
log files, 50
manager applications, 50
overview, 17
restarting in non-TruCluster environment, 49
restarting inTruCluster environment, 49
selecting Java environment, 48
starting, 48
starting from Administration Utility, 48
stopping from Administration utility, 48
understanding, 47
using as a standalone public Web server, 47
tomcat start command, 49
tomcat stop command, 49
tomcat/.tomcatrc initialization file, 48
TruCluster
restarting Tomcat, 49
tuning, 16
U
user account
adding, 33
changing public, 33
deleting, 34
modifying, 34
72
Index
pdf