Chapter 1 Overview
The Secure Web Server (powered by Apache) is an implementation of the Apache Software Foundation's (ASF) Apache HTTP server for Tru64 UNIX. It contains a 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's Tomcat Java Servlet and JavaServer Pages (JSP) are provided to handle Java based dynamic content.
The Secure Web Server integrates other features beyond the core modules supplied by ASF, including:
Support for Dynamic Shared Objects (DSO).
Support for SSL connections (HTTPS) using a DSO module.
Support for APXS, which allows third party modules to be built against and used with an installed Secure Web Server.
Support for SUexec, once it is enabled in the server (an additional configuration is required to enable it).
Support for the Atalla hardware accelerator cards.
Support for the Tomcat Java Servlet and Java Server Pages (JSP) container.
In addition, all modules provided with the Apache code base are built-in or provided as a dynamic shared object (DSO).
The Secure Web 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 Server Administration utility (see Section : Accessing the Secure Web Servers).
The Secure Web 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 the Internet 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 HP Web site:
The Secure Web Server provides the following servers for managing Internet services:
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 from a Web browser.
The URL takes the form:
where host.domain.name represents the fully qualified host name of the local system (the system on which Internet Express is installed) and port represents the port Web server is listening on (either Port 80 or 8081).
The Administration Web Server is initially accessible from the local system only. To allow access from a remote system when running the Secure Web Server, see Section : Allowing Remote Access to the Administration Web Server.
To access the Secure Web Servers, follow these steps:
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 Administration server, you are prompted for a user name and password.
Enter a 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 : Managing the Administrator Password. Figure 1-1 shows the Secure Web Server main menu when you first log in.
Figure 1-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 the Web Server Administration menu. In addition to the links for the Administration Web Server and Public Web Server, when you install Apache Version 2.0, an additional link, Manage the Public Web Server 2.0, is displayed.
Figure 1-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 Internet system management tasks.
Choosing a Web Server
For Internet Express 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.
Each Web server has 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 in the URL of the request.
The following sections evaluate each of the Web server options.
The Secure Web 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 Web Server 1.3 Components and Modules).
Use this Web server under the following conditions:
You are running applications where the existing Web content depends on Apache modules that have not been ported to the Apache Version 2.0 API.
You are running an older version of Apache Version 1.3 and you need to minimize transitional risks (i.e., upgrading to a newer version of Apache).
The Secure Web Server 1.3 offers the following strengths:
The Secure Web Server 1.3 offers a proven code base, and provides robust and fault tolerant service.
Most Apache modules were 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 PHP module provided in Apache Version 1.3 contains the most features.
The Secure Web Server 1.3 is easily configured to support SSL connections.
The Secure Web Server 1.3 is supported as a TruCluster multi-instance application.
The Secure Web Server 1.3 has the following weaknesses:
It does not support IPv6.
The Apache Version 1.3 code base is no longer in active development by the Apache Software Foundation.
JSP and Java Servlet requests must be forwarded to Tomcat.
The Secure Web Server 2.0 is powered by the new Apache Version 2.0 code base. Apache Version 2.0 is a 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 for a 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 Secure Web Server 2.0 offers the following strengths:
The new code design uses threads and is intended to provide for more efficient delivery of content.
The Secure Web Server 2.0 supports IPv6.
The Apache Software Foundation is actively developing this code base.
The Secure Web Server 2.0 is easily configured to support SSL connections.
The Secure Web Server 2.0 is supported as a TruCluster multi-instance application.
The Secure Web 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 uses multithreaded programming, all Apache modules (and the libraries they depend on) must also be thread safe.
The PHP module does not include some features that are present in servers based on Apache Version 1.3 due to thread-safety issues of the libraries used by the optional features.
JSP and Java Servlet requests must be forwarded to Tomcat.
The Secure Web Server 2.0 currently does not support FrontPage, and Auth_ldap extensions.
Tomcat Java Servlet and JavaServer Pages Container
The Tomcat Java Servlet and 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 is a full-featured Web server. Choose the Tomcat server when your applications primarily supply Java-based dynamic content in the form of Java Servlet and JavaServer Pages (JSP) with the supporting static Web content.
The Tomcat server has the following strengths:
It provides the fastest handling of Java Servlet and JSP requests.
When used with the Fast Java Virtual Machine and adequate resources, the Tomcat server provides comparable performance to the Apache Web servers.
Using the Tomcat server standalone provides significant improvements to response time, compared to requests forwarded through an Apache Web server to Tomcat.
The Tomcat server has 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 of Tomcat and are recommended primarily for transitional use during the development of a Web application. CGI and SSI can bypass any Java-based security settings that are configured into the Java Security Manager.
The Tomcat server does 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:
The Tomcat server runs as a single instance in a TruCluster.
By default, the Tomcat server does not support running as a non-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.
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 servers 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 to use the same ports while allowing only one version to run.
Table 1-1 lists the commands for managing the Secure Web Server 1.3.
Table 1-1 Command-Line Commands for Managing the Secure Web Server 1.3
|Start the server||/sbin/init.d/httpd_public start|
|Stop the server||/sbin/init.d/httpd_public stop|
|Restart the server||/sbin/init.d/httpd_public restart|
|Start the server on all Cluster Members||/sbin/init.d/httpd_public cluster-start|
|Stop the server on all Cluster Members||/sbin/init.d/httpd_public cluster-stop|
|Restart the server on all Cluster Members||/sbin/init.d/httpd_public cluster-restart|
|Enable the server||/sbin/rcmgr -c set APACHE1 ENABLE|
|Disable the server||sbin/rcmgr -c set APACHE1 DISABLE|
|Check server status||/sbin/rcmgr -c get APACHE1|
Table 1-2 lists the commands for managing the Secure Web Server 2.0.
Table 1-2 Command-Line Commands for Managing the Secure Web Server 2.0
|Start the server||/sbin/init.d/hpapache2 start|
|Stop the server||/sbin/init.d/hpapache2 stop |
|Restart the server||/sbin/init.d/hpapache2 restart|
|Start the server on all Cluster Members||/sbin/init.d/hpapache2 cluster-start|
|Stop the server on all Cluster Members||/sbin/init.d/hpapache2 cluster-stop|
|Restart the server on all Cluster Members||/sbin/init.d/hpapache2 cluster-restart|
|Enable the server||/sbin/rcmgr -c set APACHE2 ENABLE|
|Disable the server||/sbin/rcmgr -c set APACHE2 DISABLE|
|Check server status||/sbin/rcmgr -c get APACHE2|
Table 1-3 lists the commands for managing the Tomcat Web server.
Table 1-3 Command-Line Commands for Managing the Tomcat Web Server
|Start the server in a TruCluster environment||caa_start tomcat|
|Start the server||/sbin/init.d/tomcat start|
|Stop the server in a TruCluster environment||caa_stop tomcat|
|Stop the server||/sbin/init.d/tomcat stop|
|Enable the server||/sbin/rcmgr -c set TOMCAT ENABLE|
|Disable the server||/sbin/rcmgr -c set TOMCAT DISABLE|
|Check server status||/sbin/rcmgr -c get TOMCAT |
Migration Utilities for the Secure Web Server
This section describes the following utilities for migrating the iPlanet Web Server to the HP Secure Web Server for Tru64 UNIX:
certmig — Migrates iPlanet 4.x certificates to the Secure Web Server. This utility, an extension of the PK12UTIL utility provided by the Mozilla community, uses Network Security Services (NSS) libraries to convert iPlanet certificates, key translations, and certificate chains to those of the Apache Web Server.
test_certmig.sh — Provides a wrapper around certmig for importing and extracting the list certificates in an iPlanet 4.1.x Certificate 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 Apache 2.0.
Tuning Tru64 UNIX for the Secure Web Server
Proper system tuning can have a significant impact on the performance of the Secure Web Servers. The Secure Web Server software includes the kerneltuner shell script that sets the primary tuning recommendations for Internet server performance. These recommendations are described in the Tuning Tru64 UNIX for Internet Services manual, available from the following URL:
Additional system performance tuning settings are also described in this document.
The kerneltuner utility is installed in the bin subdirectory under the Web server root directory for each Secure Web Server Public Web server. Run this utility as root. For example:
# su root
# cd /usr/opt/hpapache2/bin
The above example runs the kerneltuner 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 kerneltuner utility with the -s command line option:
# /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 TruCluster member 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 the kerneltuner utility, or you can wait for a more convenient time.
Managing the Administrator Password
During installation of the Secure Web Server, a single Web administration user is created for accessing all Administration Web Server instances. The username is 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 (Section : Changing the Password for the Administration Web Server).
If you received your Secure Web Server software preinstalled from HP or if you have forgotten your administrator password, the /usr/internet/httpd/bin/dbmmange command 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:
Login as the root user, then run the following command:
# /usr/internet/httpd/bin/dbmmanage /usr/internet/httpd/userdb/admin adduser admin
The dbmanage command initializes the database (if needed) and prompts you for a 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 the dbmanage command as follows (note that adduser is now update):
# /usr/internet/httpd/bin/dbmmanage /usr/internet/httpd/userdb/admin update admin
The command prompts you for a password and updates the database.
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
All Secure Web Server administration functions are performed using Port 8081. All activity is recorded in the associated log files (Section : 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.
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.
Tomcat, provided with the Secure Web Server, is a Java Servlet and JavaServer Pages (JSP) container developed by the Apache Software Foundation's Jakarta project. 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 Servlet and JSP pages to the Tomcat container.
Chapter 4 describes how to start Tomcat, use the Tomcat examples, and locate Tomcat directories and files.
The Secure Web 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 provides privacy, 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 also provides authentication through digital certificates that are generated for SSL, although the source of digital certificates might not always be credible for online payment transactions. Secure Web Server SSL encryption uses a secret key nested within public key encryption and authenticated through digital certificates.
Chapter 5 describes the administration functions that you perform to enable SSL on your server:
Generating a private key.
Generating a request for a 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.