Patch-ID# 106756-01 Keywords: security ENCRYPTION INTERNATIONAL WebServer 1.0 performance SKI/SSL domestic Synopsis: Sun WebServer 1.0: Security and Performance domestic (US/CANADA) Patch Date: Dec/10/98 ****************************************************** The items made available through this website are subject to United States export laws and may be subject to export and import laws of other countries. You agree to strictly comply with all such laws and obtain licenses to export, re-export, or import as may be required. Unless expressly authorized by the United States Government to do so you will not, directly or indirectly, export or re-export the items made available through this website, nor direct the items therefrom, to any embargoed or restricted country identified in the United States export laws, including but not limited to the Export Administration Regulations (15 C.F.R. Parts 730-774). ****************************************************** Solaris Release: 2.5.1, 2.6 SunOS Release: 5.5.1, 5.6 Unbundled Product: Sun WebServer Unbundled Release: 1.0 Relevant Architectures: i386 BugId's fixed with this patch: 4059435 4059811 4059824 4063346 4067890 4070306 4070945 4074172 4078510 4081194 4094281 4094283 4099847 4104865 4108020 4108022 4108098 4117486 4117682 4124932 4125104 4127477 4128710 4129204 4132533 4131473 4049393 4134275 4146506 4148652 4154106 4155910 4162111 Changes incorporated in this version: Patches accumulated and obsoleted by this patch: Patches which conflict with this patch: Patches required with this patch: Obsoleted by: Files included with this patch: NOTE: The packages included in this patch are: SUNWfns Up-to-date Federated Naming Service files. SUNWhttpr Basic configuration information. SUNWhttpu HTTP and HTPASSWD binaries, administration Java code, SSL scripts, and Verisign certificates. SUNWhttpv Default server root and document root, and online documentation. SUNWski SKI library. SUNWskica Encryption software for generating key packages and certificates. SUNWskicw Licensing software for the Root CA. SUNWskimc SKI 1.0 Software (CA Manual Page Package). SUNWskimu SKI 1.0 Software (CA User Manual Page Package). SUNWssl SSL 1.0 Software (Global Version Library). SUNWskild SKI 1.0 Software Package (US and Canada Library). SUNWssld SSL 1.0 Software (US and Canada Library). Problem Description: SSL libraries and server support Verisign certificates on the server. SSL API is extended in order to set other variables for CGI requests that came over a secure connection. These variables are HTTPS, HTTPS_KEYSIZE, HTTPS_SECRETKEYSIZE, SSL_CLIENT_DN, and HTTPS_CIPHER. When setup_creds fails because -d is not specified, the server prints an error message. SSL supports client authentication with Microsoft Internet Explorer. The setup_creds parameter no longer results in a segmentation fault for Solaris 2.6 when it is replaced with new FNS pkgs. SSL set up and configuration has been simplified. SKI/SSL packages are i18n compliant. Server-Side Includes (SSI) do not send Content-Length headers. SSI environment variables DATE_GMT and DATE_LOCAL are set correctly. Active port ceiling of 1024 has been eliminated, and the maximum concurrent connections the server can handle has been increased. Sun WebServer 1.0 properly handles all string content in HTTP headers ("if-modified-since", "if-unmodified-since" and "Range"). The server creates a log entry for httpd -validate, and returns a status of 2 if validation fails. An error message is logged for failed Basic and digest authentications. The server logs an error message for failed mmap calls. Redirecting HTTP 501 errors does not lead to core dump when unknown HTTP method is sent. Changed the default_file parameter so that it can exist in both the server and host blocks. The entry in the host block overrides the entry in the server block. The server is not case sensitive when resolving virtual host names. Trailing "/" is handled properly in virtual host names in httpd.conf. You can list multiple URLs in one ACL block. The server prints an error message if daemon creation fails. Patterns such as "/.." do not cause httpd to loop and take up CPU usage. The server properly handles such patterns. The arbitrary override of request timeout has been removed, and the upper limit on how many seconds a CGI script can take is specified by user. Sun WebServer 1.0 Administration Console displays on Netscape Communicator 4.05 AWT 1.1.4 version, HotJava 1.1.4, and Internet Explorer 4.0. Sun WebServer 1.0 Administration Console usability form has a Submit button. Server timeout, request_timeout, and threads_n_active have no upper limit. File listings can handle space separated file names properly. File stat information gets updated when the file is updated. Sun WebServer 1.0 expands request with encoded slashes ('/'), and handles the request including encoded slashes properly. For digest authentication, a login prompt is resent if the user enters incorrect login information. CGI scripts' stderr is no longer logged into the access log. The server safely discards this data. Removed spurious locks to prevent the CPU load from increasing excessively with the number of idle keep-alive connections. The directive log_translate_ip_address is not documented in the /etc/http/httpd.conf file. This directive determines whether a given virtual host logs its IP address or DNS name into its log files. Default is "no" and the IP address is logged. It is recommended to download and install the following applicable Kernel patch: Solaris 2.6: 105181-xx (SPARC) 105182-xx (Intel) Solaris 2.5.1: 103640-xx (SPARC) 103641-xx (Intel) Note: For Solaris 2.5.1, you may choose to download the latest Solaris 2.5.1 patch cluster(103640 for SPARC or 103641 for Intel) which includes the Kernel patch along with other updates to Solaris 2.5.1. Patch Installation Instructions: -------------------------------- You can not use the generic 'installpatch' and 'backoutpatch' scripts to install the packages in this patch. Instead, you must remove all old packages before installing the new ones. It is recommended that you backup your document tree and configuration files before beginning this process. To install Sun WebServer using the pkgadd command: 1. Become superuser. % su 2. Remove old packages. Execute the following commands: Note: | Substitute SUNWssld for SUNWssl, and add SUNWskild if you are using | the domestic version of SWS1.0 # pkgrm SUNWhttpu SUNWhttpv SUNWhttpr SUNWski SUNWskicw \ SUNWskica SUNWskimc SUNWskimu SUNWssl If this command fails because the package SUNWski is not installed, then you previously had a version of SWS without SSL support. In any case, remove the SUNWhttpu, SUNWhttpv, and SUNWhttpr packages. On Solaris 2.5.1 and Solaris 2.6 systems, execute: # pkgrm SUNWfns Ignore any warnings about dependencies. If the system reports that no SUNWfns package is installed, that is not a problem; carry on with step 3. 3. Change (cd) to the directory where you unpacked the archives. For example: Note: | The packages are located in the directory where you unpacked the | archives; however, the actual directory names may vary. # cd /tmp 4. Install the SSL packages. Install the packages in the order specified below, as some packages have dependencies on other packages. The installation process is interactive and will prompt you for answers. Answer "yes" to all questions in the pkgadd process. A. Install the updated version of SUNWfns. SUNWfns is located in a separate subdirectory for Solaris 2.5.1 and Solaris 2.6. For Solaris 2.5.1, use the following pkgadd command: # pkgadd -d fns2.5.1 SUNWfns For Solaris 2.6, use the following pkgadd command: # pkgadd -d fns2.6 SUNWfns B. Install the SUNWski and SUNWssl packages. There are two cases, depending on whether you have a domestic or global version. If you have the domestic version, execute this command. # pkgadd -d . SUNWski SUNWskild SUNWskica \ SUNWskicw SUNWskimc SUNWskimu SUNWssld Note: | The SUNWskild package must be installed after | the SUNWski package to ensure the integrity | of all symbolic links. OR, if you have a global version, execute this command: # pkgadd -d . SUNWski SUNWskica \ SUNWskicw SUNWskimc SUNWskimu SUNWssl 5. Install the Sun WebServer core packages. The installation process is interactive and will prompt you for answers. Answer "yes" to all questions in the pkgadd process. # pkgadd -d . SUNWhttpr SUNWhttpu SUNWhttpv Special Install Instructions: ----------------------------- If SWS1.0 is installed in a non-default location on your system, you should use the -R option for ``pkgrm'' and ``pkgadd'' (supplying the same as the original installation), when removing and replacing the Sun WebServer packages SUNWhttpu, SUNWhttpr, and SUNWhttpv. As with the original 1.0 release, the security related packages [list] must be installed in the default location. Additional Information: ----------------------- This patch allows you to use digital certificates signed by Verisign, Inc. with Sun WebServer. Currently, Verisign is the only third-party certificate authority supported by Sun WebServer. Please visit the Verisign web site at https://digitalid.verisign.com/ss_intro.html for information, policies, and pricing regarding Verisign certificates for Sun WebServer. This section contains instructions for acquiring and installing a Verisign certificate. ** Issues and Known Problems ** Digital certificates for Sun WebServer should be in PKCS#7 format. Verisign production certificates and self-signed certificates are in this format. Other web servers have their certificates in X.509 format. Since these formats differ, a certificate issued for a different server cannot be used with Sun WebServer. ____________________________________ SSL Configuration for Sun WebServer: Contents: I. SSL Requirements Overview A. Root Certificate Authority (Root CA) i. Root CA User ii. Root CA Host B. Federated Naming Service (FNS) C. SSL-Enabled Sun WebServer D. Unique IP for Web Site E. Certificate Signing II. SSL Configuration Procedures III. Root CA Configuration IV. Creating Credentials V. Enabling SSL on a Web Site VI. Requesting Signed Certificates VII. Enabling Client Authentication ___________________________________ I. SSL Requirements Overview This section explains each of the major components required at your site to use Secure Sockets Layer (SSL) with web sites. This is in- tended to give you an overview of what you must have in place and how the components interact. A list of the procedures to follow to configure SSL is in the "SSL Configuration Procedures" section below. Before a web site can use SSL, it must have public and private keys for encryption and an X.509 certificate which it can present to clients. The certificate contains the web site's identity (disting- uished name), the identity of the issuer, the web site's public key, and the digital signature of the issuer. Public web sites typically get certificates signed by a third-party certificate authority (CA) such as VeriSign; if a client also has the public key of the third- party CA, it can trust that the site's identity has been verified and is authentic. NOTE | "Credentials" in this document refers to a key package: | public and private encryption keys-and an associated | certificate. Sun WebServer includes software for running a CA. The CA can create SSL credentials for web sites. Other tools allow you to install the web site's credentials for use by a Sun WebServer instance, to get credentials signed by a third-party, and to install third-party certificates. The following must be completed at your site to run SSL: . Create root certificate authority (Root CA). . Install federated naming system (FNS). . Install Sun WebServer with SSL. . Use unique IP address for web sites that use SSL. . (Recommended) Request signed certificates from an independent CA. ___________________________________ I.A Root Certificate Authority (Root CA) You need to create a Root CA at your site to create credentials for web sites. A Root CA user will create credentials for itself, and then use the credentials to create key packages and sign certificates for web servers in your network. You may store the credentials in the Federated Naming Service (FNS) for easy accessibility from other machines, or you can store them only in files on the Root CA machine to limit access. By default, they are stored in /var/fn. The Root CA host (where credentials are created) does not need to be the same machine as Sun WebServer, and for security reasons you may want to run the Root CA on a different machine or a machine with no network access at all. NOTE | The preceding steps need to be completed only for self- | signed certificates. It is not needed if only third-party | certificates are used. ___________________________________ I.A.i. Root CA User You can use any user name except for root (UID 0) on the Root CA host to be the Root CA user. The Root CA user is the only user that can create credentials for web sites. The Root CA user will have its own, password-protected credentials which are used to sign all of the certificates it creates. The Root CA credentials are bound to a distinguished name (DN) entry. All credentials are bound to a DN. The Root CA distinguished name uses the following attributes: Attribute Type Abbreviation Example Common name cn cn=rootca Email address em em=rootca@A.net Serial number serial serial=no12345 Organizational unit name ou ou=web Organization Name o o=A.net Locality name l l=internet State or province name st st=California Country name c c=US The order of the attributes matters in the DN. The DN must begin with the most specific attribute and continue to the least specific. The attributes are listed in the table from most specific (common name) to least specific (country). All credentials are stored in a directory owned by the Root CA user, which should not be publicly readable. The Root CA user's credentials (as well as each web site's credentials) will be available through the Federated Naming Service (FNS). ___________________________________ I.A.ii. Root CA Host All computers that use SSL or key packages will need to have the security tools packages installed. There must be at least one machine, the Root CA host, where . The user name of the Root CA exists. . The credentials of the Root CA are stored. . FNS is properly installed. The Root CA will create and store credentials for web sites on this host. Running Sun WebServer on the Root CA host is not necessary. A Sun WebServer machine can get access to the credentials for web sites it hosts by copying the files from the Root CA hosts. ___________________________________ I.B. Federated Naming Service (FNS) FNS is the interface the SSL security tools use to access credentials. The Sun WebServer security packages create a name service context in which to store and retrieve credentials from files. Remove any existing FNS packages and install the SUNWfns package bundled with Sun WebServer. This step is done before you install Sun WebServer. If you did not remove SUNWfns and install the bundled package, do so now on hosts where you will use SSL, including the Root CA host. NOTE | The SUNWfns package that is part of Solaris 2.5.1 and 2.6 will | not work with SSL. Removing the package will not cause you to | lose any data, and your existing FNS contexts will be | preserved once the new SUNWfns package is installed. | You can get the package version by running ``pkginfo -l SUNWfns''. | The required versionf of SUNWfns are ``11.5.1,REV=1.0'' | if you are running Solaris 2.5.1 and `11.6.0,REV=1998.07.1.1.1'' | if you are running Solaris 2.6. If the VERSION string you | see when you run ``pkginfo'' does not match these values | exactly, then you must install the SUNWfns packages included | with Sun WebServer. ___________________________________ I.C. SSL-Enabled Sun WebServer To support SSL for web sites, you need an instance of Sun WebServer that has all of the SSL packages and libraries available and has SSL enabled on a port for each IP address where SSL will be used. Once credentials are created by the Root CA, the credentials must be installed on the Sun WebServer machine where the site is hosted. ___________________________________ I.D. Unique IP for Web Site The Root CA user creates credentials for a web site, using the web site's host name and IP address. The credentials must be bound to a unique host name and IP address, so there must be a unique IP address with an SSL port for each SSL-enabled site. ___________________________________ I.E. Certificate Signing When a client connects to an SSL enabled port on a web site, it requests the site's credentials. To verify the credentials, they must be signed by a CA for which the client has a public key and which the client trusts. Since most clients will not have your local Root CA's public key, you will want to get site credentials signed by a well known CA, such as VeriSign. ___________________________________ II. SSL Configuration Procedures This section lists the top level procedures to follow to configure SSL. If you are unfamiliar with the environment required for running SSL and a Certificate Authority, please refer to "SSL Requirements Overview" (above) before performing the following procedures: 1. Root CA Configuration 2. Creating Credentials 3. Enabling SSL on a Web Site 4. (optional) Requesting Signed Certificates ___________________________________ III. Root CA Configuration The Root Certificate Authority (CA) is required to create key packages and certificates for web sites on your network. See the "SSL Requirements Overview" (above) if you are unfamiliar with the role of the Root CA user and Root CA machine. You need to configure the Root CA machine, and then create the Root CA that can create credentials for web sites. ___________________________________ To Configure the Root CA Machine 1. Make sure that the correct packages for generating credentials are installed on the machine: SUNWhttp Contains tools and scripts for running the Root CA. SUNWfns Up-to-date Federated Naming Service files. SUNWski SKI library. SUNWskica Encryption software for generating key packages and certificates. SUNWskicw Licensing software for the Root CA. SUNWskimc SKI 1.0 Software (CA Manual Page Package) SUNWskimu SKI 1.0 Software (CA User Manual Page Package) SUNWssl SSL 1.0 Software (Global Version Library) SUNWskild SKI 1.0 Software Package (US and Canada Library) SUNWssld SSL 1.0 Software (US and Canada Library) These packages are installed automatically during Sun WebServer installation if you choose to install SSL. 2. Sun WebServer installation will start the processes required for generating security keys and certificates. Make sure that the following processes are running: . /usr/lib/security/skiserv . /usr/lib/security/cryptorand 3. Select or create a user to be the Root CA user. NOTE | This document will refer to this user as ``rootca'', | but you may choose any UNIX user name from /etc/passwd. 4. Create a directory owned by rootca where you can store credentials. This directory should not be readable by others. For example: # mkdir /var/SSL_CERTS # chmod 700 /var/SSL_CERTS # chown rootca /var/SSL_CERTS 5. Set the file mode creation mask: # umask 022 ___________________________________ To Create the Root CA 1. Determine the distinguished name (DN) entry for the root CA. For details see "Root CA User" above. An example DN is cn=rootca, o=A.net, st=California, c=US. 2. Log in to the Root CA machine as the Root CA user. 3. Run ``create_rootca'' If ``create_rootca'' is not available in /usr/bin, you have not installed the SUNWski package on this machine. 4. Enter the DN for the Root CA. Enter Distinguished Name (e.g. "o=SUN, c=US") or q[uit]: cn=rootca, o=A.net, st=California, c=US 5. Enter the directory name where credentials will be stored. Enter directory pathname under which the key package and certificate will be stored, or q[uit]. Directory name ? /var/SSL_CERTS The script will generate public and private encryption keys for the Root CA. All key packages are protected by a password to prevent unauthorized use. 6. Enter a password for the Root CA key package. keypkg: Enter your NEW key package password: keypkg: Reenter your NEW key package password: 7. You have the option of making the key packages available in the naming service. To store the key package in the naming service, you will need the machine's root password. Key packages are always stored in files. Making the key package available in the naming service allows other security tools to locate the keys without the full path name. 8. If you don't choose this option, save the credentials in FNS, and then store the credentials manually: # skistore -d where is as specified in step 5. The Root CA is now configured. The next step is for the Root CA to generate a key package and certificate for a web site. Continue with the next configuration procedure, "Creating Credentials." ___________________________________ IV. Creating Credentials The Root CA creates and stores credentials for web sites on the Root CA machine. The certificate can then optionally be signed by another CA, such as VeriSign. When the credentials are ready, they are installed on the Sun WebServer machine for use by the web site. NOTE | "Credentials" in this document refers to a key package: | public and private encryption keys-and an associated | certificate. ___________________________________ To Create Credentials for a Web Site 1. Determine the distinguished name entry for the web site, using the Fully Qualified Domain Name (FQDN) as the common name (cn). For details on the distinguished name in certificates, see "Root CA User" above. 2. Login to the Root CA machine as the Root CA user. 3. Create a directory where you can store the credentials you are about to create. rootca% mkdir /var/SSL_CERTS/121.122.123.12/ 4. Run ``/usr/http/bin/setup_creds'' with the appropriate options. Valid options are: -d Specifies the directory where credentials should be stored; for example, /var/SSL_CERTS/121.122.123.12/. -f (Not required; used to add certificates for other trusted CAs at setup time.) Specifies the full pathname to the file containing the Root CA certificate, for example, /export/skirca2/certs/skirca2.CERT. -i Specifies the IP Address of the web site for which credentials are being created. -r (Optional) Specifies the name of the Root CA user (the user name you have used to run the script). If -r is omitted, setup_creds will ask for the user name of the Root CA user on this system. For example, # /usr/http/bin/setup_creds -r rootca \ -d /var/SSL_CERTS/121.122.123.12/ -i 121.122.123.12 5. Enter the host name only as the name of the web site. You will be asked to enter the domain name next. For example, if the web site is www.V.com, enter www. Enter host name on which you run httpd server: (Hit return to use localhost) www 6. Enter the domain name for of the web site. Enter domain name for your server (for example, eng.sun.com) V.com 7. Enter the DN attributes for the web site, without the common name (cn). Enter Distinguished Name Suffix for your server (eg: o=SUN, c=US) : o="Company V", st=California, c=US 8. Enter a new password for this web site's credentials. Each key package has a password, which should be different from the password for the Root CA's credentials. Please provide the password to encrypt your server's private key. You will need it when you install the certificates. Enter password: Reenter password: Using configuration file '/tmp/try/host_config' skilogin: Enter your own key package password: 9. The key package and certificate for the site will be generated and stored in the output directory you named. The location of the certificate is /certs/IP_Address.cert. In this example, it would be /var/SSL_CERTS/121.122.123.12/certs/121.122.123.12.cert. You will need the certificate if you reinstall this certificate over another one. 10. Repeat Steps 1 through 9 to generate credentials for additional web sites. You now have a "self-signed" certificate. You can use this for SSL encryption if the connecting browser has your Root CA in its list of trusted CAs. This is useful within your organization where you can update browsers that need to use SSL (for example, if you protect the Sun WebServer Administration Console with SSL). Most clients on the Internet, however, will not know about your Root CA so you will want certificates signed by a third party for public SSL sites. Refer to "Requesting Signed Certificates" below after you have installed the credentials on the Sun WebServer machine. Continue with the procedures in "Enabling SSL on a Web Site." __________________________________ V. Enabling SSL on a Web Site Enabling SSL on a web site requires three procedures: ensuring that the SSL packages are installed, installing the credentials on the machine where Sun WebServer is running, and configuring SSL on a port that the web site can use. ___________________________________ To Install Site Credentials on a Sun WebServer Machine 1. The directories where the site's credentials are stored need to be copied to the Sun WebServer machine. If the Root CA machine and the Sun WebServer machine are the same, skip this step. You can move the directory to a floppy disk or other portable medium, or you can share the directory with the Sun WebServer machine over NFS. In either case, copy the directory you specified for the output of setup_creds and all of its subdirectories. The directory should contain: . certs/.CERT . keypkgs/.KEYPKG where is the address used by the web site. 2. As root on the Sun WebServer machine, run ``/usr/http/bin/install_certs'' with the appropriate options. Valid options are: -c (Optional) Indicate re-installation of a local certificate. -p Specifies the path to the certificates directory. -i (Optional) Specifies the IP Address of the web site for which credentials are being created. -uid (Optional) Specifies the name of the user under which the web server process runs. You will need to specify the path to the credentials, the IP address of the web site, and the user ID (``uid'') of the Sun WebServer process. For example # /usr/http/bin/install_certs -p /floppy/cert_floppy -i \ 121.122.123.12 0 3. Enter the key package password for this web site. This is the password specified in Step 8 of "Creating Credentials" above. /usr/bin/skilogin: Enter host key package password The credentials are now stored on the Sun WebServer machine. Follow the next procedure to configure the web site to use SSL. ___________________________________ VI. Configuring a Web Site for SSL You must create port on the web site's IP address that uses SSL. The default port used for SSL connections is 443. These instructions assume you are using the Sun WebServer Administration Console. You can also configure the port by editing the configuration file for the web site's server instance (for example, /etc/http/sws_server.httpd.conf). Please refer to the man page for httpd.conf(4) if you choose to edit the configuration file. ___________________________________ To Configure A Web Site for SSL: 1. Connect to the Sun WebServer Administration Console and log in. The default URL for the administration server is http://hostname:2380/admin/admin.html 2. Find the server instance that hosts the web site in the Server List. Click on the + to expand the folder if the configuration pages are not listed. 3. If you do not know the IP address of the web site, choose the Web Sites page. The IP address(es) used by the web site are shown in the list. NOTE | The IP Address must not be used by multiple web sites. | The SSL certificate is bound to a unique IP address and | host name. 4. Click the IP/Ports page to add a port to the web site's IP address. The Network Connections list will display on the right, showing all of the IP addresses and ports used by this server instance. 5. Click on Add to create a Network Connection using the web site's IP address and port 443. The Network Connection Dialog opens. 6. Fill in the IP Address and Port fields with the web site's IP address and the port on which you want SSL active (usually 443). Set the Timeout and whether you want to Allow HTTP 1.0 Keepalive. If you are unsure about Timeout and Allow HTTP 1.0 Keepalive, click on Help in the dialog. For adequate performance, set the Timeout to 300 seconds and allow HTTP 1.0 Keepalive. 7. Click the Enable SSL box. 8. If you want to accept connections only from clients that have valid personal certificates, click the Require Client Certificate box. For more information on this field click on Help in the dialog. 9. Set the cipher suites you want to enable. The server will negotiate with the client to use a common cipher suite. If the client and server have more than one suite in common, the strongest suite will be used. If you have the US/Canada encryption software, you may choose 128-bit, 40-bit, or both. Select both, unless you explicitly want to require a certain set from clients. If you have global encryption software, you can only use the 40-bit cipher suite. Click the 40-bit box. 10. Click on OK to save your changes, then choose Server->Save IP/Ports. 11. If you are configuring SSL on the default site for the server instance, skip the remaining steps. The default site on a server listens to all connection endpoints defined for that server, so there is no need to add the new SSL connection to the web site. 12. From the Server List, choose the Web Site page and select the web site in the list. Choose Server->Edit Web Site. In the Edit Web Site dialog, find the SSL enabled network connection in the Connections list and choose it. The connections are listed as IP_Address:Port combinations. 13. Click on > to move the connection in the Site Connections list. NOTE | This option is disabled for default sites because default | sites automatically listen in on all connection endpoints | for the server. If you are configuring the default site for | the server instance, skip steps 12 through 15. 14. Click on Save to confirm the web site changes. 15. Select Server->Save to save your changes. Continue with the next configuration procedure, "Requesting Signed Certificates." ___________________________________ VII. Requesting Signed Certificates Having a web site's certificate signed by an independent CA is the equivalent of having an independent auditor vouch for the site's identity. Clients may not believe that a secure site is what it claims to be unless its credentials are "digitally signed" by a CA that the client trusts. Sun WebServer currently only supports VeriSign as a third party CA. You can use the tools that come with Sun WebServer to send a certificate and a certificate signing request (CSR) to VeriSign via their public web site. ___________________________________ To Request a Signed Web Site Certificate 1. Your local Root CA must generate credentials and store them on the Sun WebServer machine. Refer to "Creating Credentials" and "Enabling SSL on a Web Site." 2. Log in to the Sun WebServer machine as super-user (root). 3. Run the ``send_request'' utility to generate a certificate that can be sent to a CA. On the command line, you must specify the IP address of the site whose certificate you want signed. The portable certificate will be stored in a file in /tmp, unless you use -o to specify a different directory (the directory must already exist). # mkdir /var/SSL_CERTS/requests # /usr/http/bin/send_request -o /var/SSL_CERTS/requests \ 121.122.123.12 4. Enter the key package password for the web site. This is not the Root CA's key package password. This is the password you created when you ran ``setup_creds''. 5. The certificate signing request will be stored in the directory you named or /tmp, in a file named ``cert.request''. The contents of this file can be sent to VeriSign through their web site. 6. You will need to follow the CA's procedures for requesting a signed certificate. At some point, you will need to supply the generated certificate file to the CA. To request a VeriSign certificate, visit http://www.verisign.com/idcenter/new/. You will need to request a server certificate for server software from Sun Microsystems. 7. When the CA sends the signed certificate, save it in a file. For example, save the reply in /tmp/121.122.123.12.cert. CAUTION | Do not save the certificate from the CA in the directory the | Root CA uses to store credentials. 8. As root, run ``/usr/http/bin/install_external'' to make the signed certificate available for SSL. ___________________________________ VIII. Enabling Client Authentication You can use SSL as a method for authenticating client connections if clients have digital IDs. Currently Sun WebServer supports personal digital IDs from VeriSign. VeriSign offers three levels of personal digital ID, based on the strength of the key and the insurance protection: . Class1 . Class2 . Class3 You can configure an SSL web site to require client authentication and define which level(s) of personal IDs to accept. ___________________________________ To require client authentication for SSL 1. Log in to the Sun WebServer Administration Console and go to the IP/Ports list for the server where the SSL-enabled web site is hosted. 2. Select the SSL-enabled connection used by this web site, and click Edit. The Edit Network Connections dialog opens. 3. In the dialog box, click on the "Require Client Certificate" box, then click OK. 4. Choose Selected->Save IP/Ports to save the configuration. 5. Return to the command line and become superuser. 6. Run ``setup_client_auth'' to configure the acceptable signers for client certificates on the web site. The syntax for the command is: setup_client_auth -e | -d -i The -e flag enables, and the -d flag disables, access to clients with certificates signed by the . The is the IP address of the SSL enabled web site. can be one of the VeriSign classes: Class1, Class2, or Class3. Run ``setup_client_auth'' multiple times to enable or disable multiple signers. The enabled CAs are added to the web site's trusted key list.