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 and JSPs into an iTP Secure WebServer environment. This guide is intended for experienced NonStop HP system administrators and operators who need to install, configure, and manage the iTP Secure WebServer on an HP NonStop system.
Document History Part Number Product Version Published 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 523346-001 iTP Secure WebServer (Release 6.0) July 2002 523346-002 iTP Secure WebServer (Release 6.
iTP Secure WebServer System Administrator’s Guide Glossary Index What’s New in This Manual xxi Manual Information xxi New and Changed Information Examples Figures xxi About This Guide xxv Who Should Read This Guide xxv Organization of This Guide xxvi Related Manuals xxvii Bibliography xxx Reference Information on the Internet Your Comments Invited xxxii Notation Conventions xxxii Abbreviations xxxvi xxxi 1.
1. Introduction to the iTP Secure WebServer (continued) Contents 1. Introduction to the iTP Secure WebServer (continued) iTP Secure WebServer Encryption 1-11 Secure Sockets Layer (SSL) and Private Communications Technology (PCT) Encryption 1-11 WebSafe2 Encryption 1-11 2.
Contents 3. Planning the iTP Secure WebServer PATHMON Environment (continued) 3.
Contents 5. Integrating the WebSafe2 Internet Security Processor (WISP) (continued) 5.
Contents 7. Configuring the iTP Secure WebServer 7. Configuring the iTP Secure WebServer Configuring Your Server 7-1 The httpd Configuration File 7-2 Configuring Your Server For Use With Parallel Library TCP/IP 7-6 The Secure Transport Configuration File (httpd.stl.
7. Configuring the iTP Secure WebServer (continued) Contents 7.
Contents 8. Using Common Gateway Interface (CGI) Programs (continued) 8. Using Common Gateway Interface (CGI) Programs (continued) CGI Standard File Environment 8-30 Standard Input 8-30 Standard Output 8-30 Standard Error 8-30 Customizing the Standard File Environment 8-30 CGI Library 8-31 Pathway CGI Coding Considerations 8-33 Including the CGI Library 8-33 Design Guidelines 8-34 Examples of a Pathway CGI Implementation 8-35 9.
Contents 9. Using NonStop Servlets for JavaServer Pages (NSJSP) (continued) 9.
Contents 9. Using NonStop Servlets for JavaServer Pages (NSJSP) (continued) 9. Using NonStop Servlets for JavaServer Pages (NSJSP) (continued) Changing Your iTP_server.xml File 9-45 Reserved Cookie Name 9-46 Changes from Servlet Version 2.0 to 2.2 9-46 Changes from Servlet Version 2.1 to 2.2 9-47 Other Changes 9-47 10.
. Managing the iTP Secure WebServer From Your Browser (continued) Contents 12. Managing the iTP Secure WebServer From Your Browser (continued) Server Control: Stop 12-8 View Configuration Files 12-9 Edit Configuration File 12-9 View EMS Logs 12-10 View Server Logs 12-13 Search Configuration Files 12-14 OSS Commands 12-14 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.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A. Configuration Directives (continued) Description A-71 Default A-72 Example A-72 SK_GlobalCache A-72 Syntax A-72 Description A-72 Default A-72 Example A-72 SK_GlobalCacheTimeout Syntax A-72 Description A-72 Default A-72 Example A-73 User A-73 Syntax A-73 Description A-73 Default A-73 Example A-73 UserDir A-73 Syntax A-73 Description A-74 Default A-74 Example A-74 WidTimeout A-75 Syntax A-75 Description A-75 Default A-75 Example A-75 A-72 B.
C. Server Log File Formats (continued) Contents C. Server Log File Formats (continued) Extended Log Format C-4 Extended Log Entry Format Example C-7 C-4 D. Security Concepts Open Network Security D-1 Encryption D-1 Authentication D-2 Cryptographic Techniques D-3 Secret Key Systems D-3 Public Key Systems D-3 Managing Key Certificates D-5 Using Certificates 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.
Examples (continued) Contents Examples (continued) Example 7-1. Example 7-2. Example 7-3. Example 7-4. Example 7-5. Example 7-6. Example 8-1. Example 8-2. Example 8-3. Example 9-1. Example 9-2. Example 10-1. Example 11-1. Sample httpd.config File 7-2 Sample httpd.stl.config File 7-8 Sample URL 7-10 Sample Image Map 7-48 Sample WID Configuration File 7-56 Sample WebSafe2 Configuration File 7-57 Server MIME Types 8-8 Sample cgilib.
Tables Contents Tables Table 4-1. Table 7-1. Table 7-2. Table 7-3. Table 8-1. Table 8-2. Table 8-3. Table 8-4. Table 8-5. Table 8-6. Table 11-1. Table 11-2. Table A-1. Table A-2. Table A-3. Table A-4. Table A-5. Table A-6. Table C-1. Table C-2. Table C-3. Table E-1. Table F-1.
Contents iTP Secure WebServer System Administrator’s Guide —523346-002 xx
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 and JSPs into an iTP Secure WebServer environment.
What’s New in This Manual ° • • • • • • • Changes for the Original 523346-001 Version 6.0 Product names in graphic representations are consistent with the current product interface. In this edition of the current manual, Section 9, Using NonStop Servlets for JavaServer Pages (NSJSP) documents the NSJSP 1.0 version of this product. Subsequent versions of NonStop Servlets for JavaServer Pages (NSJSP), starting with NSJSP 2.
What’s New in This Manual • • • • Changed occurrences of ZOSSUTL to ZWEB in Section 2, Installing the iTP Secure WebServer and to ZNSJSP in Section 9, Using NonStop Servlets for JavaServer Pages (NSJSP). Added information on Secure HTTP to Section 4, Configuring for Secure Transport.
What’s New in This Manual • • Changes for the Original 523346-001 Version 6.0 Changed the subtitle, Changes from Servlet Version 2.0 to 2.1, to Changes from Servlet Version 2.0 to 2.2 on page 9-46. Removed the batch translator (also called ahead-of-time (AOT) compilation) from NonStop Server for Java on page 9-30 because the NonStop Java development team says this feature is not supported.
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.
Organization of This Guide About 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.
Related Manuals About This Guide 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.
TCP/IP Manuals About This Guide 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 NonStop TCP/IP subsystem. It is for system managers, operators, and others who require a basic understanding of the HP TCP/IP implementation.
WebSafe2 Manuals About This Guide 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 NonStop Server for Java, refer to the following HP manual: • NonStop Server for Java (NSJ) Programmer’s Guide And the followin
Bibliography About This Guide • • HP NonStop S-Series Planning and Configuration Guide describes how to plan and configure a NonStop 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 NonStop S-series servers, site planning and preparation, creating the operational environment, and making hardware and software configuration changes to an existing server.
Reference Information on the Internet About This Guide • Ousterhout, John K. Tcl and the Tk Toolkit. Reading, MA: Addison-Wesley, 1994. This book provides a complete description of the Tcl language. The author of the book is also the creator of the language. • Wrox Press, Ltd. Professional Java Server Programming (J2EE Edition) Provides useful information about the Servlet API and servlets/JSP programming.
Your Comments Invited About This Guide Your Comments Invited After using this manual, please take a moment to send us your comments. You can do this by: • • • Completing the online Contact NonStop Publications form if you have Internet access. Faxing or mailing the form, which is included as a separate file in Total Information Manager (TIM) collections and located at the back of printed manuals. Our fax number and mailing address are included on the form.
General Syntax Notation About This Guide computer type. Computer type letters within text indicate C and Open System Services (OSS) keywords and reserved words; enter these items exactly as shown. Items not enclosed in brackets are required. For example: myfile.c italic computer type. Italic computer type letters within text indicate C and Open System Services (OSS) variable items that you supply. Items not enclosed in brackets are required. For example: pathname [ ] Brackets.
Notation for Messages About This Guide Punctuation. Parentheses, commas, semicolons, and other symbols not previously described must be entered as shown. For example: error := NEXTFILENAME ( file-name ) ; LISTOPENS SU $process-name.#su-name Quotation marks around a symbol such as a bracket or brace indicate the symbol is a required character that you must enter as shown. For example: "[" repetition-constant-list "]" Item Spacing.
Notation for Messages About This Guide lowercase italic letters. Lowercase italic letters indicate variable items whose values are displayed or returned. For example: p-register process-name [ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For example: Event number = number [ Subject = first-subject-value ] A group of items enclosed in brackets is a list of all possible items that can be displayed, of which one or none might actually be displayed.
Notation for Management Programming Interfaces About This Guide Notation for Management Programming Interfaces The following list summarizes the notation conventions used in the boxed descriptions of programmatic commands, event messages, and error lists in this manual. UPPERCASE LETTERS. Uppercase letters indicate names from definition files; enter these names exactly as shown. For example: ZCOM-TKN-SUBJ-SERV lowercase letters.
Abbreviations About This Guide CCITT. Consultative Committee for International Telegraph and Telephone CGI. Common Gateway Interface CN. Common Name CWD. Current Working Directory DES. Data Encryption Standard DN. Distinguished Name DNS. Domain Name Server EMS. Event Management Service (HP) 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.
Abbreviations About This Guide 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 NSJSP. NonStop Servlets for JavaServer Pages 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.
Abbreviations About This Guide SI. 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.
Abbreviations About This Guide iTP Secure WebServer System Administrator’s Guide —523346-002 xl
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 • High availability The iTP Secure WebServer uses HP NonStop TS/MP to ensure high availability. NonStop TS/MP lets you run, as a server class, several instances of the same process. You can configure NonStop TS/MP to create new processes as workload increases and to restart any process that fails. • Extensibility You can enrich your WebServer environment by creating applications that use CGI, Java Servlets and JavaServer Pages.
Introduction to the iTP Secure WebServer Features and Standards Supported by iTP Secure WebServer Features and Standards Supported by iTP Secure WebServer • Standards compliance The iTP Secure WebServer complies fully with: ° ° ° ° ° ° Common Gateway Interface (CGI/1.1) ° Microsoft Private Communications Technology (PCT version 1) protocol Java Servlets 2.2 and JavaServer Pages 1.1 APIs HyperText Transfer Protocol (HTTP/1.0 and required features of HTTP/1.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer VeriSign’s Global Server ID The iTP Secure WebServer (domestic-secure version) supports VeriSign's Global Server ID, which enables 128-bit SSL sessions with browsers that offer Step-Up/Server Gated Cryptography (SGC) capability. The Global Server ID assures your visitors of your site's legitimacy.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer Byte-range protocol The iTP Secure WebServer supports the proposed Byte Range Retrieval Extension to HTTP. This means, for example, that the iTP Secure WebServer can send Adobe Portable Document Format (PDF) documents one page at a time, rather than an entire document at once, to users of the Adobe Acrobat Reader version 3.0 or later.
Introduction to the iTP Secure WebServer • iTP Secure WebServer Architecture Content negotiation When a page is available in multiple representations (for example, if the text is available in multiple languages, or a file is available in different character sets or compression formats), the iTP Secure WebServer can select among those representations on the basis of information transmitted with each request or specified in the iTP Secure WebServer configuration.
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 HP NonStop 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.
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.
Introduction to the iTP Secure WebServer WebSafe2 Encryption iTP Secure WebServer System Administrator’s Guide —523346-002 1-12
2 Installing the iTP Secure WebServer This section describes what you need to do to prepare your HP 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.
Installing the iTP Secure WebServer Required and Optional Software Required and Optional Software The following HP software products are required for using the iTP Secure WebServer: • • • NonStop operating system version D42 or later, or G03 or later. For information about installing the NonStop operating system, refer to the INSTALL User’s Guide or the DSM/SCM User’s Guide. Open System Services (OSS) file system, D40 or later.
Installing the iTP Secure WebServer Required Hardware In addition to the HP products, you must have access to a web client such as Netscape Navigator or Microsoft Internet Explorer. If you will be running your server in secure mode, you will need access to a secure browser. Required Hardware The hardware required for a NonStop server is as follows: • For a NonStop K-series server, you must have a 3615 Ethernet controller or a 3616 Token Ring controller.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer one TCPSAM (TCP socket access point) process must be running. If not all of these processes are running, the Auto-Accept feature will not be used. The iTP Secure WebServer will fall back to using the conventional support for TCP/IP. For information about configuring for Parallel Library TCP/IP, refer to the TCP/IP (Parallel Library) Configuration and Management Manual.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer CPU that already has a number of httpd servers running is neither going to help distribute the load nor improve performance. Note that load distribution has now been moved down to the adapter level by use of the round-robin filter. Additional processes may create more dispatching costs for the CPU.
Installing the iTP Secure WebServer Event Management Service (EMS) Template Installation Event Management Service (EMS) Template Installation Before you install the iTP Secure WebServer, you should install the EMS templates. When the templates are installed, each event reported by the iTP Secure WebServer appears in EMS displays and logs using the subsystem identifier TANDEM.WEBSERV.version and an event number that identifies the error or other event.
Installing the iTP Secure WebServer Installing and Configuring the iTP Secure WebServer The script displays the number of errors and warnings and terminates on an error. If an error occurs, you can check the files LWEBDDL, LWEBTMPL, LTEMPLI, and LCOUP for more information. If the iTP Secure WebServer is already running when you install the templates, the change in the presentation of event messages takes effect immediately; you need not restart the server.
Installing the iTP Secure WebServer • • Begin the Installation If you haven't used the IPSetup program before, you might want to refer to the IPSetup User's Guide on the product CD for information about this installation utility. The file is USRGUIDE.PDF on the CD. If you are upgrading from a previous iTP Secure WebServer, you must be logged on as the same userid that originally installed iTP Secure WebServer before you run ./setup under Run the Setup Script on page 2-10.
Installing the iTP Secure WebServer Copy the iTP Secure WebServer Software From the Distribution Medium 9. On the Placement Manifest screen, review the file locations. You can click Back to go back and change the file locations. When you are satisfied with the locations, click Next. This step may take a few minutes to complete. 10. On the Placement Complete screen, you can choose the check boxes to view the RVU documentation. It is recommended that you review the RVU documentation.
Installing the iTP Secure WebServer Run the Setup Script The softdoc file, T8997V60 (and T7951AAF if you unpaxed T7951PAX), is a text file that you can keep on $ISV.SOFTDOC, or you can copy the file to any other location on your NonStop system by using the FUP DUP or FUP RENAME commands. 3. To complete a typical installation of the iTP Secure WebServer, Run the Setup Script located in the OSS file system directory. Run the Setup Script HP recommends that a SUPER group userid other than SUPER.
Installing the iTP Secure WebServer Setup for Parallel Library TCP/IP Support these directories or subdirectories, you will have to reinstall the entire product starting with unpaxing the product PAX file. 3. You may now install Setup for Parallel Library TCP/IP Support, Install a WISP or Install the Resource Locator. Setup for Parallel Library TCP/IP Support In addition to scanning for conventional TCP/IP processes, the setup script will check for the presence of TCPSAM processes on the target system.
Installing the iTP Secure WebServer Install a WISP For Parallel Library TCP/IP users the next step after running the setup script is to specify the TCPSAM process in the configuration file by use of the ACCEPT or ACCEPTSECURETRANSPORT commands. For example: ACCEPT -TRANSPORT G/ZSAM1 -PORT 80 -ADDRESS 143.17.211.104 You must also consider modifying the server directive of the configuration file. A new attribute, DELETEDELAY , is intended for use with PTCP/IP support.
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 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. Use a web client to connect to the Administration Server through its IP address or DNS name (as specified during installation).
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 TS/MP System Management Manual. Parallel Library TCP/IP: The Auto Accept Feature Running with the Auto-Accept feature, an iTP Secure WebServer no longer needs its Distributor component.
Planning the iTP Secure WebServer PATHMON Environment Migration Considerations For Parallel Library TCP/IP Support Besides, it also posts a risk of losing a few connections when the PATHWAY removes the dynamic servers. The Auto-Accept feature traded the Distributor with better performance.
Planning the iTP Secure WebServer PATHMON Environment Configuring the PATHMON Environment Configuring the PATHMON Environment The configuration of the iTP Secure WebServer PATHMON environment is specified in the httpd.config file. You specify the configuration file when you start the iTP Secure WebServer process. The httpd.config file consists of keyword-value pairs. The sample configuration file httpd.config.sample is included in the /usr/tandem/webserver/conf directory.
Planning the iTP Secure WebServer PATHMON Environment Security for the Server’s Pathway Environment TANDEM_RECEIVE_DEPTH is the maximum number of requests a single httpd or servlet process can handle. Note. Although the receive depth is conceptually similar to the NonStop TS/MP link depth, the link depth is limited to 255 simultaneous requests per server class, whereas the receive depth is limited to 255 simultaneous requests per process.
Planning the iTP Secure WebServer PATHMON Environment • • • • Who Can Modify the Configuration Files? Who Can Start/Stop the iTP Secure WebServer? on page 3-6 What TCP/IP Port Is the Distributor Process Monitoring? on page 3-6 Common Gateway Interface (CGI) Application Security Considerations on page 3-7 Pathway CGI Server Class Considerations on page 3-7 Who Can Modify the Configuration Files? By default, access to the /usr/tandem/webserver/admin/conf directory is restricted to the owner of the directo
Planning the iTP Secure WebServer PATHMON Environment Common Gateway Interface (CGI) Application Security Considerations Common Gateway Interface (CGI) Application Security Considerations The system administrator must consider the user ID that will configure and start the iTP Secure WebServer environment. The user ID determines the security restrictions for the server classes within the environment. CGI programs and scripts are spawned by the generic-cgi.pway server class. The owner of the generic-cgi.
Planning the iTP Secure WebServer PATHMON Environment Protecting the Server Password One way that you can protect the key database file is by protecting its password (see Protecting the Server Password below). You also should protect the key database file by ensuring that it has the correct file permissions. The file should be owned by the user name under which the server is run and set to mode 600, giving read/write access only to that user.
Planning the iTP Secure WebServer PATHMON Environment Protecting Transmission of Key Database Files and Core Dumps Protecting Transmission of Key Database Files and Core Dumps If you must transmit a key database file and/or a core dump over the public network— for example, to HP support services for help with troubleshooting— make sure the transmission mechanism is appropriate for your security requirements.
Planning the iTP Secure WebServer PATHMON Environment Protecting Transmission of Key Database Files and Core Dumps iTP Secure WebServer System Administrator’s Guide —523346-002 3- 10
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.
Configuring for Secure Transport Using the Administration Server Securely Using the Administration Server Securely HP recommends that you access the iTP Secure WebServer Administration Server only from secure transport connections. In some cases, you must provide the password with which the server’s key database file is encrypted, and this password should not be transmitted unsecured. To specify that the iTP Secure Administration server must accept requests from secure connections only, modify the httpd.
Configuring for Secure Transport Server Configuration 4. Obtain a certificate for the public key part of the pair from a Certificate Authority (CA) by e-mailing the certificate-request file to the CA. This procedure is described in Requesting a Certificate on page 4-10. 5. Store the resulting public key certificate in the key database file by using the keyadmin utility. 6. Make a new backup copy of the key database file once the certificate has been added. Also, make a backup of the certificate itself.
Configuring for Secure Transport Managing Certificates For complete information about these options, refer to AcceptSecureTransport on page A-5. Note. The server checks for connections on the ports specified by both the Accept and the AcceptSecureTransport directives. 4. Use the RequireSecureTransport commands in the Region directive to control how clients access the server and its contents as described in Controlling Access and Privacy on page 4-28. 5. Restart the server. 6.
Configuring for Secure Transport Support for International 128-Bit SSL Sessions Using VeriSign’s Global Server ID CAs use DNs to formally bind particular persons or organizations to particular keys. The individual attributes in DNs are separated by commas and must be specified in the order required by a particular CA. Table 4-1 lists and describes the most common DN attributes. Table 4-1.
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 the Keyadmin Utility to Manage Keys and Certificates below for information about obtaining and installing 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.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates For information about the server key database file and the password used to encrypt it, see KeyDatabase on page A-24 and ServerPassword on page A-67. 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.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -length key-length specifies the length of the key in bits. This option allows you to control the size of the encryption key. The default key size is 512 bits. The minimum key size is 512 bits. The maximum key size is 1024 bits, except for the exportable version of the iTP Secure WebServer, for which it is 512 bits. -verbose specifies that complete information associated with the command string should be displayed.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Note that if you omit -mkreq, this command generates both a random key pair and a certificate request. -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.
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 -addcert cert-recv-file specifies the name of the encoded file containing your new certificate as received from your CA. -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.
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 -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. Make sure to include the same field values entered on the CA request form and in the exact order that the CA specifies.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -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. -enable specifies that you wish to enable a certificate in the 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 -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. Database passwords must have at least eight characters all in uppercase or in a combination of uppercase and lowercase characters. Note.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -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. -verbose specifies that complete information associated with the command string should be displayed.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Updating the Default Root Certificates The iTP Secure WebServer supports a set of default root certificates for domestic use (United States and Canada). If a request arrives and client authentication is required, the iTP Secure WebServer checks the certificate to see whether it matches any of the default root certificates; if the certificate matches, the request is accepted, and if not, the request is rejected.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-2. Example Default Root Certificate (page 2 of 4) ----------------------------------Distinguished Name OU: Class 1 Public Primary Certification Authority O: Verisign, Inc.
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: Secure Server Certification Authority O: RSA Data Security, Inc. C: US State: Root Enabled Private Key: Not Present Public Key: Present Certificate: Present ----------------------------------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: GTE CyberTrust Root O: GTE Corporation C: US State: Root Enabled Private Key: Not Present Public Key: Present Certificate: Present ----------------------------------Distinguished Name CN: Open Market, Inc.
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. Under normal circumstances, you do not need to invoke this option. 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.
Configuring for Secure Transport Using Server Certificate Chains With the iTP Secure WebServer -verbose specifies that complete information associated with the command string should be displayed. If an entry already exists in the new database, keyadmin displays a prompt asking if the existing entry can be overwritten.
Configuring for Secure Transport Managing Client Authentication You can use certificate chains with the WebSafe2 unit for increased security. If you plan to do this, see How to Use Server Certificate Chains With WebSafe2 Encryption on page 5-16 for specific configuration details. To create a server certificate chain, follow these steps: 1. Obtain leaf and intermediate certificates from the appropriate CA.
Configuring for Secure Transport Using the -requireauth Option Client authentication does not occur unless you specify either the -requestauth or -requireauth option. Specifying one of these options allows you to use the web client’s authentication information in Region configuration directives to restrict access to the iTP Secure WebServer.
Configuring for Secure Transport Using the -requestauth Option Using the -requestauth Option When you set the -requestauth option, the server always allows the web client connection, regardless of the state of the client certificate. In addition, the server sets the HTTPS_CLIENT_STATUS variable to reflect the status of the client certificate (if the certificate is valid or invalid). The server sets the variable to one of the following values: No certificate The certificate does not exist.
Configuring for Secure Transport Updating SSL and PCT Configuration Valid certificate but root certificates don’t match The server requested client authentication and received a client certificate chain which contains X509 version 3 certificates. The public key contained within the root certificate of the chain provided by the web client matches the public key from the root certificate in the key database file, but one or more other fields within the two certificates do not match.
Configuring for Secure Transport Controlling Access and Privacy The KeyDatabase directive specifies the file to be used for storing keys and publickey certificates. The ServerPassword directive specifies the password used to encrypt the key database file. This password must agree with the one you specified when running the keyadmin utility. For details, see Changing the Key Database File Password on page 4-15.
Configuring for Secure Transport Using SSL and PCT Environment Variables in CGI Programs You can further restrict access by using the -auth option of the RequireSecureTransport command to require that client authentication occurs, as in this example: Region /recipes/* { RequireSecureTransport -auth } In this example, only clients that have been authenticated using SSL or PCT are allowed access to objects in the /recipes/top-secret region on the server.
Configuring for Secure Transport Controlling Encryption and Integrity Checking Controlling Encryption and Integrity Checking The iTP Secure WebServer allows the web client and server to negotiate which encryption algorithm will be used. The encryption algorithm is called a cipher. The choice of cipher controls both the encryption and integrity checking required between client and server.
Constraints on Cipher Use Configuring for Secure Transport Figure 4-1. Cipher Negotiation Between Web Client and Server Lists Web Client List Server List DEC-CBC3-SHA1 RC2-CBC-SHA1 EXP-RC4-MD5 RC4--MD5 RC4-MD5 DES-CBC3-MD5 RC2-CBC-SHA1 When this list... is compared to this list... RC2-CBC-SHA1 This cypher is used CDT 114.CDD For a list of the cipher-hashing algorithms iTP Secure WebServer supports, refer to AcceptSecureTransport on page A-5.
Configuring for Secure Transport Constraints on Cipher Use iTP Secure WebServer System Administrator’s Guide —523346-002 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).
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) How the iTP Secure WebServer Uses WebSafe2 Internet Security Processors (WISPs) How the iTP Secure WebServer Uses WebSafe2 Internet Security Processors (WISPs) The WISP generates the public/private key pair used by the iTP Secure WebServer and protects the private key by encrypting it an MFK.
Integrating the WebSafe2 Internet Security Processor (WISP) Fault-Tolerance Requirements Fault-Tolerance Requirements There is no automatic backup to software encryption in the event of WISP failures. Therefore, you must install and configure enough hardware to survive a single point of failure.
Integrating the WebSafe2 Internet Security Processor (WISP) If You Are Upgrading the WebSafe2 Internet Security Processor (WISP) From An Earlier Version 5. Generate the public/private key pair and obtain a certificate. See Generating the Public/Private Key Pair and Obtaining the Certificate on page 5-9. Note. The public/private key pair and certificate used for SSL encryption cannot be used when the iTP Secure WebServer operates with the WISP.
Integrating the WebSafe2 Internet Security Processor (WISP) Preparing a Distinguished Name (DN) for the Certificate Preparing a Distinguished Name (DN) for the Certificate Use the instructions in Formatting Distinguished Names (DNs) on page 4-4 to prepare a DN for the Certificate you will obtain. You will use this DN when you configure and generate a public/private key pair.
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 c. Select double length (F2). d. Enter 1 as the number of key parts. 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.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Step 2. Generating a Public/Private Key Pair and a Certificate Request When used with WebSafe2 encryption, the iTP Secure WebServer can only use a public/private key pair generated by the WISP. You use the keyadmin utility to cause the WISP to generate a public/private key pair and to generate a certificate request containing the public key.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate -kek_clear kek-value specifies the clear KEK value. If kek-value is not supplied in the command line, you are prompted by keyadmin to enter it. Keyadmin computes the check digits of KEK and asks you to verify that it is correct. The size of KEK is 16 bytes (32 hex digits). -length key-length specifies the length of the key in bits.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Step 3. Requesting a Certificate From a Certificate Authority (CA) To request a certificate, e-mail the file cert-req.txt to a CA. For more information about this process, see Requesting a Certificate on page 4-10. Step 4. Obtaining a KEK Pair Using Variant 31 You obtain a KEK pair using variant 31 by performing the following steps: a. Select Encryption Key MFK1. b.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate the newdn.txt file. After the newdn.txt file is created, a message will be displayed showing the current DN that is to be used in all keyadmin commands. This current DN is the one to be used in the AcceptSecureTransport directive. For information about the AcceptSecureTransport directive, see AcceptSecureTransport on page A-5. A sample newdn.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Example The following sample command shows the keyadmin syntax and the prompts that keyadmin displays: bin/keyadmin -verbose -websafeadd \ test-cert.resp -widconf wid.config \ -kek_mfk31 DCA519DB8A3EF822 -kek_clear 6BE0106B619EB3DF Note.
Integrating the WebSafe2 Internet Security Processor (WISP) How to Use Server Certificate Chains With WebSafe2 Encryption 4. Stop the server by executing the stop script that is in the /conf directory: : ./stop You should not get any error messages. The Pathmon process and any other processes started by the iTP Secure WebServer are stopped. 5. Verify that the server has stopped: : ps You should not see the Distributor, httpd, or generic-cgi.pway processes running.
Integrating the WebSafe2 Internet Security Processor (WISP) Configuration and Version Requirements for SSL 3.0 Hardware Encryption 3. Store the leaf certificate, including the lines labeled ----- BEGIN CERTIFICATE ----- and ----- END CERTIFICATE -----, in the designated certificate file (cert.txt in the example) using the keyadmin command as shown in the following example: keyadmin -websafeadd cert.txt -widconf widconf -kek_mfk31 kek_mfk31 4.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Earlier Version Keys and Certificates Using Earlier Version Keys and Certificates Observe the following guidelines if you intend to use keys and certificates generated or configured with earlier versions of the iTP Secure WebServer or the WISP’s firmware. iTP Secure WebServer Version WebSafe2 Internet Security Processor (WISP) Firmware Version SSL Support Recommended Action Earlier than 3.2 Any SSL 2.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Earlier Version Keys and Certificates Keys Were Generated With: WebSafe2 Internet Security Processor (WISP) Firmware Version Certificate Configured With WebSafe2 Internet Security Processor (WISP) Firmware Version iTP Secure WebServer 3.3 Any Earlier than 2611 No; the APKB format is incompatible (the new key type cannot be used with older commands)3 iTP Secure WebServer 3.3 2.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Appropriate WebSafe2 Internet Security Processor (WISP) Firmware Using Appropriate WebSafe2 Internet Security Processor (WISP) Firmware Make sure your WISPs are using firmware version 2611 or later. To use 1024 bit keylength certificates, you must run Atalla WISP firmware version 2.761.
Integrating the WebSafe2 Internet Security Processor (WISP) Switching From Software to WebSafe2 (Hardware) Encryption 2. Remove or rename the httpd.websafe.config file. 3. Ensure that the httpd.config file includes httpd.stl.config and that the httpd.stl.config file has one or more AcceptSecureTransport directives that include the options you require. 4. Restart the iTP Secure WebServer as described in Section 6, Managing the iTP Secure WebServer Using Scripts.
Integrating the WebSafe2 Internet Security Processor (WISP) Where to Go From Here iTP Secure WebServer System Administrator’s Guide—523346-002 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.
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 You should not get any error messages. You should have a $ZWEB PATHMON process running on your system after the start script has been executed. 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.
Managing the iTP Secure WebServer Using Scripts For Classical TCP/IP Support: For Classical TCP/IP Support: If the iTP Secure WebServer is already running and you want to restart it so that changes to the httpd.config file can take effect, you can bring up your new configuration without stopping the server first. You can use the script as shown below: : cd /usr/tandem/webserver/conf : ./restarth You should not get any error messages.
Managing the iTP Secure WebServer Using Scripts Syntax Syntax The httpd command has the following syntax: httpd {-start [-rollover] |-stop [-rollover] |-restart [-rollover] |-restarth [-rollover]} config-filename -start starts the httpd server with the configuration specified by config-filename. -stop stops the httpd server with the configuration specified by config-filename. -restart stops and restarts the httpd server with the configuration specified by config-filename, then restarts it.
Managing the iTP Secure WebServer Using Scripts Description You can dynamically change the configuration of an iTP Secure WebServer by modifying the configuration file for the server you want to change, then using the httpd command with the -restarth argument The -restarth argument causes the server to reread the directives in the configuration file without stopping. The configuration file specified must be one that is already in use.
Managing the iTP Secure WebServer Using Scripts • PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes When you use -rollover with -stop, the current log files are saved before the httpd process is stopped. When the iTP Secure WebServer is started again, it begins logging to new files. Note. If no disk space is available to save the current log files, a message (#580) appears on the command line.
Managing the iTP Secure WebServer Using Scripts PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes iTP Secure WebServer System Administrator’s Guide—523346-002 6 -8
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 Use the new directive SK_GlobalCacheTimeout, to alter the default Pathsend timeout value of 1/2 second (50/100 second). This timeout determines how long the httpd server will wait for a response from the global cache server before a timeout error occurs. To enable tracing you must define the env variable TRACEFILE. All communication from and to the httpd server is logged. This option should be set only if problems arise.
Configuring the iTP Secure WebServer Other Configuration Files Example 7-2. Sample httpd.stl.config File (page 2 of 2) # SK_GlobalCacheTimeout 50 Server $root/bin/gcache { eval $DefaultServerAttributes Maxservers 1 Maxlinks 50 Linkdepth 50 Numstatic 1 # Env TRACEFILE=$root/logs/gctrace.log Env ERRORFILE=$root/logs/gcerror.
Configuring the iTP Secure WebServer Understanding How URLs Work Understanding How URLs Work Objects on your iTP Secure WebServer are accessed by means of Universal Resource Locators (URLs). A URL is composed of five elements, as follows: No. URL Component Description 1 Method The transport method to be used to access the server. For example: http. 2 Host The name of the host machine. 3 Port The port on the host to which the request is to be directed.
Configuring the iTP Secure WebServer Mapping Requests to Contents dir is the server directory to which any object specification matching url-prefix will be directed for the requested object. The Filemap directive converts a matched request specification (object path) into the actual location on the server of the requested object by substituting the target server directory (dir) for the matched URL prefix (url-prefix).
Configuring the iTP Secure WebServer Mapping Requests to Contents the URL http://my.server.com/encyclopedia/info/doc.html will refer to the file /usr/disk0/info/doc.html while the URL http://my.server.com/dictionary/entry/ants.html will refer to the file /usr/disk7/entry/ants.html Handling Directory Accesses A URL can refer to a directory instead of a specific object. For example: http://my.server.
Configuring the iTP Secure WebServer Mapping Requests to Contents information on automatic indexing, see Enabling Automatic Directory Indexing on page 7-34. Content Negotiation Sometimes it is reasonable to present the same content to different users in different ways. For example, you might want to let the user choose whether to receive text in English, German, or Japanese. Similarly, different clients might prefer different character sets or file compression options.
Configuring the iTP Secure WebServer • Mapping Requests to Contents The LanguageSuffix directive maps between the RFC 2068 standard abbreviation for a language (such as en-US for American English and de for German) and the extension used to identify files in that language on the host. For example, the following directive specifies that German language files will have the extension .ger: LanguageSuffix de .ger For detailed information about these directives, see Appendix A, Configuration Directives.
Configuring the iTP Secure WebServer Mapping Requests to Contents 3. After locating a subdirectory for the preferred language, the server searches for and returns the requested file. If the server finds a directory corresponding to the highest weighted language, but the file is not present in that directory, the server searches for the file in the directory for the second best language, then the third best, and so on.
Configuring the iTP Secure WebServer Establishing User Directories 3. Upon locating a file that meets the content-negotiation criteria, the server returns that file to the client. 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 Requests to user directories are differentiated from normal requests by the use of a tilde (~) prefixed to the path component of the URL. Any path beginning with a tilde is automatically mapped to the appropriate user directory. 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.
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. For 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 CacheTime Default: When no FileStatsCheckTime directive is present, the value of 60 (one hour) will be used. 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.
Configuring the iTP Secure WebServer MaxFileCacheContentSize To disable file opens caching, the CacheTime directive must be set to 0. Default: When no MaxFileCacheEntries directive is present, the server allows 2000 entries in the file cache. Example: MaxFileCacheEntries 5000 MaxFileCacheContentSize Syntax: MaxFileCacheContentSize where [num_kilobytes] specifies the number of kilobytes (KB), where 1 KB equals 1024 bytes.
Configuring the iTP Secure WebServer NoCache Region Command NoCache Region Command Syntax: Region URL_path { [NoCache] } 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.
Configuring the iTP Secure WebServer Managing Log Files Managing Log Files This section tells you how to manage your log files including: • • • Choosing a Log Format on page 7-23 Planning Space for Logs on page 7-24 Rotating Log Files on page 7-24 Choosing a Log Format You can choose between two formats for your server log files: • • Common Log Format (CLF) on page 7-23 Extended Log Format (ELF) on page 7-23 Common Log Format (CLF) The common log format (CLF) is used by the access and error log file
Configuring the iTP Secure WebServer Planning Space for Logs If you plan to write your own log-analysis programs, or if you need to use the additional information fields, you may wish to specify ELF. ELF also allows you to make best use of WebReporter. For more information, refer to the iTP Secure WebServer WebReporter Command Reference Manual and the iTP Secure WebServer WebReporter User’s Guide. CLF and ELF are described in detail in Appendix C, Server Log File Formats.
Configuring the iTP Secure WebServer Rotating Log Files Secure WebServer continues operation. You run the rollover script from the /usr/tandem/webserver/conf directory as follows: : cd /usr/tandem/webserver/conf : ./rollover The rollstarth script operates like the rollover script, but dynamically restarts the iTP Secure WebServer so that configuration changes can take effect without the iTP Secure WebServer being brought down.
Configuring the iTP Secure WebServer Setting Up Server Aliases Log File Naming Conventions When you automatically rotate log files, current log files are saved under their configured names, but a timestamp is appended to the name in the form mm-dd-[y]yy.hh.mm. You can use the compress command to archive the files as shown in the following examples: : cd /usr/tandem/webserver/logs : compress ../logs/elog11-23-96.19:34 : cd /usr/tandem/webserver/logs : compress ../logs/elog04-11-102.10:20 Note.
Configuring the iTP Secure WebServer Setting Up an Alias Setting Up an Alias You set up an alias for your server as follows: 1. Choose an alias for your machine and register it with the DNS. If you are not sure how to register the name you choose, consult your local area network (LAN) administrator or the system documentation. 2. Verify that your alias has been registered. Use the nslookup command if it is available on your system. 3. In the server configuration file (httpd.
Configuring the iTP Secure WebServer • • • Using Region Directives Using Tcl Variables on page 7-38 Allowing Byte Ranges on page 7-41 Implementing Multiple-Host Support on page 7-41 Using Region Directives You control client access to your server by entering commands in a Region directive in the server configuration file (httpd.config). The Region directive applies these commands to any requests or classes of requests attempting to access a specified portion of your server file tree.
Configuring the iTP Secure WebServer Granting Access by Host Name/IP Address A Region command is a procedure that either runs to completion or calls a result command such as Deny, Redirect, or Allow. When a result command other than Allow is called, command processing stops; when Allow is called, the server executes the requested access immediately.
Configuring the iTP Secure WebServer Denying Access by Host Name/IP Address /secret-project. If your company domain is wonka.com, the following directive would grant the desired access: Region /secret-project/* { AllowHost *.widget.com *.wonka.com } If a host name pattern is specified but the web client’s host name is not available (for example, because the host’s IP address has not been registered with the DNS for reverse lookup), the AllowHost command will deny access to the web client.
Configuring the iTP Secure WebServer Administering Passwords userfile is the name of a server file containing a user-name/password database. This file is maintained by means of the useradm tool, as described in Administering Passwords below. If the user enters a user name and password that matches one of the user name/password pairs in the specified password file, the web client is granted access to the server region specified in the containing Region directive.
Configuring the iTP Secure WebServer Administering Passwords -digest specifies a digest-authentication format file-name is the name of the new password file 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
Configuring the iTP Secure WebServer Redirecting Access Example of Password Administration The following commands create a new password file, then add the user tristen who is assigned the password play-group: useradm create /usr/tandem/webserver/users useradm add /usr/tandem/webserver/users tristen play-group Redirecting Access You can use the Redirect command in a Region directive to redirect requests to an alternate URL.
Configuring the iTP Secure WebServer Enabling Automatic Directory Indexing 2. You can use a Redirect command with the -replace option to redirect requests to an alternate location that has the same file structure as the original location: Redirect [-replace /replace-spec] alt-rl When you specify the -replace option, the URL path element specified by /replace-spec is removed from the front of the request URL. The remainder of the request URL is then appended to the alternate URL (alt-url).
Configuring the iTP Secure WebServer Disabling Logging For more information about the DirectoryIndex command, see Region on page A-39. 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.
Configuring the iTP Secure WebServer Using Multiple Region Commands 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.com } In this example, your server would first require a user name and password for access.
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. 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.com For information on reverse lookup, refer to Region on page A-39. REMOTE_ADDR Contains the IP address of the web client making the request. For example: 199.170.183.5 PATH Contains the URL path for this request.
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 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.cgi } } Allowing Byte Ranges The iTP Secure WebServer supports byte-range access, which is always enabled. Web clients that also support byte-range access can request any range within a requested file.
Configuring the iTP Secure WebServer Implementing Multiple-Host Support Implementing Multiple Servers There are two ways to configure multiple servers on the same machine: • • Using Different Ports on page 7-42 Using Different IP Addresses on page 7-42 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 individua
Configuring the iTP Secure WebServer Implementing Multiple-Host Support related to TCP/IP configuration on HP NonStop systems, see the TCP/IP Configuration and Management Manual. Assigning Servers to Specific IP Addresses You can limit a server to accept connections on only one IP address and assign each of multiple servers running on the same host to a different IP address.
Configuring the iTP Secure WebServer Implementing Multiple-Host Support Create virtual hosts by using the Accept and/or AcceptSecureTransport directives to associate specific IP addresses with specific host names and/or ports. Then associate content regions with these virtual hosts by using Region directives, using the -host and/or -port arguments. For example: Accept -transport /G/ZTC0 -address www.baygroup.org -port 4986 Region -host www.baygroup.
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-29.
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 189
Configuring the iTP Secure WebServer Setting Up a Server-Side Include (SSI) 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) 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) server which extension you want to correspond to these files, you specify the MimeType directive in the mime-types.config file. For example, the server default is: MimeType text/x-server-parsed-html shtml This directive marks for parsing any file ending in .shtml. The default MIME-type extensions specified in the mime-types.config file are lowercase. Therefore, if you have a file with the extension .
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:
