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. Product Version iTP Secure WebServer (Release 7.0) Supported Release Version Updates (RVUs) This publication supports J06.03 and all subsequent J-series RVUs, H06.
Document History Part Number Product Version Published 523346-007 iTP Secure WebServer (Release 7.0) May 2008 523346-008 iTP Secure WebServer (Release 7.0) August 2008 523346-009 iTP Secure WebServer (Release 7.0) February 2009 523346-010 iTP Secure WebServer (Release 7.0) August 2009 523346-012 iTP Secure WebServer (Release 7.
Legal Notices Copyright 2010 Hewlett-Packard Development Company L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
iTP Secure WebServer System Administrator’s Guide Glossary Index Examples Figures Tables Legal Notices What’s New in This Manual xxi Manual Information xxi New and Changed Information xxi About This Guide xxv Who Should Read This Guide xxv Organization of This Guide xxvi Bibliography xxx Reference Information on the Internet Notation Conventions xxxii Change Bar Notation xxxv Abbreviations xxxv xxxi 1.
1. Introduction to the iTP Secure WebServer (continued) Contents 1. Introduction to the iTP Secure WebServer (continued) Secure Sockets Layer (SSL) and Private Communications Technology (PCT) Encryption 1-11 WebSafe2 Encryption 1-11 2.
3. Planning the iTP Secure WebServer PATHMON Environment (continued) Contents 3.
Contents 5. Integrating the WebSafe2 Internet Security Processor (WISP) (continued) 5.
Contents 6. Managing the iTP Secure WebServer Using Scripts (continued) 6. Managing the iTP Secure WebServer Using Scripts (continued) Description 6-5 PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes 6-7 Collecting httpd Statistics Using statscom 6-7 statscom Command 6-7 Collecting Webserver Statistics Using timestat script 6-12 7.
7. Configuring the iTP Secure WebServer (continued) Contents 7.
8. Using Common Gateway Interface (CGI) Programs (continued) Contents 8.
11. Administering Session Identifiers for Anonymous Sessions (continued) Contents 11. Administering Session Identifiers for Anonymous Sessions (continued) Advanced Configuration Options 11-6 Ticketing Strategies 11-11 Using Session Identifiers for Reporting 11-15 Using Tcl Variables for Anonymous Sessions 11-16 12.
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.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A.
A. Configuration Directives (continued) Contents A. Configuration Directives (continued) Syntax A-86 Description A-86 Default A-87 Example A-87 WidTimeout A-87 Syntax A-87 Description A-87 Default A-87 Example A-87 B. Error Messages C. Server Log File Formats Access Log Format C-1 Access Log Entry Format C-1 Example C-2 Error Log Format C-3 Hypertext Transfer Protocol (HTTP) Status Codes Extended Log Format C-4 Extended Log Entry Format C-4 Example C-7 Logging through an External ServerClass C-7 C-3 D.
D. Security Concepts (continued) Contents D. Security Concepts (continued) Design Goals D-9 Relative Advantages D-10 E. Tool Command Language (Tcl) Basics Tcl Syntax Rules E-1 Tcl Commands E-3 Script Commands E-4 F. HTTP/1.1 Feature List Glossary Index Examples Example 4-1. Example 4-2. Example 4-3. Example 5-1. 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 10-1. Example 11-1.
Figures (continued) Contents Figures (continued) Figure 8-1. Figure 8-2. Figure 8-3. Figure 11-1. Figure 11-2. Figure 11-3. Figure 11-4. Figure C-1. Figure D-1. Figure D-2. Figure D-3. CGI Relationships 8-2 Generic-CGI Server class 8-3 Pathway CGI Interface 8-5 Requesting a Ticket 11-3 Using a Ticket 11-3 Proxies 11-10 Relative and Absolute References 11-12 Logging Using External Serverclass C-8 Basic Encryption D-2 Public-Key Systems D-4 Certificate Chain D-6 Tables Table 4-1. Table 4-2. Table 7-1.
Contents iTP Secure WebServer System Administrator’s Guide —523346-012 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. Product Version iTP Secure WebServer (Release 7.0) Supported Release Version Updates (RVUs) This publication supports J06.
What’s New in This Manual Changes to the H06.19/J06.08 Manual Changes to the H06.19/J06.08 Manual • • • • • • • • • • Added IP CIP on page 1-8. Added a note in Preparing Your System for the iTP Secure WebServer on page 2-4. Added Setup for IP CIP Support on page 2-16. Added the following: ° Importing a Private Key into iTP Secure WebServer's Key Database File on page 4-26. ° Exporting a Private Key to a User-Defined Disk File on page 4-27.
What’s New in This Manual Changes to the H06.15/J06.04 Manual Changes to the H06.15/J06.04 Manual • • • • • • Added a section LNP Support for TCP/IPv6 on page 2-16. Added a section Combined Log Format on page 7-23. Updated the section Using the rollover and rollstarth Scripts to Rotate Log Files on page 7-24 . Added new attribute LOG1 [status|eventformat] on page A-45.
What’s New in This Manual Changes to the H06.14/J06.
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 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, see Appendix D, Security Concepts. If you need more information about NonStop systems, you should consult these publications before reading this guide: • • G06.
Organization of This Guide About This Guide Section Description Section 8, Using Common Gateway Interface (CGI) Programs Explains how to use existing Common Gateway Interface (CGI) programs with the iTP Secure WebServer. It also discusses how to develop CGI applications with much better scalability and performance than conventional CGI.
TCP/IP Manuals About This Guide TCP/IP Manuals For information specific to managing the TCP/IP subsystem, see: • • • • • 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 • TS/MP Management Programming Manual describes how to start, configure, and manage PATHMON environments programmatically and describes the event messages that report errors and other occurrences of interest to operators.
Bibliography About This Guide The guide introduces the control, configuration, and maintenance tools used in Integrity NonStop NS-series systems, and gives an overview of the installation planning. The guide is for the personnel responsible for planning the installation, configuration, and maintenance of the server and the software environment at a particular site. • • • • H06.nn Release Version Update Compendium provides a summary of the products that have major changes in the H06.
Reference Information on the Internet About This Guide • Garfinkel, Simson, and Spafford, Gene. Practical UNIX and Internet Security. Sebastopol, CA: O’Reilly & Associates, 1996. This book offers practical information about running a secure UNIX site. • Hunt, Craig. TCP/IP Network Administration. Sebastopol, CA: O’Reilly & Associates, 1998. This book is useful for anyone who has to administer a UNIX system attached to a TCP/IP network. • Liu, Cricket et al. Managing Internet Information Services.
Notation Conventions About This Guide • • • • • Java Servlet reference: http://java.sun.com/products/servlet/download.html Java Servlet Specification Version 2.3: http://java.sun.com/products/servlet/ JavaServer Pages API Specification Version 1.2: http://java.sun.com/products/jsp/ J2EE Platform 1.3 Specification: http://java.sun.com/j2ee For a list of books that can help you become more familiar with Web technology, see the Bibliography on page xxx.
General Syntax Notation About This Guide [ ] 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 can 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. For example: FC [ num ] [ -num ] [ text ] K [ X | D ] address { } Braces.
Notation for Messages About This Guide 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 this example, there are no spaces permitted between the period and any other items: $process-name.#su-name Line Spacing.
Abbreviations About This Guide horizontally, enclosed in a pair of brackets and separated by vertical lines. For example: proc-name trapped [ in SQL | in SQL file system ] { } Braces. A group of items enclosed in braces is a list of all possible items that can be displayed, of which one is actually displayed. The items in the list might be arranged either vertically, with aligned braces on each side of the list, or horizontally, enclosed in a pair of braces and separated by vertical lines.
Abbreviations About This Guide AOT. Ahead Of Time APKB. Atalla Public Key Block AWT. Abstract Windows Toolkit ARPA. Advanced Research Project Agency ATP. Active Transaction Pages BSD. Berkeley Software Distribution C. Country CA. Certificate Authority CBC. Cipher Block Chaining 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.
Abbreviations About This Guide ITU-T. ITU Telecommunication Standardization Sector JDBC. Java Data Base Connectivity JDK. Java Development Kit JIT. Just-In-Time (Java compiler) JNI. Java Native Interface JSP. JavaServer Pages JVM. Java Virtual Machine KEK. Key Exchange Key L. Locality 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.
Abbreviations About This Guide QIO. Queued Input Output RFC. Request for Comments RLS. Resource Locator Service RSA. Rivest, Shamir, and Adelman SCF. Subsystem Control Facility SCT. Secure Configuration Terminal SGC. Server Gated Cryptography (Microsoft) SGML. Standard Generalized Markup Language SHA1. Secure Hash Algorithm 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.
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 • Flexible access control You can control access to the iTP Secure WebServer on the basis of such factors as host name, time of day, user name, browser type and version, and authentication method. • High availability The iTP Secure WebServer uses HP NonStop TS/MP to ensure high availability. NonStop TS/MP enables you to run, as a server class, several instances of the same process.
Introduction to the iTP Secure WebServer Features and Standards Supported by iTP Secure WebServer while the other Pathmon serves the requests with older webserver objects. This process is repeated to upgrade the other PATHMON. Note. The online-upgrade feature is available on systems running J06.06 and later Jseries RVUs and H06.17 and later H-series RVUs.
Introduction to the iTP Secure WebServer Features and Standards Supported by iTP Secure WebServer Provides a challenge/response authentication mechanism for additional security; the user’s password is not sent over the network. • 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.
Introduction to the iTP Secure WebServer • Features and Standards Supported by iTP Secure WebServer National Center for Supercomputing Applications (NCSA) format in image maps The iTP Secure WebServer supports NCSA-formatted image-map files in addition to the CERN format. The iTP Secure WebServer also provides support for the point directive in NCSA-formatted image maps. • Byte-range protocol The iTP Secure WebServer supports the proposed Byte Range Retrieval Extension to HTTP.
Introduction to the iTP Secure WebServer iTP Secure WebServer Architecture establishment of a persistent connection for a set of related requests; you can set a timeout or specify the maximum number of requests per connection. • Chunked-transfer encoding When a browser or Web client cannot anticipate the length of a request, it can transmit the data in chunks to the iTP Secure WebServer. The iTP Secure WebServer reassembles the request and processes it.
Web Clients Introduction to the iTP Secure WebServer Figure 1-1.
Introduction to the iTP Secure WebServer TCP/IP Subsystem TCP/IP Subsystem The HP NonStop TCP/IP subsystem allows processes on a NonStop System to communicate using the TCP/IP protocol. There are three versions of TCP/IP support available; conventional, Parallel Library, and TCP/IPv6. Conventional TCP/IP In essence, conventional TCP/IP has one listening process on each port. The conventional TCP/IP connections are managed by the Distributor process.
Introduction to the iTP Secure WebServer iTP Secure WebServer httpd the listening role (as opposed to one per processor in Parallel Library TCP/IP and TCP/IPv6). 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.
Introduction to the iTP Secure WebServer Pathway CGI Server For further information, see the iTP Active Transaction Pages (iTP ATP) Programmer’s Guide. Note. The iTP Secure WebServer does not support Microsoft Active Server Pages or ADO. 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.
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 The iTP Secure WebServer is shipped with the software it needs to use the WebSafe2 unit. You can begin using the WebSafe2 unit by unpaxing this additional software, making certain configuration changes, generating a key pair for the server, and obtaining and installing a new certificate from a CA. For more information about this topic, see Section 5, Integrating the WebSafe2 Internet Security Processor (WISP).
2 Installing the iTP Secure WebServer This section describes what you need to do to prepare your NonStop 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 These HP NonStop product versions are required for using the iTP Secure WebServer: • • • NonStop operating system version D42 or later RVU, or G03 or later RVU, or H06.03 or later RVU. For information about installing the NonStop operating system, see the INSTALL User’s Guide or the DSM/SCM User’s Guide. Open System Services (OSS) file system, D40 or later RVU.
Installing the iTP Secure WebServer Required Hardware other PATHMON environment on the same NonStop system. For more information, see Install a WISP on page 2-17 and The WebSafe2 Interface Driver (WID) on page 5-3. Note. WID and WISP are compatible only with systems running on G-series RVUs. • If you plan to use C run-time library to install EMS templates, see the C/C++ Programmer’s Guide.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer 3. Read this information if you intend to use the Parallel Library support of TCP/IP for iTPWebServer operations. Running the iTP Secure WebServer relies on the properly configured Parallel Library TCP/IP environment. Every processor specified in the Server CPUS command (in the httpd.config configuration file) needs to be enabled to run Parallel Library TCP/IP.
Installing the iTP Secure WebServer Preparing Your System for the iTP Secure WebServer created. In addition, dynamic servers can drop one or two connections when the Deletedelay effect occurs. Because all the httpd servers are designed to run on high PIN, creating more servers at the startup should not create a resource problem. • Specify a Larger Tandem_Receive_Depth The range is 1 to 255. The default is 50. Selecting a larger number prevents extra pathsends and possible socket migration.
Installing the iTP Secure WebServer Event Management Service (EMS) Template Installation 5. When you configure DNS, you must modify the file $SYSTEM.ZTCPIP.RESCONF to point to the DNS name server you are using. For information about starting DNS, see the TCP/IP Configuration and Management Manual. 6. For security, you should add a super ID (for example, super.webmastr) configured for the OSS environment, and you should use this super ID instead of super.super when installing the software. 7.
Installing the iTP Secure WebServer Installing and Configuring the iTP Secure WebServer 4. Run the template script to create the new versions of newres and newnres. 5. Run the install.EMS script, located in the /usr/tandem/webserver/TnnnnVnn_DDMMMYY_SPR_Vnnn_nn/admin/conf directory, as: : cd /usr/tandem/webserver/TnnnnVnn_DDMMMYY_SPR_Vnnn_nn/admin/conf : ./install.EMS The install.EMS script moves the template file to the proper NonStop directory, and merges the template file with the system template.
Installing the iTP Secure WebServer Before You Begin the Installation The procedure for installing the software depends on the distribution medium for the product. Check the Readme.txt file if you have received the software on a CD. Check the softdoc before you install the product. These installation instructions are correct as of the time this manual was published. However, the Readme.txt file or softdoc supersedes the information here.
Installing the iTP Secure WebServer Use DSM/SCM 6. To complete a typical installation of the iTP Secure WebServer, Run the Setup Script on page 2-11. Use DSM/SCM 1. Receive the SPR from disk or tape. 2. Copy the SPR to a new software revision of the configuration you want to update. 3. Execute the Build request and the Apply request on the configuration revision. 4. Run ZPHIRNM to rename the product files. 5. On the HP NonStop server, log on as SUPER.SUPER, go to $.
Installing the iTP Secure WebServer Copy the iTP Secure WebServer Software From the Distribution Medium 7. On the Host Target screen, either accept the default locations for Work and Backup subvolumes or browse to the locations of your choice. Click Next. 8. On the Host File Placement screen, you can either accept the default disk locations or browse to the locations of your choice. After confirming the choice of the locations, click Next. 9. On the Placement Manifest screen, review the file locations.
Installing the iTP Secure WebServer Run the Setup Script COPYOSS places the contents of the T8996PAX file into the version-specific OSS directory located at: /usr/tandem/webserver/ where is the vproc of this RVU (for example: V60_30JAN04_ABR_V606_1). The softdoc file, T8996ABR, is a text file that you can keep on$.SOFTDOC, or copy to any other location on your HP NonStop server by using the FUP DUP or FUP RENAME command. 3.
Installing the iTP Secure WebServer Run the Setup Script If you want to install the iTP Secure WebServer into an OSS directory other than /usr/tandem/webserver, specify the desired installation directory as a parameter to the setup script. For example: OSS: ./setup /home/myuser/mywebserver Note. • • The target installation path cannot be the same as the source path.
Run the Setup Script Installing the iTP Secure WebServer /G/YWEB) during auto configuration. However, during manual configuration, you will be prompted to supply two PATHMON names and at least one of the Parallel TCP/IP, TCP/IPv6, or IP CLIM transport service name. A sample interaction is as follows: Configuring iTP WebServer...
Installing the iTP Secure WebServer Setup for Parallel Library TCP/IP Support After the installation of iTP WebServer is complete, do not delete or modify the version-specific directory (/usr/tandem/webserver/) or its subdirectories. This is because the OSS symbolic links present in the directory where the iTP Secure WebServer was installed point to this directory tree.
Installing the iTP Secure WebServer Setup for TCP/IPv6 support TCP/IP Secure Port: 443 Test Certificate: CN=Secure Transport Bootstrap Certificate, OU=Testing Only - Do Not Trust for Secure Transactions, OU=No Assurance - Self-Signed, OU=Generated , O= Pathmon name: /G/zweb Guardian Pathmon subvolume name: /G/system/zweb.
Installing the iTP Secure WebServer Setup for IP CIP Support There are other dialogs with the setup script if you choose conventional TCP/IP support, or support for both types of support. LNP Support for TCP/IPv6 LNP can be viewed as an instance of the Conventional TCP/IP (T9551) process that spans all CPUs within a system. Each LNP can logically be viewed as a different Conventional TCP/IP process running on the system with its own set of IP addresses.
Installing the iTP Secure WebServer Install a WISP system and prompts for your response. Following are some examples of the interaction: If you wish to use IP CLIM as your underlying transport services, you need only one CIPSAM (CIP Socket Access Method) process. Therefore, the following lookup process will only list the first one it encounters. If you wish to use a CIPSAM process other than the first one in the list, please follow the manual configuration procedures.
Installing the iTP Secure WebServer Installation Considerations prior to installation. See Section 10, Using the Resource Locator Service (RLS) for information on using RLS. Installation Considerations • Pathway CGI applications that are built with a newer version of the libcgi.a library than the version of the httpd server may not run correctly. If you encounter problems, verify that the httpd object and the libcgi.a library are of the same version by following these steps: a.
Installing the iTP Secure WebServer Upgrading iTP Secure WebServer online Upgrading iTP Secure WebServer online You can upgrade a running iTP Secure WebServer environment to a higher version without taking it offline. To accomplish this, the current version must support the onlineupgrade feature. During this process, one Pathmon will be brought down for upgrading webserver objects with those of the newer version, while other Pathmon serves the requests with older webserver objects.
Installing the iTP Secure WebServer Upgrading iTP Secure WebServer online TACL> LOGON SUPER.WEB TACL> OSH OSS: cd /usr/tandem/webserver/ /usr/tandem/webserver/: ./setup /home/iTP *** Welcome to iTP WebServer Setup *** iTP WebServer will be installed into directory: /home/iTP *** WARNING *** A user ID other than SUPER.SUPER should be used to execute this setup program. It is recommended that a super ID (such as SUPER.
Installing the iTP Secure WebServer The Ninety-Day Test Certificate Checking required files... [OK] Press Enter key to continue... Using TCPIPv6 as your default transport service. Installing new files, creating/updating links ..
Installing the iTP Secure WebServer If You Plan to Use SSL or PCT Encryption 2. Use a Web client to connect to the Administration Server through its IP address or DNS name (as specified during installation). The Web client displays the iTP Secure WebServer Administration Server home page. 3. Click the View button to view your configuration files or the Edit button to edit those files. 4. Click the Start or Restart button to start the iTP Secure WebServer. 5. Check the EMS log file for startup messages.
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, TCP/IPv6, and IP CIP: The Auto Accept Feature For more information about the OSS environment, see the Open System Services User’s Guide. For more information about the Pathway environment, see the TS/MP System Management Manual. Parallel Library TCP/IP, TCP/IPv6, and IP CIP: 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, TCP/IPv6, and IP CIP 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? These subsections discuss issues to consider with respect to the iTP Secure WebServer PATHMON environment: • • • • • Who Can Modify the Configuration Files? on page 3-6 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 o
Planning the iTP Secure WebServer PATHMON Environment Common Gateway Interface (CGI) Application Security Considerations For ports with a value from 1 through 1024 (including the default), super ID users (for example, super.webmastr) can access the port with no restriction. Use a super ID to install and start the iTP Secure WebServer. For security reasons, super.super is not recommended.
Planning the iTP Secure WebServer PATHMON Environment Protecting the Server Password The key database file contains sensitive information that must be protected. The iTP Secure WebServer protects the database by encrypting it, and by requiring a password to access it (decrypt it). One way that you can protect the key database file is by protecting its password (see Protecting the Server Password on page 3-8).
Planning the iTP Secure WebServer PATHMON Environment Protecting Core Dumps Protecting Core Dumps Any server can fail and dump core, and core dumps of the iTP Secure WebServer can contain keys and the server password. You must protect core files as carefully as the key database file and server password files. Consider who has physical access to them, whether the files can end up on a backup tape, what their file protections are, and so on.
Planning the iTP Secure WebServer PATHMON Environment Protecting Transmission of Key Database Files and Core Dumps iTP Secure WebServer System Administrator’s Guide —523346-012 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 Overview of Server Configuration RequireSecureTransport command to the Region directive for the /admin/* region, as shown in this example: Region /admin/* { RequireSecureTransport AllowHost *.company.com RequirePassword {WebServer Administration User}\ -userfile /conf/adm.passwd IndexFile index.
Configuring for Secure Transport Server Configuration Server Configuration After you have used the keyadmin utility for server configuration, complete the server configuration by following these steps: 1. Specify the path name of the key database file by using the KeyDatabase configuration directive. See KeyDatabase on page A-28 for information about using this directive. 2. Specify the password for decrypting the key database file.
Configuring for Secure Transport Managing Certificates Use the HTTPS protocol specifier (https) in anchor specifications to specify that the Web client use SSL or PCT, as this 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.com:444/recipes Managing Certificates Each iTP Secure WebServer must have a public key pair for encrypting and decrypting secure transactions.
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. For complete list of supported DN attributes, see Table 4-2 on page 4-25. 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.
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 To use VeriSign’s Global Server ID with the iTP Secure WebServer, obtain a Global Server ID for the server and install it just as you would a regular certificate. See Using the Keyadmin Utility to Manage Keys and Certificates for information about obtaining and installing certificates.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates You can access this form from the CA’s home page on the Web. For a list of supported SSL server certificates, see the Web page at this URL (specify that you need an SSL server certificate): http://www.verisign.org • • The DN you have decided to use to identify your server. The password associated with the server’s key database file.
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, be sure to enclose any value containing a comma with quotation marks (").
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates You can 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.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -webmaster webmaster-name -phone webmaster-phone-num -software software adds any of these plain text fields to the certificate request. The information in these fields are for your convenience and do not affect the keyadmin command. Be sure to include single quotes (‘) or double quotes (“) around any entries that contain a space.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates For information about installing a certificate for use with a WebSafe2 unit, see Step 5. Installing the Certificate on page 5-14. Note. WebSafe2 unit is compatible only with systems running on G-series RVUs. Adding Certificates With DNs That are Different From the Key Generation DN You can add certificates that have DNs that are different from the DN used during key generation.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates -force specifies that a renewal of an older certificate should occur, 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: bin/keyadmin -keydb conf/mykeys -addcert my-cert.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-1.
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 Disabling or Enabling a Certificate To disable a certificate or enable a previously disabled certificate in the key database file, use the following keyadmin command. You can enter the arguments in any order. Enter the entire command on a single command line.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Changing the Key Database File Password Use the following keyadmin command to change the password with which the server’s key database file is encrypted. You can 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. bin/keyadmin -keydb keydb -chpw [-verbose] Note.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates This command lists the attributes of the certificates in the key database file. If you do not specify any of the options, the server displays all certificates in the database. Otherwise, you can specify precisely the certificate attributes you want displayed, by using the optional command components. The options are mutually exclusive.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Private Key: Not present Public Key: Present Certificate: Present -----------------------------------Distinguished Name: CN: Secure Transport Bootstrap Certificate OU: Testing Only - Do Not Trust for Secure Transactions OU: No Assurance - Self-Signed OU: Generated Wed Mar 5 17:36:57 EST 1997 O: fenway.company.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates Example 4-2. Example Default Root Certificate (page 1 of 4) ----------------------------------Distinguished Name OU: Class 4 Public Primary Certification Authority O: Verisign, Inc. C: US State: Root Enabled Private Key: Not Present Public Key: Present Certificate: Present ----------------------------------Distinguished Name OU: Class 3 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 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 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 can enter the arguments in any order. Enter the entire command on a single command line.
Using the Keyadmin Utility to Manage Keys and Certificates Configuring for Secure Transport keyadmin simply overwrites the existing entry without prompting first (but does generate a message to indicate that it has overwritten the entry). 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.
Using the Keyadmin Utility to Manage Keys and Certificates Configuring for Secure Transport Table 4-2. Supported DN Attributes (page 2 of 2) Attribute Required Encoding Type GQ: Generation Qualifier Directory String NAME: Name Directory String Note: Directory String can take one of these encoding formats, UTF-8 String (if the –utf8 option is specified during key-pair or certificate request generation), Printable String (default encoding if the –utf8 option is not specified), or T.
Configuring for Secure Transport Using the Keyadmin Utility to Manage Keys and Certificates [-dn 'dn'] specifies the DN to be used to identify the newly created entry for the imported key. This parameter is ignored if the corresponding certificate already exists in the key database. For example: ./keyadmin -keydb demo.db -importpriv priv.key -dn 'CN=www.hp.
Configuring for Secure Transport Using Server Certificate Chains With the iTP Secure WebServer Using Server Certificate Chains With the iTP Secure WebServer The iTP Secure WebServer’s SSL 3.0 protocol allows you to send and receive certificate chains. With the certificate chain option, you can establish a certificate hierarchy that is more than two certificates deep. Server certificate chain support allows iTP Secure WebServers to use VeriSign Global Server IDs, which are certificate chains.
Configuring for Secure Transport Managing Client Authentication certificate file (a plain text file). Add this certificate to the designated key database file using the keyadmin utility. For details about adding certificates using keyadmin, see Adding a Certificate to the Key Database File on page 4-11. Managing Client Authentication For SSL 3.0 the server always authenticates itself to its clients.
Configuring for Secure Transport Using the -requireauth Option Therefore, the server’s action depends on its specific configuration, as shown in the list of variable settings in Using the -requestauth Option.
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 these values: No certificate The certificate does not exist.
Configuring for Secure Transport Updating SSL and PCT Configuration Valid certificate but root certificates do not 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 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 RegionSet goodusers $goodusers Region /* { RequireSecureTransport -auth $goodusers } This command allows access only to clients who have presented a certificate by using one of the DNs specified in goodusers. Using SSL and PCT Environment Variables in CGI Programs You can use SSL and PCT environment variables to access information about individual requests from within CGI programs.
Constraints on Cipher Use Configuring for Secure Transport (SHA1), was developed by the U.S. government. For most applications, either cipher provides sufficient security. Negotiating Selection Among Available Ciphers Use the -ciphers option to specify a Tcl list of ciphers that describe the bulk encryption and hash algorithms the iTP Secure WebServer will use. If you specify no -ciphers option, all the ciphers are set by default.
Configuring for Secure Transport Constraints on Cipher Use The actual key used depends on the Web client’s choice. The session is terminated if the Web client does not support the key sizes supported by the iTP Secure WebServer.
Configuring for Secure Transport Constraints on Cipher Use iTP Secure WebServer System Administrator’s Guide —523346-012 4- 38
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). Note. WISP is compatible only with systems running on G-series RVUs.
Integrating the WebSafe2 Internet Security Processor (WISP) Figure 5-1. WebSafe2 Internet Security Processors (WISPS) in an iTP Secure WebServer Environment NonStop Operating System iTP Secure WebServer 3615 Ethernet LAN Controller Web Clients WebSafe2 Interface Driver (WID) 3615 Ethernet LAN Controller WebSafe2 Internet Security Processors (WISPs) VST003.
Integrating the WebSafe2 Internet Security Processor (WISP) The Secure Configuration Terminal (SCT) secure location for these tasks to be performed, preventing unwanted access to keying material. The contents of WISPs are protected by the MFK, which is a key loaded into it at initialization time. The WISP can only be initialized and managed using a device called a Secure Configuration Terminal (SCT); it cannot be controlled or its contents accessed using a network connection.
Integrating the WebSafe2 Internet Security Processor (WISP) How the iTP Secure WebServer Uses WebSafe2 Internet Security Processors (WISPs) The number of WISPs need not be as great as the number of WID processes: multiple WID processes can use the same WISP. How the iTP Secure WebServer Uses WebSafe2 Internet Security Processors (WISPs) Note. WISP is compatible only with systems running on G-series RVUs.
Integrating the WebSafe2 Internet Security Processor (WISP) Fault-Tolerance Requirements other keys. The server uses the master key to generate its SERVER-READ and SERVER-WRITE session keys. 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 See Installing the WebSafe2 Interface Driver (WID) on page 5-7. 4. Configure the iTP Secure WebServer for WISPs. See Configuring the iTP Secure WebServer for WebSafe2 Internet Security Processors (WISPs) on page 5-7. 5. Generate the public/private key pair and obtain a certificate.
Integrating the WebSafe2 Internet Security Processor (WISP) • Preparing a Distinguished Name (DN) for the Certificate If you intend to use SSL 3.0 services with the WISP, you need to install the latest version of the WID. See Installing the WebSafe2 Interface Driver (WID) on page 5-7 for specific information. 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.
Integrating the WebSafe2 Internet Security Processor (WISP) Configuring the iTP Secure WebServer for WebSafe2 Internet Security Processors (WISPs) The install.WS script prompts you for the DN, the IP addresses of the WISPs, and the TCP/IP process name for each address. If you are running install.WS with the upgrade or -websafe option, the script automatically detects the presence of your old configuration, saves the old httpd.websafe.config file as httpd.websafe.config.
Integrating the WebSafe2 Internet Security Processor (WISP) Configuring the iTP Secure WebServer for WebSafe2 Internet Security Processors (WISPs) 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.config in this directory and restart the server. Copying files...
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Generating the Public/Private Key Pair and Obtaining the Certificate The WISP generates a public/private key pair and sends it to the NonStop system, where it is stored in the file named by the keyfile statement in wid.config. A certificate is obtained by sending a certificate request to a recognized Certificate Authority (CA).
Integrating the WebSafe2 Internet Security Processor (WISP) f. Generating the Public/Private Key Pair and Obtaining the Certificate 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. Record the right portion of the cryptogram.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate character as shown. The backslash is not permitted to break the DN value across lines. bin/keyadmin -websafegen [key-req-file] \ -widconf wid-config-file -dn 'dn' -kek_mfk0 kek-cryptogram \ [-kek_clear kek-value] [-length key-length] [-verbose] [-utf8] Note. The bin/ prefix indicates the directory that contains the keyadmin utility.
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. -utf8 specifies that the DN attributes specified while generating a Public/Private key pair and a certificate request are UTF-8 encoded. Note. All DN attributes cannot be UTF-8 encoded.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate 1. Select Encryption Key MFK1. 2. Define Key Under MFK1. 3. Select 1 for a single length (8-byte) key. 4. Enter 1 as the number of key parts. 5. Select the MFK. 6. Enter input variant 310. 7. 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. 8. Record the left portion of the cryptogram. 9.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate A sample newdn.txt file is: DN used at the time of key generation is: CN=hima.lab201.tandem.com, OU=datadev, O=tandem, L=cupertino, ST=california, C=US New DN in the certificate to be added is: CN=hima.lab201.tandem.com, SN=297-68-2381, OU=a-sign.datadev.
Integrating the WebSafe2 Internet Security Processor (WISP) Generating the Public/Private Key Pair and Obtaining the Certificate Example This 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 thse 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.0 only Upgrade as needed for SSL 3.
Integrating the WebSafe2 Internet Security Processor (WISP) Using Earlier Version Keys and Certificates Keys Were Generated 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 Note. WISP is compatible only with systems running on G-series RVUs. 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. Installing the Latest WebSafe2 Interface Driver (WID) Software Note.
Integrating the WebSafe2 Internet Security Processor (WISP) Switching From WebSafe2 to Software Encryption Switching From WebSafe2 to Software Encryption Note. WebSafe2 encryption is supported only on systems running G-series RVUs. If your configuration includes WISPs, and you decide to switch to software encryption—for example, if you want to use PCT—you must do these: 1.
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 VST005.
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: : 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 You should not get any error messages. 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 -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, and 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.
Managing the iTP Secure WebServer Using Scripts Description The -restarth argument applies configuration changes only to the Distributor process, the httpd process, and the Servlet Server Class (SSC). Do not specify changes to the PATHMON configuration. The -restarth argument does not apply these kinds of changes: • • • The arguments to other server classes such as generic-cgi.
Managing the iTP Secure WebServer Using Scripts PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes PATHMON Environment’s Autorestart for the iTP Secure WebServer and Related Processes Because the iTP Secure WebServer and related processes run in a PATHMON environment, a process that fails is restarted automatically, ensuring persistence of its service. (PATHMON does not automatically restart a process that the operator has explicitly stopped.
Managing the iTP Secure WebServer Using Scripts statscom Command Using the statscom Command Following are the various command-line options that can be performed using statscom ($PATHMON is the PATHMON name for webserver, %DOMAIN is the DOMAIN of iTP WebServer running in the online-upgrade mode).
Managing the iTP Secure WebServer Using Scripts statscom Command This command collects statistics for all httpd processes in PATHMON $PATHMON for parameters specified in user-specified config-file. The output of all of the above commands is a Comma Separated Value list that can be read in Microsoft Excel. • statscom -stop $PATHMON [config-file] This command stops the statistics gathering for all httpd processes in PATHMON $PATHMON. For example, ./statscom -stop \$SWEB OR .
Managing the iTP Secure WebServer Using Scripts statscom Command where config-file is the user-specified configuration file. • statscom -submit \%DOMAIN [config-file] This command stores the httpd statistics in the statistics.csv file under the logs directory of the webserver. For example, ./statscom -submit \%WEB This command collects complete statistics for all httpd processes in DOMAIN $DOMAIN OR .
Managing the iTP Secure WebServer Using Scripts statscom Command Sample Configuration File for statscom The sample configuration file for statscom (statparams.config) is located in the conf directory of the webserver. Statistics collection for a particular parameter can be enabled by specifying ON in front of the parameter in the configuration file.
Managing the iTP Secure WebServer Using Scripts Collecting Webserver Statistics Using timestat script TotalTransactionCompleted Total number of transactions completed ReceivedPassonRequest Total number of pass-on requests OutgoingPathsends Number of outgoing Pathsend requests TotalPathwayInterfacesOpen Total number of Pathway interfaces open TotalOpenFileDescriptors Total number of open file descriptors ConnectionsOnSocketOperation Number of connections on a socket Collecting Webserver Statistics Using t
Managing the iTP Secure WebServer Using Scripts Collecting Webserver Statistics Using timestat script Statistics of all the httpd processes are gathered and stored in the statistics.csv file under the logs directory of the webserver. It will be overwritten if already present.
Managing the iTP Secure WebServer Using Scripts Collecting Webserver Statistics Using timestat script iTP Secure WebServer System Administrator’s Guide —523346-012 6- 14
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 This 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. # # ServerName web.
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 might 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, TCP/IPv6, or IP CIP 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.
The Secure Transport Configuration File (httpd.stl.config) Configuring the iTP Secure WebServer The Secure Transport Configuration File (httpd.stl.config) Example 7-2 on page 7-8 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.
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.log if {[info exists CacheSize]} { Env SK_CacheSize=$CacheSize } if {[info exists CacheExpiration]} { Env SK_CacheExpiration=$CacheExpiration } } } Other Configuration Files Note.
Understanding How URLs Work Configuring the iTP Secure WebServer Understanding How URLs Work Objects on your iTP Secure WebServer are accessed by means of Universal Resource Locators (URLs). A URL is composed of these five elements: 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.
Mapping Requests to Contents Configuring the iTP Secure WebServer 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 see the file /usr/disk0/info/doc.html while the URL http://my.server.com/dictionary/entry/ants.html will see the file /usr/disk7/entry/ants.html Handling Directory Accesses A URL can see a directory instead of a specific object. For example: http://my.server.
Configuring the iTP Secure WebServer Mapping Requests to Contents You can configure your server to automatically generate an index file whenever the server cannot locate an index file within an accessed directory. This generated index file lists all the files currently residing in the accessed directory. For complete information on automatic indexing, see Enabling Automatic Directory Indexing on page 7-36.
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, and 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 these criteria, the server returns the one that offers the best match according to these 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.
MaxFileCacheContentSize Configuring the iTP Secure WebServer 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 describes how to manage your log files including: • • • Choosing a Log Format Planning Space for Logs on page 7-24 Rotating Log Files on page 7-24 Choosing a Log Format You can choose between three formats for your server log files: • • • Common Log Format (CLF) Combined Log Format Extended Log Format (ELF) Common Log Format (CLF) The common log format (CLF) is used by the access and error log files and is specif
Planning Space for Logs Configuring the iTP Secure WebServer • • • Fields are provided for security information, such as the name of an authenticated user. The name/value pairs used for the information fields support the addition of new logging fields (such as a field for security information). The overall format makes it easy to write new log-analysis programs. If you plan to write your own log-analysis programs, or if you need to use the additional information fields, you might want to specify ELF.
Configuring the iTP Secure WebServer Rotating Log Files current log files in an archive directory called ArchiveLogs and causes the iTP Secure WebServer to begin writing to new ones; the iTP Secure WebServer continues the operation. The old log files will be saved with a timestamp attached to their names when the rollover occurs. You run the rollover script from the /usr/tandem/webserver/conf directory: : cd /usr/tandem/webserver/conf : .
Configuring the iTP Secure WebServer Setting Up Server Aliases starts the server, saves the log files that were current when the server was stopped, and opens new log files. The following command: : httpd -restarth -rollover configfile_name dynamically restarts the server so that configuration changes can take effect immediately. The iTP Secure WebServer continues operation, the log files that were current when the server was started are saved, and new log files are opened.
Configuring the iTP Secure WebServer Why Aliases Are Useful you might select the following name as its DNS alias: www.compedia.com After registering this name with the DNS, you can then advertise www.compedia.com as the name of your server. Users making requests through this alias would actually be accessing aegean.compedia.com. Why Aliases Are Useful The major benefit to using an alias is flexibility.
Configuring the iTP Secure WebServer Setting Up an Alias Setting Up an Alias To set up an alias for your server: 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-40 Allowing Byte Ranges on page 7-43 Implementing Multiple-Host Support on page 7-43 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.
Administering Passwords Configuring the iTP Secure WebServer 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. -safeguard allows to use the Safeguard user ID database for authentication. Note.
Configuring the iTP Secure WebServer Administering Passwords Creating a New Password File To create a new password file: useradm create [-digest] file-name where: -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: 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
Configuring the iTP Secure WebServer Redirecting Access the current password, the provided user-name will be deleted. Three unsuccessful attempts will abort this process.
Configuring the iTP Secure WebServer Redirecting Access This Redirect command tells the server to redirect a request for a specified object and specifies a fully qualified alternate URL (alt-url). For example, if you move the HTML document /info/stats.html to /statsinfo.html on a different host machine (www.widgets.com), you could use the following Region directive to redirect requests for this file: Region /info/stats.html { Redirect http://www.widgets.com/statsinfo.
Configuring the iTP Secure WebServer Enabling Automatic Directory Indexing Enabling Automatic Directory Indexing You can enable automatic indexing for server directories. Under automatic indexing, if a request corresponds to a directory for which no index file is available, the server automatically generates one. To enable automatic indexing, you use the DirectoryIndex command in a Region directive.
Configuring the iTP Secure WebServer Using Multiple Region Commands For example, if your company domain is wonka.com, you could use this directive to disable logging for all requests from within your company: Region * { NoLog *.wonka.com } To disable logging for requests affecting only files that have the .gif extension, you would specify: Region *.gif { NoLog } Using the NoLog command with a host name only works if there is Domain Name Server (DNS) reverse lookup available for the specified host name.
Configuring the iTP Secure WebServer Using Multiple Region Commands You can enter any number of Region directives in your server’s configuration file. Therefore, a request might be processed by more than one directive, depending on how the URL matching patterns in the directives are specified. For example, if the configuration file contains the Region directives, Region * { DirectoryIndex } Region /admin/* { 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 want 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.) The if statement has this syntax: if condition { if-true } else { if-false } If condition is non-zero (indicating true), the if-true statement is executed; otherwise, the if-false statement (in the else clause) is executed.
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, see Region on page A-49. 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 this 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 want 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 Implementing Multiple Servers There are two ways to configure multiple servers on the same machine: • • Using Different Ports Using Different IP Addresses 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 topics related to TCP/IP configuration on 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 or AcceptSecureTransport directives to associate specific IP addresses with specific host names or ports. Then associate content regions with these virtual hosts by using Region directives, using the -host 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 subsection describes 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-35.
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, suppose that you have an HTML document with an inline image specified as: 
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 211
Setting Up a Server-Side Include (SSI) Configuring the iTP Secure WebServer Figure 7-1. Image Map Areas (50,50) (100,100) (50,200) (200,50) (100,200) (50,250) VST006.vsd 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 on page 7-52), 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.
Setting Up a Server-Side Include (SSI) Configuring the iTP Secure WebServer 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 path name relative to the directory in which the document with the #include occurs. The path ./ cannot be used in this path name, nor can absolute paths be used. As for the virtual option, you can access other static documents, but not CGI scripts. For example:
