iTP Secure WebServer System Administrator’s Guide Abstract This guide describes how to install, configure, and manage the iTP Secure WebServer. It also discusses how to develop and integrate Common Gateway Interface (CGI) applications and Java servlets into an iTP Secure WebServer environment. This guide is intended for experienced Compaq system administrators and operators who need to install, configure, and manage the iTP Secure WebServer on a Compaq system.
Document History Part Number Product Version Published 142615 iTP Secure WebServer D42 (Release 3.3) March 1999 422876-001 iTP Secure WebServer D42 (Release 4.0) July 1999 425144-001 iTP Secure WebServer D42 (Release 4.1) February 2000 427022-001 iTP Secure WebServer (Release 5.0) December 2000 429506-001 iTP Secure WebServer (Release 5.1) August 2001 522659-001 iTP Secure WebServer (Release 5.1) November 2001 Ordering Information For manual ordering information: domestic U.S.
iTP Secure WebServer System Administrator’s Guide Glossary Index Examples Figures What’s New in This Manual xxiii Manual Information xxiii New and Changed Information xxiv About This Guide xxvii Who Should Read This Guide xxvii Organization of This Guide xxviii Related Manuals Bibliography xxix xxxiii Reference Information on the Internet xxxiv Your Comments Invited xxxiv Notation Conventions xxxv Abbreviations xxxviii 1.
1. Introduction to the iTP Secure WebServer (continued) Contents 1. Introduction to the iTP Secure WebServer (continued) Administration Server 1-9 Other Products for the iTP Secure WebServer Environment 1-10 1-10 iTP Secure WebServer Encryption Secure Sockets Layer (SSL) and Private Communications Technology (PCT) Encryption 1-10 WebSafe2 Encryption 1-10 2.
3. Planning the iTP Secure WebServer PATHMON Environment (continued) Contents 3.
5. Integrating the WebSafe2 Internet Security Processor (WISP) Contents 5.
6. Managing the iTP Secure WebServer Using Scripts (continued) Contents 6. Managing the iTP Secure WebServer Using Scripts (continued) For Parallel Library TCP/IP Support: For Classical TCP/IP Support: 6-3 6-3 Restarting the iTP Secure WebServer Using the restart Script 6-5 Using the httpd Command 6-5 Syntax 6-5 Description 6-6 PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes 6-7 7.
7. Configuring the iTP Secure WebServer (continued) Contents 7.
8. Using Common Gateway Interface (CGI) Programs (continued) Contents 8.
9. Using NonStop Servlets for JavaServer Pages With The iTP Secure WebServer (continued) Contents 9.
9. Using NonStop Servlets for JavaServer Pages With The iTP Secure WebServer (continued) Contents 9.
10. Using the Resource Locator Service (RLS) (continued) Contents 10. Using the Resource Locator Service (RLS) (continued) Modifying the Database 10-5 Building and Installing the Resource Locator Service (RLS) 10-6 11.
A. Configuration Directives Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A. Configuration Directives (continued) Example A-92 SK_GlobalCacheTimeout A-93 Syntax A-93 Description A-93 Default A-93 A-93 Example User A-94 Syntax A-94 Description A-94 Default A-94 Example UserDir A-94 A-95 Syntax A-95 Description A-95 Default A-96 Example A-96 WidTimeout A-97 Syntax A-97 Description A-97 Default A-97 Example A-97 B. Error Messages C.
D. Security Concepts (continued) Contents D. Security Concepts (continued) Cryptographic Techniques D-3 Secret Key Systems D-3 Public Key Systems D-3 Managing Key Certificates Using Certificates D-5 D-6 Obtaining Certificates D-7 Secure Sockets Layer (SSL) D-7 What SSL Does D-7 SSL 3.0 Protocol Enhancements Over SSL 2.0 Deploying SSL D-8 Private Communications Technology (PCT) Comparing SSL and PCT Design Goals D-8 D-9 D-9 D-9 Relative Advantages D-9 E.
Examples (continued) Contents Examples (continued) Example 7-5. Sample WID Configuration File 7-56 Example 7-6. Sample WebSafe2 Configuration File Example 8-1. Server MIME Types 8-8 Example 8-2. Sample cgilib.h File 8-33 Example 8-3. Sample Pathway CGI Program 8-34 Example 10-1. RLS Server Class Definition 7-57 10-2 Figures Figure 1-1. iTP Secure WebServer Architecture 1-6 Figure 4-1. Cipher Negotiation Between Web Client and Server Lists 4-31 Figure 5-1.
Figures (continued) Contents Figures (continued) Figure D-3. Certificate Chain D-6 Tables Table 4-1. Common Distinguished Name (DN) Attributes 4-5 Table 7-1. Required Log-File Space 7-24 Table 7-2. Region Directive Variables 7-39 Table 7-3. SSI Environment Variables 7-54 Table 8-1. Environment Variables Table 8-2. Pathway Specific Environment Variables Table 8-3. Environment Variable Access Methods Table 8-4. Sample HTTP Header Variables Table 8-5.
Contents iTP Secure WebServer System Administrator’s Guide —522659-001 xxii
What’s New in This Manual Manual Information iTP Secure WebServer System Administrator’s Guide Abstract This guide describes how to install, configure, and manage the iTP Secure WebServer. It also discusses how to develop and integrate Common Gateway Interface (CGI) applications and Java servlets into an iTP Secure WebServer environment. This guide is intended for experienced Compaq system administrators and operators who need to install, configure, and manage the iTP Secure WebServer on a Compaq system.
What’s New in This Manual New and Changed Information New and Changed Information This edition of the iTP Secure WebServer System Administrator’s Guide contains new and changed information about the following features: • Parallel Library TCP/IP Support. You can now use either conventional TCP/IP support or the new Parallel Library TCP/IP support as the transport service for the iTP WebServer.
About This Guide This guide describes the installation, configuration, and management of the Internet Transaction Processing (iTP) Secure WebServer. It covers the nonsecure version (iTP WebServer) along with the exportable and nonexportable versions of the iTP Secure WebServer. For simplicity, all three versions are referred to as iTP Secure WebServer throughout the guide. This guide provides an overview of the iTP Secure WebServer environment and World Wide Web concepts.
About This Guide • • • Organization of This Guide You are familiar with writing and using configuration scripts. You are familiar with the TCP/IP family of protocols. You are familiar with network security and authentication techniques. This guide also assumes that you have experience operating a secure computing system. For an introduction to basic network security concepts, refer to Appendix D, Security Concepts.
About This Guide Related Manuals Section 10, Using the Resource Locator Service (RLS), describes how to use RLS to implement replicated web servers. Section 11, Administering Session Identifiers for Anonymous Sessions, describes how to use the ticketing services of the iTP Secure WebServer.
About This Guide TCP/IP Manuals TCP/IP Manuals For information specific to managing the TCP/IP subsystem, refer to the following manuals: • • • TCP/IP Configuration and Management Manual describes the installation, configuration, and management of the Compaq TCP/IP subsystem. It is for system managers, operators, and others who require a basic understanding of the Compaq TCP/IP implementation.
About This Guide WebSafe2 Manuals WebSafe2 Manuals For detailed information about WebSafe2, refer to the following Atalla manuals: • • WebSafe2 Internet Security Processor Installation and Operations Manual (domestic edition) WebSafe2 Internet Security Processor Installation and Operations Manual (export edition) NonStop Java Manuals For information about the features of the Compaq NonStop Server for Java, refer to the following Compaq manual: • NonStop Server for Java (NSJ) Programmer’s Guide And t
About This Guide • • Bibliography Himalaya S-Series Planning and Configuration Guide describes how to plan and configure a Himalaya S-series server and provides a case study documenting a sample system. This guide describes the ServerNet system area network (ServerNet SAN), the available hardware and software configurations for Himalaya S-series servers, site planning and preparation, creating the operational environment, and making hardware and software configuration changes to an existing server.
About This Guide Reference Information on the Internet The following publication is a useful sources of information about programming Java Servlets and the J2EE environment, which is discussed in Section 9, Using NonStop Servlets for JavaServer Pages With The iTP Secure WebServer: • Subrahmanyam Allamaraju, et al. Professional Java Server Programming (J2EE Edition). Wrox Press Ltd, 2000.
About This Guide Notation Conventions Many of the improvements you see in manuals are a result of suggestions from our customers. Please take this opportunity to help us improve future manuals. Notation Conventions Hypertext Links Blue underline is used to indicate a hypertext link within text. By clicking a passage of text with a blue underline, you are taken to the location described. For example: This requirement is described under Backup DAM Volumes and Physical Disk Drives on page 3-2.
About This Guide General Syntax Notation [ ] Brackets. Brackets enclose optional syntax items. For example: TERM [\system-name.]$terminal-name INT[ERRUPTS] A group of items enclosed in brackets is a list from which you can choose one item or none. The items in the list may be arranged either vertically, with aligned brackets on each side of the list, or horizontally, enclosed in a pair of brackets and separated by vertical lines.
About This Guide Change Bar Notation Item Spacing. Spaces shown between items are required unless one of the items is a punctuation symbol such as a parenthesis or a comma. For example: CALL STEPMOM ( process-id ) ; If there is no space between two items, spaces are not permitted. In the following example, there are no spaces permitted between the period and any other items: $process-name.
About This Guide Abbreviations CN. Common Name CRL. Certificate Revocation List CWD. Current Working Directory DES. Data Encryption Standard DN. Distinguished Name DNS. Domain Name Server EMS. Event Management Service (Compaq) FBA. Forms Based Administration FTP. File Transfer Protocol GIF. Graphics Interchange Format GUI. Graphical User Interface HTML. HyperText Markup Language HTTP. HyperText Transfer Protocol HTTPD. HyperText Transfer Protocol Daemon IEEE.
About This Guide Abbreviations LAN. local area network MAC. Message Authentication Code MD5. Message Digest MFK. Master File Key MIME. Multiple Internet Mail Extensions NCSA. National Center for Supercomputing Applications O. Organization OLTP. Online Transaction Processing OSS. Open System Services OU. Organizational Unit PAID. Process Accessor ID PCT. Private Communication Technology PDF. Portable Document Format PEM. Privacy Enhanced Message PKS. Public Key Certificate Standard PPP.
About This Guide SI. Abbreviations Session Identifier SLIP. Serial Line IP SMTP. Simple Mail Transfer Protocol SSC. Servlet Server Class (for Java) SSI. Server Side Include SSL. Secure Sockets Layer ST. State TACL. Tandem Advanced Command Language TAL. Transaction Application Language Tcl. Tool Command Language Tcl/CGI. Tool Command Language/Common Gateway Interface TCP/IP. Transmission Control Protocol/Internet Protocol TS/MP. Transaction Services/Massively Parallel URL. Uniform Resource Locator WID.
About This Guide Abbreviations iTP Secure WebServer System Administrator’s Guide —522659-001 xxxviii
1 Introduction to the iTP Secure WebServer The iTP Secure WebServer provides a full range of services for running an online commercial or informational enterprise on the Web. In addition to basic web-related services, the iTP Secure WebServer provides other important services including access control, enhanced logging, customized error messaging, and automatic directory indexing.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer Extensibility You can enrich your WebServer environment by creating applications that use CGI, Java Servlets and Java Server Pages. The iTP Secure WebServer supports both conventional CGI applications and persistent applications by using the parallel processing benefits of NonStop TS/MP. You can write applications in any of several popular programming languages, including Java.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer Microsoft Private Communications Technology (PCT version 1) protocol The set of protocols that can be supported by a single instance of the iTP Secure WebServer now consists of HTTP, SSL, and PCT. • • • • Caching of session keys, encompassing all the secure transport protocols, including PCT, SSL 2.0, and SSL 3.0.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer Session tracking and authentication The iTP Secure WebServer includes built-in support for ticketing, a technique for user-session tracking. The iTP Secure WebServer issues anonymous tickets. You can use the iTP WebReporter log-analysis tool to generate reports detailing user-access patterns.
Introduction to the iTP Secure WebServer iTP Secure WebServer Architecture A browser or web client uses the OPTIONS request method to determine the options and/or requirements associated with a resource, or the capabilities of a server, without necessarily retrieving or acting on the resource. A browser or web client uses the TRACE method to see the data that is being received at the other end of the request chain. The data can then be used for testing or diagnostic information.
iTP Secure WebServer Architecture Introduction to the iTP Secure WebServer Figure 1-1.
Introduction to the iTP Secure WebServer Web Clients Web Clients Web clients, such as browsers, are programs that provide a graphical user interface (GUI) to web servers such as the iTP Secure WebServer. TCP/IP Subsystem The Compaq TCP/IP subsystem allows processes on a NonStop System to communicate using the TCP/IP protocol. There are two versions of TCP/IP support available; Conventional and Parallel Library. Conventional TCP/IP In essence, one listening process per port.
Introduction to the iTP Secure WebServer iTP Secure WebServer httpd iTP Secure WebServer httpd The iTP Secure WebServer httpd has two main functions: • • A file server. The httpd process transfers and stores files, such as HTML documents. A message-switching facility. The httpd process forwards messages from web clients to application programs. The httpd process is implemented as a server class in NonStop TS/MP.
Introduction to the iTP Secure WebServer Pathway CGI Server Pathway CGI Server The Pathway CGI extensions are a set of utility procedures that let you develop CGI applications as NonStop TS/MP server classes or integrate existing NonStop TS/MP applications into the iTP Secure WebServer environment. Generic Common Gateway Interface (CGI) Server CGI is a standard for applications that interface with web servers.
Introduction to the iTP Secure WebServer iTP Secure WebServer Encryption iTP Secure WebServer Encryption The iTP Secure WebServer can use three types of encryption: • • • Secure Socket Layer (SSL) encryption Private Communications Technology (PCT) encryption WebSafe2 encryption Secure Sockets Layer (SSL) and Private Communications Technology (PCT) Encryption Because the iTP Secure WebServer complies with the SSL 3.0 and PCT standards, the ability to use SSL and PCT encryption is built in.
2 Installing the iTP Secure WebServer This section describes what you need to do to prepare your Compaq system to run the iTP Secure WebServer and explains how to install and configure it. It also provides a test procedure that you can use to verify configuration and to perform server testing. iTP Secure WebServer System Requirements The iTP Secure WebServer runs on a variety of Compaq systems and is supported by standard Compaq subsystems and local area network (LAN) controllers.
Installing the iTP Secure WebServer • • • Required Hardware NonStop TS/MP subsystem, with PATHMON and Pathsend features, version D40 or later. For information on installing and configuring this subsystem, refer to the TS/MP System Management Manual. NonStop SQL/MP D42 or later, including TSQLEXE, TSQLCAT, TSQLUTI, and TSQLFIL. This product is required only if you will be using the Resource Locator Service (RLS). NonStop Server for Java D42 or later.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer This section describes the steps necessary to prepare your NonStop system for the iTP Secure WebServer. The iTP Secure WebServer is set up to come up out-of-box and run on TCP/IP process $ZTC0 using a port that is configured during the installation process. You can use multiple TCP/IP processes in the same iTP Secure WebServer environment. 1.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer Use One TCPSAM Process Ensure that there is one TCPSAM process pair running on any two CPUs in the system. It is recommended that you use only one TCPSAM process pair - even where you are using more than one IP address. Unlike the conventional TCP/IP processes, one TCPSAM process can provide socket interfaces for all IP addresses configured in the Parallel Library TCP/IP environment.
Installing the iTP Secure WebServer Event Management Service (EMS) Template Installation You Can No Longer Use Restarth Because the new product architecture no longer has a distributor working as a buffer zone between the incoming connection requests and the httpd servers, new servers cannot successfully bind to a local port unless the older httpd servers cease their operations. Therefore the -restarth option is no longer supported if you are using Parallel Library TCP/IP. 4.
Installing the iTP Secure WebServer Installing and Configuring the iTP Secure WebServer 3.
Installing the iTP Secure WebServer Copy the Files Copy the Files Copy the product files to <$ISV>.ZOSSUTL (if you have a product CD, see the README.TXT file for instructions specific to moving files from the product CD with FTP). If you will also be installing a new WebSafe2 Internet Security Processor (WISP), with the iTP Secure WebServer, then you must also copy the product files for the WebSafe Interface Driver (WID; T7951). Unpax the Files On the Compaq NonStop™ system, logon as SUPER.
Installing the iTP Secure WebServer Run the Setup Script For example: TACL> LOGON SUPER.WEB TACL> OSH OSS: cd /usr/tandem/webserver/ OSS: ./setup [] The installation script walks you step-by-step through the installation of the Administration Server, the iTP Secure WebServer, and, by default, installs the product into the /usr/tandem/webserver directory.
Installing the iTP Secure WebServer Run the Setup Script If you wish to use a TCPSAM process other than the one in the list, please follow the manual configuration procedures. Do you wish to use ONLY the Parallel Library TCPIP as your transport services? Type y/n (Default: n) #: y Looking up running TCPSAM process on your system...please wait You can use the conventional TCP/IP support, the Parallel Library support, or both.
Installing the iTP Secure WebServer Install a WISP Install a WISP After you install the iTP Secure WebServer, you may also install a WISP by running install.WS, which is provided in the /admin/conf directory, with the -websafe option; doing so adds the WISP configuration information to the existing iTP Secure WebServer configuration file, and the script properly configures the WID and iTP Secure WebServer for WISP operations.
Installing the iTP Secure WebServer Verifying the Configuration Verifying the Configuration Use the OSS file system to verify that the installation was successful. You should see the following directory structure at the installation directory. The default directory is /usr/tandem/webserver: /bin Contains all binary files related to the iTP Secure WebServer. /root This is the root that appears when you use the default configuration. A sample home page (index.sample.html) exists here.
Installing the iTP Secure WebServer Test-Starting the Administration Server and the iTP Secure WebServer Note. Certain versions of Microsoft Internet Explorer do not accept self-signed test certificates. Test-Starting the Administration Server and the iTP Secure WebServer Use the following procedure to verify your configuration: 1. Start the Administration Server by executing the start script: : cd /usr/tandem/webserver/admin/conf : ./start 2.
3 Planning the iTP Secure WebServer PATHMON Environment This section provides background for configuring the iTP Secure WebServer PATHMON environment.
Planning the iTP Secure WebServer PATHMON Environment Parallel Library TCP/IP: The Auto Accept Feature For more information about the OSS environment, refer to the Open System Services User’s Guide. For more information about the Pathway environment, refer to the NonStop TS/MP System Management Manual. Parallel Library TCP/IP: The Auto Accept Feature Running with the Auto-Accept feature, an iTP WebServer no longer needs its Distributor component.
Planning the iTP Secure WebServer PATHMON Environment Configuring the PATHMON Environment Because the httpd servers are now picking the new connections by themselves, removing an httpd server may disrupt the pending new connections (those connection requests have been forwarded to the httpd server and has not yet picked up by the httpd server). Unfortunately, the PATHWAY is unaware of these pending connections and may remove a dynamic server when it has no more links with the Link Manager.
Planning the iTP Secure WebServer PATHMON Environment Threading Considerations for the httpd Server are essential in the Compaq environment for the iTP Secure WebServer. The configuration file creates a PATHMON process and configures the application servers and the Distributor process. Refer to Appendix A, Configuration Directives, for detailed descriptions of all the configuration directives you can specify in the server configuration file (httpd.config).
Planning the iTP Secure WebServer PATHMON Environment • Security for the Server’s Pathway Environment No system dispatching is required to switch among threads in the same process. Assigning a larger number of processes with a lower number of threads per server has different benefits: • • Increased load balancing across CPUs Less susceptibility to CPU and process failures, and better fault isolation The TANDEM_RECEIVE_DEPTH environment variable has no meaning for server classes other than httpd.
Planning the iTP Secure WebServer PATHMON Environment What TCP/IP Port Is the Distributor Process Monitoring? What TCP/IP Port Is the Distributor Process Monitoring? In its default, out-of-box configuration, the Distributor process monitors TCP/IP port number 80. To use a different port, modify the port specification in the httpd.config file. The Distributor process also can monitor multiple ports. For example, in the httpd.stl.
Planning the iTP Secure WebServer PATHMON Environment Other Security Considerations Other Security Considerations In addition to the security of the PATHMON environment, the system administrator should consider the following security requirements before installing the iTP Secure WebServer: • • • • Protecting the Key Database File (See page 3-7) Protecting the Server Password (See page 3-7) Protecting Core Dumps (See page 3-8) Protecting Transmission of Key Database Files and Core Dumps (See page 3-8) P
Planning the iTP Secure WebServer PATHMON Environment Protecting Core Dumps The iTP Secure WebServer installation requires the server password to be eight characters or longer. In addition, the keyadmin utility also requires passwords to be either mixed case or all uppercase. If your password is stored in the configuration file or another file, protect that file at least as carefully as you would the key database file itself.
4 Configuring for Secure Transport The Secure Sockets Layer (SSL) and Microsoft Private Communications Technology (PCT) protocols provide security enhancements for the Web. These enhancements include encryption, for ensuring privacy, and authentication (using key certificates), for verifying the identity of servers, and, optionally, clients. This section explains how to prepare the iTP Secure WebServer to use encryption provided by SSL, PCT, or both.
Configuring for Secure Transport Overview of Server Configuration Region /admin/* { RequireSecureTransport AllowHost *.company.com RequirePassword {WebServer Administration User}\ -userfile /conf/adm.passwd IndexFile index.html } For even greater security, choose the -auth option of the RequireSecureTransport directive to require that a web client certificate be presented when accessing the administration area.
Configuring for Secure Transport Server Configuration Server Configuration Once you have used the keyadmin utility for server configuration, complete the server configuration by following these steps: 1. Specify the pathname of the key database file by using the KeyDatabase configuration directive. Refer to KeyDatabase on page A-24 for information about using this directive. 2. Specify the password for decrypting the key database file.
Configuring for Secure Transport Managing Certificates 6. Include security properties in HTML documents. Use the HTTPS protocol specifier (https) in anchor specifications to tell the web client that SSL or PCT should be used, as the following example shows: https://www.oregon-club.com/recipes If you are using an SSL or PCT port other than the default (443), specify the port: https://www.oregon-club.
Configuring for Secure Transport Support for International 128-Bit SSL Sessions Using VeriSign’s Global Server ID Table 4-1 lists and describes the most common DN attributes. Table 4-1. Common Distinguished Name (DN) Attributes Attribute Description CN Common Name: The name of the owner of the certificate. OU Organizational Unit: The name of the owner’s organizational subdivision. DNs can include multiple OUs. An example of multiple OUs is shown after this table.
Configuring for Secure Transport Support for International 128-Bit SSL Sessions Using VeriSign’s Global Server ID Global Server IDs allow you to conduct a variety of secure transactions using 128-bit SSL encryption.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates You can continue using other server IDs along with your Global Server ID in order to provide services to browsers and other clients that do not support Global Server IDs. Using the Keyadmin Utility to Manage Keys and Certificates The keyadmin utility is used to generate key pairs and to manage certificates in the server key database file.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates To generate a new key pair, use the keyadmin command shown below. If you are going to use this certificate with the WebSafe2 unit, the keyadmin commands you use are somewhat different. For information about generating a key pair for use with a WebSafe2 unit, see Step 2. Generating a Public/Private Key Pair and a Certificate Request on page 5-10. You may enter the arguments in any order.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -verbose specifies that complete information associated with the command string should be displayed. The keyadmin utility prompts you to enter the password associated with the key database file. After you enter the key database file password, the keyadmin utility creates the private and public parts of a new key pair, stores them in the key database file, then binds this key pair to the DN you specified.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -dn 'dn' specifies the full DN for the new key pair. Enclose this DN with apostrophes (') to protect it from being interpreted by the shell. Make sure to include the same field values entered on the CA request form and in the exact order that the CA specifies. Also, enclose any value containing a comma with quotation marks (").
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Adding a Certificate to the Key Database File When you receive a certificate from a CA, install it in your server’s key database file and remove any hidden characters it contains (such as line-feed characters). To add a certificate, use the keyadmin command shown below. If you are going to use this certificate with the WebSafe2 unit, the keyadmin commands you use are somewhat different.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -force specifies that a renewal of an older certificate should occur, as specified through the -renew option, but that the check for a valid start date should not be performed. -root treats the certificate as a root. -verbose specifies that complete information associated with the command string should be displayed. A sample command is as follows: bin/keyadmin -keydb conf/mykeys -addcert my-cert.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-1 shows an example of a certificate is in PKCS #7 format: Example 4-1.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates The command’s arguments have the following functions: -keydb keydb specifies the name of the key database file in which the key pair you created is stored. -delete specifies that a certificate and key pair should be deleted from the server’s key database file. -dn 'dn' specifies the full DN for the new key pair. Enclose this DN with apostrophes (') to protect it from being interpreted by the shell.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates The command’s arguments have the following functions: -keydb keydb specifies the name of the key database file in which the key pair you created is stored. -disable specifies that you wish to disable a certificate in the key database file. The certificate remains in the key database file so that it can be enabled, as required, at a later time.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates The command’s arguments have the following functions: -keydb keydb specifies the name of the key database file in which the key pair you created is stored. -chpw specifies that you wish to change the password. -verbose specifies that complete information associated with the command string should be displayed. The keyadmin utility prompts you for the new password.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -list specifies that you wish to generate a list of keys and certificates. -dn 'dn' specifies that only the entry indicated by dn be displayed. -root specifies that only entries marked as root should be displayed. -nonroot specifies that only the entries not marked as root be displayed. -disabled specifies that only disabled entries be displayed. -enabled specifies that only enabled entries be displayed.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates If you specify keyadmin -list for a nonexistent key database file, the command will list only the built-in roots that ship with the utility. Updating the Default Root Certificates The iTP Secure WebServer supports a set of default root certificates for domestic use (United States and Canada).
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-2.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-2. Example Default Root Certificate (page 3 of 4) ----------------------------------Distinguished Name OU: Persona Certificate O: RSA Data Security, Inc.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-2. Example Default Root Certificate (page 4 of 4) ----------------------------------Distinguished Name CN: Open Market, Inc.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Exporting a Database Entry You can request that an entry from a specified key database file be written to any file name that you specify. Then you can use the new file as a key database file. You may enter the arguments in any order. Enter the entire command on a single command line.
Configuring for Secure Transport Using Server Certificate Chains With the iTP Secure WebServer If you specify -nooverwrite, keyadmin generates a message to indicate that the entry was not overwritten. Displaying Keyadmin Utility Information You can display information about keyadmin by issuing the following keyadmin command: bin/keyadmin -version [-verbose] Note. The bin/ prefix indicates the directory that contains the keyadmin utility; the default is the bin directory.
Configuring for Secure Transport Managing Client Authentication 2. Note that when a certificate chain is sent from VeriSign, the leaf certificate is the certificate that follows the text SERVER SUBSCRIBER CERTIFICATE, and the intermediate certificate is the certificate that follows the text INTERMEDIATE CA CERTIFICATE. 3.
Configuring for Secure Transport Using the -requireauth Option 2. Attempts to back-build the internal certificate chain by retrieving issuer certificates from the certificate database and adding them to the internal certificate chain. The chain is built until the server either retrieves a certificate that is marked as root from the database or it cannot find an issuer of a certificate on the chain in the database. 3.
Configuring for Secure Transport Updating SSL and PCT Configuration Issuer certificate not CA type The server requested client authentication and received a client certificate chain that contains X509 version 3 certificates, but one or more of the issuer certificates do not have CA privilege (indicated by the issuer certificate containing the Basic Constraints extension with the subject type set to END_ENTITY).
Configuring for Secure Transport Updating SSL and PCT Configuration Example 4-3. Sample Secure Transport httpd.stl.config File # httpd.stl.config # Configure the required Secure Transport information # # Disable transmission of SSLv3 close_notify alert messages to # Microsoft browsers. # Region /* { if {[info exists HEADER(user-agent)] && [string match "*MSIE*" $HEADER(user-agent)]} { DisableCloseNotify } } KeyDatabase $root/conf/test_key.
Configuring for Secure Transport Controlling Access and Privacy Controlling Access and Privacy With SSL and PCT, all connections between a web client and the server are encrypted. A web client can verify the server’s identity by using the server’s public-key certificate. As described previously, you also can request or require a web client to authenticate itself to the server.
Configuring for Secure Transport Using SSL and PCT Environment Variables in CGI Programs Following is another example, using the web client’s DN: set goodusers {CN=User 1, OU=Persona Certificate,\ O="RSA Data Security, Inc.", C=US} lappend goodusers {CN=User 2, OU=Persona Certificate,\ O="RSA Data Security, Inc.
Using Ciphers With the AcceptSecureTransport Directive Configuring for Secure Transport Hashing Ciphers Used by iTP Secure WebServer Ciphers The ciphers for secure transport ports within the iTP Secure WebServer can use two different hashing algorithms. The first, called MD5, has been in wide use for many years in various Internet applications. The other, called Secure Hash Algorithm (SHA1), was developed by the U.S. government. For most applications, either cipher provides sufficient security.
Configuring for Secure Transport Constraints on Cipher Use Constraints on Cipher Use The iTP Secure WebServer imposes the following constraints: • • The nonexportable version of the iTP Secure WebServer supports the RC4/RC2 ciphers that have either 40-bit or 128-bit keys. The exportable version of the iTP Secure WebServer supports the RC4/RC2 ciphers that have 40-bit keys only. The actual key used depends on the web client’s choice.
Configuring for Secure Transport Constraints on Cipher Use iTP Secure WebServer System Administrator’s Guide —522659-001 4- 32
5 Integrating the WebSafe2 Internet Security Processor (WISP) Follow the instructions in this section if you need to prepare the iTP Secure WebServer to use Atalla WebSafe 2 Internet Security Processors (WISPs). Notes. You cannot simultaneously use Secure Sockets Layer (SSL) 3.0 and Private Communication Technology (PCT). To use SSL 3.0 with a WISP, you must run WISP firmware version 2.6.11 or later and WID software IPM AAC or later.
Integrating the WebSafe2 Internet Security Processor (WISP) Figure 5-1. WebSafe2 Internet Security Processors (WISPS) in an iTP Secure WebServer Environment NonStop Kernel iTP Secure WebServer 3615 Ethernet LAN Controller Web Clients WebSafe2 Interface Driver (WID) 3615 Ethernet LAN Controller WebSafe2 Internet Security Processors (WISPs) CDT012.
Integrating the WebSafe2 Internet Security Processor (WISP) The Secure Configuration Terminal (SCT) The iTP Secure WebServer’s SSL 3.0 protocol using WebSafe2 encryption allows you to send and receive certificate chains to and from the iTP Secure WebServer. For information about sending and receiving certificate chains, see How to Use Server Certificate Chains With WebSafe2 Encryption on page 5-16.
Integrating the WebSafe2 Internet Security Processor (WISP) Fault-Tolerance Requirements Figure 5-2. Setting Up Secure Communication Using a WebSafe2 Internet Security Processor (WISP) NonStop Kernel SSL Handshake Protocol Distributor Process Web Client {master key} Public Key iTP Secure WebServer WID {text } text {decrypted master key} KEK WID=WebSafe2 Interface Driver encryption key encrypted message WebSafe2 Internet Security Processor (WISP) CDT014.
Integrating the WebSafe2 Internet Security Processor (WISP) How to Integrate WebSafe2 Internet Security Processors (WISPs) How to Integrate WebSafe2 Internet Security Processors (WISPs) You should add the WISP to an iTP Secure WebServer environment that has already been operating so that you can isolate problems more easily.
Integrating the WebSafe2 Internet Security Processor (WISP) If You Are Upgrading the WebSafe2 Internet Security Processor (WISP) From An Earlier Version 7. Complete the quickstart procedure to verify installation and configuration. See Verifying Integration of a WebSafe2 Internet Security Processor (WISP) on page 5-15. If the server has been operating, it will have to be restarted before configuration changes take effect.
Integrating the WebSafe2 Internet Security Processor (WISP) Installing the WebSafe2 Interface Driver (WID) Installing the WebSafe2 Interface Driver (WID) Install the WID software by unpaxing the file T7951PAX using the following command: $ISV.ZOSSUTL.COPYOSS $ISV.ZOSSUTL.T7951PAX where: ISV is your installed volume. COPYOSS ensures that all files in the archive are placed in the /user/tandem/webserver directories.
Integrating the WebSafe2 Internet Security Processor (WISP) Configuring the iTP Secure WebServer for WebSafe2 Internet Security Processors (WISPs) Example 5-1 contains an example of a running install.WS script: Example 5-1. Sample WebSafe2 install.WS Script #: cd /usr/tandem/webserver/admin/conf #: install.WS -websafe This script installs WebSafe configuration files and sets up iTP Webserver for WebSafe crypto. To revert to software crypto, simply remove the file httpd.websafe.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate The install.WS script uses a sample httpd.websafe.config file. The contents of the sample file are listed in Section 7, Configuring the iTP Secure WebServer. You can edit the file to modify the WebSafe2 configuration. Be sure to complete the remaining tasks before attempting to restart the WISP.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate e. Select the MFK. f. Enter input variant 0. g. Create and record the left portion of the clear text. You can enter your own clear KEK or have the SCT generate one for you. h. Record the left portion of the cryptogram. i. Create and record the right portion of the clear text. You can enter your own clear KEK or have the SCT generate one for you. j.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate You may enter the arguments in any order. Enter the entire command on a single command line. If a continuation character is necessary, you must use the backslash (\) character as shown; the backslash is not permitted to break the DN value across lines.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate -verbose specifies that complete information associated with the command string should be displayed. Example When you enter the keyadmin command and press Return, you are prompted for the clear KEK key. Your response is not echoed. The following example dialog shows correct keyadmin syntax and the prompts keyadmin displays.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate h. Record the left portion of the cryptogram. i. Create and record the right portion of the clear text. You can enter your own clear KEK or have the SCT generate one for you. j. Record the right portion of the cryptogram. When you finish the procedure, the SCT displays the check digits for the whole cryptogram.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate The command components are described below: -websafeadd cert-recv-file specifies the name of the encoded file containing your new certificate as received from your CA. -widconf config-file specifies the WID configuration file for hardware encryption. By default, this file is named wid.config. -kek_mfk31 kek-cryptogram specifies the encrypted KEK under MFK variant 31.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Verifying Integration of a WebSafe2 Internet Security Processor (WISP) You can verify integration of the WISP and do testing by using the following procedure: 1. Start the iTP Secure WebServer by executing the start script: : cd /conf : ./start After the start script has been executed, you should have a PATHMON process running on your system.
Integrating the WebSafe2 Internet Security Processor (WISP) How to Use Server Certificate Chains With WebSafe2 Encryption How to Use Server Certificate Chains With WebSafe2 Encryption The iTP Secure WebServer’s SSL 3.0 protocol allows you to send and receive certificate chains and to use certificate chains with WebSafe2 encryption. By using the certificate chain option, you can establish a certificate hierarchy that is more than two certificates deep.
Integrating the WebSafe2 Internet Security Processor (WISP) Configuration and Version Requirements for SSL 3.0 Hardware Encryption Configuration and Version Requirements for SSL 3.0 Hardware Encryption Observe the following requirements if you plan to use the SSL 3.0 hardware encryption feature. You do not need to observe these requirements if you will be using SSL 2.0 services only or if you will be using SSL 3.0 software encryption only. Obtaining a New Certificate If you will be using SSL 3.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Earlier Version Keys and Certificates If you are using the SSL 2.0 protocol, observe the following guidelines: Keys Were Generated With: WebSafe2 Internet Security Processor (WISP) Firmware Version: Certificate Configured With WebSafe2 Internet Security Processor (WISP) Firmware Version: Can You Use the Certificate? Earlier than iTP Secure WebServer 3.3 2.4 or earlier 2.4 or earlier Yes Earlier than iTP Secure WebServer 3.3 2.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Appropriate WebSafe2 Internet Security Processor (WISP) Firmware If you are using the SSL 3.0 protocol, observe the following guidelines: Keys Were Generated With: WebSafe2 Internet Security Processor (WISP) Firmware Version: Certificate Configured With WebSafe2 Internet Security Processor (WISP) Firmware Version: Earlier than iTP Secure WebServer 3.3 Any version Any version No; you must use the SSL 2.
Integrating the WebSafe2 Internet Security Processor (WISP) Updating the WebSafe2 Interface Driver (WID) Configuration File Updating the WebSafe2 Interface Driver (WID) Configuration File An optional addition has been made to the WID configuration file that specifies the SSL version of the WISP you are using. The syntax for that addition is one of the following: version = SSL2 for WISPs using firmware prior to version 2611. version = SSL3 for WISPs using firmware version 2611 or later.
Integrating the WebSafe2 Internet Security Processor (WISP) To Switch From Software to WebSafe2 (Hardware) Encryption To Switch From Software to WebSafe2 (Hardware) Encryption If you initially use SSL encryption in software and then migrate to WISP use, you must do the following: • • • Generate a new key pair and obtain a new certificate for use with the WISP; the key pair and certificate used with software SSL encryption cannot be used for WebSafe2 encryption.
Integrating the WebSafe2 Internet Security Processor (WISP) Where to Go From Here iTP Secure WebServer System Administrator’s Guide—522659-001 5- 22
6 Managing the iTP Secure WebServer Using Scripts This section describes the httpd command and how to manage the iTP Secure WebServer environment using the scripts provided. To learn how to perform the same tasks from your browser, see Section 12, Managing the iTP Secure WebServer From Your Browser. The httpd Command The httpd command starts, stops, and restarts the iTP Secure WebServer environment.
Managing the iTP Secure WebServer Using Scripts Starting the iTP Secure WebServer Using the start Script Figure 6-1 shows the management processes created and started to initialize the iTP Secure WebServer environment. Figure 6-1. WebServer Management Processes Distributor Process Generic-CGI Server PATHMON httpd config file iTP Secure WebServer Appl. CGI Server CDT002.
Managing the iTP Secure WebServer Using Scripts Stopping the iTP Secure WebServer Using the stop Script Stopping the iTP Secure WebServer Using the stop Script You can stop the iTP Secure WebServer by executing the stop script that is in the /usr/tandem/webserver/conf directory. The script stops the process that was started by the httpd.config file. You can use the script as shown below: : cd /usr/tandem/webserver/conf : ./stop You should not get any error messages.
Managing the iTP Secure WebServer Using Scripts Restarting the iTP Secure WebServer Using the restart Script The restarth script applies changes to the httpd and Distributor process configurations only. It ignores the following types of changes in the configuration file: • • The arguments to other server classes such as generic-cgi.
Managing the iTP Secure WebServer Using Scripts Description -restart stops and restarts the httpd server with the configuration specified by config-filename, then restarts it. -restarth dynamically reconfigures the httpd server with the configuration specified by config-filename. This argument does not stop the server. Cannot be used with Parallel Library TCP/IP configurations. -rollover causes the current log files to be saved and the iTP Secure WebServer to write to a new log file.
Managing the iTP Secure WebServer Using Scripts • PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes Any Parallel Library TCP/IP configuration. The -rollover argument causes the httpd process to save the files that it is logging to and to log to new, empty files. Using -rollover eliminates the need to manually rename log files when you want to archive them and start new ones.
7 Configuring the iTP Secure WebServer This section contains the default iTP Secure WebServer configuration file and explains how configuration directives can be used to affect server operation. Appendix A, Configuration Directives, contains complete descriptions of all configuration directives.
Configuring the iTP Secure WebServer The httpd Configuration File The httpd Configuration File The following example illustrates the contents of the httpd.config file: Example 7-1. Sample httpd.config File (page 1 of 5) # VERSION=3.0 ############################################################### # # This is an automatically generated configuration file for # the iTP WebServer. # # See the server documentation for more information. # # # The name of the machine that is running the HTTP server.
Configuring the iTP Secure WebServer The httpd Configuration File Example 7-1. Sample httpd.config File (page 2 of 5) # # This specifies the where the server’s process ID will be # written. # PidFile $root/logs/httpd.pid # # Procs 0 ############################################################### # # List of html files to look for when a client only specifies # a directory name # IndexFile index.html index.htm home.html home.
Configuring the iTP Secure WebServer The httpd Configuration File Example 7-1. Sample httpd.config File (page 3 of 5) ################################################################ # # # Pathmon Configuration information. # Pathmon /G/zweb { Priority 170 PrimaryCPU 1 BackupCPU 0 Gsubvol /G/system/zweb } ################################################################ # # # Attributes for servers may be stored in a variable and then # used later.
Configuring the iTP Secure WebServer The httpd Configuration File Example 7-1. Sample httpd.config File (page 4 of 5) # # # Configure Resource Locator attributes # set rmt /bin/rmt/rmt.pway if { [file exists $root$rmt]} { Filemap $rmt $root$rmt Server $root$rmt { CWD $root/bin/rmt eval $DefaultServerAttributes } RmtServer $rmt } ################################################################ # # # End Resource Locator’s configuration # # # Bring in any SSL/PCT related configuration information.
Configuring the iTP Secure WebServer Configuring Your Server For Use With Parallel Library TCP/IP Example 7-1. Sample httpd.config File (page 5 of 5) ################################################################ # # # This does an existential check for a sampleservers.config # file. If it is there, it will be included in the # configuration. # if { [file exists $root/conf/sampleservers.config] } { source $root/conf/sampleservers.
Configuring the iTP Secure WebServer The Secure Transport Configuration File (httpd.stl.config) The Secure Transport Configuration File (httpd.stl.config) Example 7-2 shows how to configure the iTP Secure WebServer for SSL or PCT. This sample file, httpd.stl.config, is supplied with the iTP Secure WebServer. For more information about SSL configuration, see Section 4, Configuring for Secure Transport. Note. You cannot use httpd.stl.config and httpd.websafe.config in the same WebServer environment.
Configuring the iTP Secure WebServer Configuring Global Session Key Caching Example 7-2. Sample httpd.stl.config File #VERSION=3.0 # httpd.stl.config # Configure the required Secure Transport information # # Disable transmission of SSLv3 close_notify alert messages to # Microsoft browsers. # Region /* { if {[info exists HEADER(user-agent)] && [string match "*MSIE*" $HEADER(user-agent)]} { DisableCloseNotify } } KeyDatabase $root/conf/test_key.
Configuring the iTP Secure WebServer Other Configuration Files Other Configuration Files Information about the configuration files required to use WebSafe2 Internet Security Processors (WISPs) are in Configuring Your Server for WebSafe2 Internet Security Processor (WISP) Use on page 7-54. Information about the configuration file required to use the Servlet Server Class (SSC) is in Installing NonStop Servlets for JavaServer Pages (NSJSP) on page 9-13.
Configuring the iTP Secure WebServer Mapping Requests to Contents Mapping Requests to Contents To make the contents on your server available to clients, you must map the object information in URLs to the actual location of these objects on your server. To implement this mapping, you specify one or more Filemap directives in your server configuration file (httpd.config).
Configuring the iTP Secure WebServer Mapping Requests to Contents Using Multiple Filemap Directives If you have a large number of files to make available on your server, it may be useful to use multiple Filemap directives. Multiple Filemap directives can coexist in the same configuration file as long as each directive specifies a different matching prefix. Using multiple Filemap directives allows you to partition major areas of server content across different directories or even different disks.
Configuring the iTP Secure WebServer Mapping Requests to Contents A common use of index files is to establish home pages that apply to a server’s entire contents. For example, the following directives might be specified in a configuration file: Filemap / /usr/tandem/webserver/root/ IndexFile index.html When a web client makes a request to this server through the home page URL http://www.widgets.com/ the server returns the file index.
Configuring the iTP Secure WebServer Mapping Requests to Contents Accept-Language header, the server chooses according to the information in that header.
Configuring the iTP Secure WebServer Mapping Requests to Contents If the request does not contain an AcceptLanguage header, the server uses the value or values of the LanguagePreference directive to condition the search. If the configuration does not include a LanguagePreference directive, the server returns a status code indicating that the file was not found. 3. After locating a subdirectory for the preferred language, the server searches for and returns the requested file.
Configuring the iTP Secure WebServer Establishing User Directories If no file matches all the criteria, the server returns the one that offers the best match according to the following criteria: Precedence Type First content type Second language Third encoding If multiple files are equal in terms of satisfying the criteria, the server returns the smallest file.
Configuring the iTP Secure WebServer Using Guardian Files For example, if the directive UserDir public_html is specified in a server’s configuration file, the URL http://www.widgets.com/~black/home.html will be mapped to public_html/home.html in the user directory black. If a referenced user account or user-dir does not exist on the host machine, the server will return a “not found” result.
Configuring the iTP Secure WebServer • Using Guardian Files If a URL refers to a Pathway-CGI application and includes an extension, the iTP Secure WebServer directs the request to the server class specified in the PathwayMimeMap directive for the extension. Example: /G/vol/subvol/serverclassname.pway invokes the server class serverclassname in the local iTP Secure WebServer environment, unless the configuration contains a PathwayMimeMap directive that assigns the extension .
Configuring the iTP Secure WebServer Controlling File Caching Controlling File Caching To improve performance, the iTP Secure WebServer caches files it accesses. When a file is cached, it is held open for 15 minutes, eliminating the need to open the file again during that time. While the file is open, no maintenance can be performed on it nor can it be moved to a different directory. In addition to file opens, file information (retrieved by calling fstat) and actual file content can also be cached.
Configuring the iTP Secure WebServer Controlling File Caching Example: FileStatsCheckTime 120 CacheTime Syntax: CacheTime Description: Use the CacheTime directive to specify the time (in minutes)during which the server caches file opens, file stats, or actual file contents. When this directive is present in a configuration file, files accessed by the iTP Secure WebServer stay in memory for the time specified in the CacheTime directive.
Configuring the iTP Secure WebServer Controlling File Caching Example: MaxFileCacheEntries 5000 MaxFileCacheContentSize Syntax: MaxFileCacheContentSize where [num_kilobytes] specifies the number of kilobytes (KB), where 1 KB equals 1024 bytes. Description: Use the MaxFileCacheContentSize directive to specify the maximum file content length allowed in a file cache entry.
Configuring the iTP Secure WebServer Managing Log Files Description: Use the Region directive to control access to the server by path component. The command(s) specified are applied to all URLs matching URL_path. The NoCache command is used to disable file caching for all URLs matching the URL_path. In other words, none of the file opens, file stats, or file contents in the region are cached. The file caching mechanism is applied to all disk files on an iTP Secure WebServer.
Configuring the iTP Secure WebServer Planning Space for Logs Common Log Format (CLF) The common log format (CLF) is used by the access and error log files and is specified by the AccessLog and ErrorLog configuration directives (see Appendix A, Configuration Directives). This format is supported by other web servers and by many log-analysis tools. If you already are using or have such tools, you may wish to use CLF.
Configuring the iTP Secure WebServer Rotating Log Files Table 7-1. Required Log-File Space Requests/Day Access Log Size Error Log Size Extended Log Size 5,000 488K 98K 732K 10,000 976K 195K 1.5 Mb 20,000 1.9 Mb 0.4 Mb 3.0 Mb 50,000 4.8 Mb 1.0 Mb 7.2 Mb 100,000 9.7 Mb 1.9 Mb 14.5 Mb 200,000 19.0 Mb 3.8 Mb 28.5 Mb 500,000 48.0 Mb 9.6 Mb 72.0 Mb 1,000,000 97.0 Mb 19.4 Mb 145.
Configuring the iTP Secure WebServer Rotating Log Files For example, the following command: : httpd -rollover configfile_name saves current log files and starts new ones without bringing down the server. If the log file names have been changed in the configuration file, the server will continue to use the old names. The following command: : httpd -start -rollover configfile_name starts the server, saves the log files that were current when the server was stopped, and opens new log files.
Configuring the iTP Secure WebServer Setting Up Server Aliases Setting Up Server Aliases If you plan to advertise URLs for your server, you should register an alias for your server machine. This section describes: • • • How Aliases Work (See below) Why Aliases Are Useful (See page 7-25) Setting Up an Alias (See page 7-25) How Aliases Work An alias, also known as a CNAME, is simply an alternative name for your server. You register the CNAME and the local name with the Domain Name Server (DNS).
Configuring the iTP Secure WebServer Controlling Access to the Server For the server in the above example, you would include the following element in the Accept or AcceptSecureTransport directive: -name www.compedia.com After changing the configuration file, you must restart the server as described in Configuring the iTP Secure WebServer on page 7-1. 4. Test the new configuration by using the new alias in a URL to access the server.
Configuring the iTP Secure WebServer Using Region Directives Region directives allow you to limit access to any region on your server. For example, you might use a Region directive to deny requests from certain hosts, to describe the security attributes required for certain requests, or to redirect requests to another location.
Configuring the iTP Secure WebServer Granting Access by Host Name/IP Address More than one Region directive in the same configuration file can specify the same matching pattern. For example: Region /foo { command1 command2 } Region /foo { command3 command4 } The commands for controlling client access to your server are introduced in the following sections. For further information about these commands, refer to Region on page A-39.
Configuring the iTP Secure WebServer Denying Access by Host Name/IP Address Denying Access by Host Name/IP Address You can specifically deny access on the basis of client host name. To deny access by host name, you use the DenyHost command in a Region directive as follows: DenyHost host_pattern host_pattern ... where: host_pattern specifies one or more client host names or IP addresses.
Configuring the iTP Secure WebServer Administering Passwords For example: Region /recipes/secret { RequirePassword "Secret Recipes" -userfile /home/data/passwords } \ Administering Passwords To administer the passwords contained in a server password file, you use the useradm utility included with the server distribution.
Configuring the iTP Secure WebServer Administering Passwords Adding a New User to a Password File To add a new user to an existing password file, enter the following: useradm add file-name [user-name] [password] where: file-name is the name of the password file user-name is the name of the user to be added password is the new user’s password If you do not supply the user name and password, you will be prompted for them.
Configuring the iTP Secure WebServer Redirecting Access Redirecting Access You can use the Redirect command in a Region directive to redirect requests to an alternate URL. This feature is especially useful when you move server contents (in part or in whole) to a different host machine. Instead of advertising the new URL, you can simply redirect requests to it. The function of the Redirect command is similar to that of the Filemap command.
Configuring the iTP Secure WebServer Enabling Automatic Directory Indexing For example, you can use the following Region directive to redirect requests for all objects under directory /info/stocks/* to the new location http://quote.widgets.com/stocks as follows: Region /info/stocks/* { Redirect -replace /info/stocks http://quote.widgets.com/stocks } In this example, any request for the object /info/stocks/quote/dec.html is redirected to the URL http://quote.widgets.com/stocks/quote/dec.
Configuring the iTP Secure WebServer Disabling Logging Disabling Logging You can disable logging for specific requests. When you disable logging for a request, no entry is generated for that request in the server log files. This feature is useful for omitting unimportant log entries. For example, you could disable logging for requests coming from your own company, or you could disable logging for requests corresponding to a particular region.
Configuring the iTP Secure WebServer Using Multiple Region Commands The ordering of commands within a Region directive can be an important consideration. For example, suppose you wish to limit the access for a particular region to machines from the domain compedia.com; you also wish to require a valid user name and password. One way you could do this is by specifying the following Region directive: Region * { RequirePassword "Access accountname" -userfile /server/root/user.db AllowHost *.compedia.
Configuring the iTP Secure WebServer Using Pattern Variables (Lists) Using Pattern Variables (Lists) The same list of matching patterns can be shared among multiple Region directives. For example, if you wish to deny the same set of hosts access to two different regions, you can specify two Region directives, each of which includes the same list of host patterns: Region /admin/* { DenyHost *.widgets.com *.compedia.com *.foo.com } Region /testing/* { DenyHost *.widgets.com *.compedia.com *.foo.
Configuring the iTP Secure WebServer Using Conditional Commands Using Conditional Commands You can use the Tcl if command to specify the conditional execution of commands in a Region directive. (See Appendix E, Tool Command Language (Tcl) Basics, for details about the Tcl language.
Configuring the iTP Secure WebServer Using Tcl Variables Table 7-2 lists the variables you can use in Region directives, except the variables used for anonymous sessions, which are described in Anonymous Ticket Attributes on page A-52. Table 7-2. Region Directive Variables Variable Description REMOTE_HOST Contains the name of the web client making the request. If no reverse lookup is available, this variable is blank. For example: aegean.compedia.
Configuring the iTP Secure WebServer Using Tcl Variables Example 1: Time of Day Variables For example, you can use the YEAR, MONTH, DAY, WEEKDAY, HOUR, and MINUTE variables to trigger different types of access based on the time of day, as shown in the following example: Region /pictures/* { if {$HOUR > 7 && $HOUR < 19} { Redirect /come-back-later.html } } In this example, the Region directive limits access to the /pictures area.
Configuring the iTP Secure WebServer Allowing Byte Ranges For example, assume the Dinosaur/1.0 browser fails whenever it attempts to use a particular CGI program and you wish to direct all Dinosaur/1.0 users to an alternative page. In this case, you could use the User-Agent header to issue a redirect: Region /order.cgi { if {[info exists HEADER(user-agent)] && \ [string match "*Dinosaur/1.0" $HEADER(user-agent)]} { Redirect /order-dinosaur.
Configuring the iTP Secure WebServer Implementing Multiple-Host Support In either case, you need to run separate instances of the iTP Secure WebServer, each of which is completely independent of the other: each has its own installation directory with configuration file, log files, and content areas specific to that individual server.
Configuring the iTP Secure WebServer Implementing Multiple-Host Support For example, you could specify the directive Accept -transport /G/ZTC0 -address 16.11.96.5 in the configuration file of one of two servers, to limit this server to accepting connections only on IP address 16.11.96.5. Similarly, you could specify the directive Accept -transport /G/ZTC0 -address 16.11.96.6 in the configuration file of the other server, to limit this server to accepting connections only over IP address 16.11.96.6.
Configuring the iTP Secure WebServer Implementing Multiple-Host Support For example: Accept -transport /G/ZTC0 -address www.baygroup.org -port 4986 Region -host www.baygroup.org -port 4986 /* { Filemap / /groups/baygroup/www } AcceptSecureTransport -transport /G/ZTC0 -address www.nerds.org\ -cert {CN=Open Market Test Certificate MCI-1, OU=Open \ Market,O=MCI, C=US} -port 8080 Region -host www.nerds.
Configuring the iTP Secure WebServer Customizing Server Error Messages Customizing Server Error Messages This section tells you how to customize the default text of the server-access error messages. You can customize these messages to include more explanation, to use a different language, or to suggest a corrective action. The server comes with a default message for each of the access errors listed in Table A-4, Server Access Errors, on page A-28.
Configuring the iTP Secure WebServer Setting Up Clickable Images For further details about the Message directive, see Appendix A, Configuration Directives. Setting Up Clickable Images The iTP Secure WebServer provides built-in support for clickable images. Clickable images are inline images that a user can click in order to access a specific URL. When a user clicks on a clickable image, the web client sends a query to the server together with the coordinates of the user’s selection.
Configuring the iTP Secure WebServer Creating an Image Map File circle (x1,y1) radius url This directive defines a circle in terms of the center of the circle (x,y) and the radius. For example: circle (100,100) 10 /target/bullseye.html polygon (x1,y1) (x2,y2) (x2,y3) ... url This directive defines a polygon in terms of the vertices of the shape. For example, a triangular region is defined by: polygon (0,0) (0,10) (10,10) (0,0) /corner.html There can be any number of vertices.
Configuring the iTP Secure WebServer Adding a HyperText Anchor Adding a HyperText Anchor The next step is to add a hypertext anchor to the HTML inline image. For example, assume you have an HTML document with an inline image specified as follows: 
To enable this image as clickable, you would add an ISMAP tag and a hypertext anchor that refers to the server’s image map file. For example: 
PAGE 178
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) The image areas defined in Example 7-4 are shown in Figure 7-1. Figure 7-1. Image Map Areas (50,50) (100,100) (50,200) (200,50) (100,200) (50,250) CDT005.CDD In Figure 7-1, if you select coordinates anywhere within the rectangle, you will be directed to http://www.foo.com/. Likewise, if you select coordinates anywhere within the circle, you will be directed to /secret-stuff.
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) be a security risk since clients would be executing commands on the server’s host system. If you disable the exec option (described in Specifying SSI Use), this danger is mitigated; however, the performance issue remains. Note. The iTP Secure WebServer does not support the tag in .shtml-file server-side includes, which is part of Sun Microsystems, Inc. implementation of the Servlet API 2.0.
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) After specifying SSI usage for specific regions, you need to tell the server the extension of the files you want to be parsed for SSIs. Internally, the server uses the MIME type text/x-server-parsed-html to identify files to be parsed. To tell the server which extension you want to correspond to these files, you specify the MimeType directive in the mime-types.config file.
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) timefmt gives the server a new format to use when providing dates. This string is compatible with the strftime library call under most versions of UNIX.
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) file gives a pathname relative to the directory in which the document with the #include occurs. The path ./ cannot be used in this pathname, nor can absolute paths be used. As for the virtual option, you can access other static documents, but not CGI scripts. For example:
