Administrator's Guide

CHAPTER 9

Setting Up Security

This chapter describes how to configure security for a Novell exteNd Application Server. It contains sections on:

• Security configuration

• About authentication

• Establishing a secure connection to the server

• Accessing security provider systems

• Using security provider login formats

• Using certificates

• Enabling authentication

• Using Cryptographic Hardware Integration

• Managing trusted clients

• Configuring FIPS-compliant mode

    For information about setting up Silver Security users and groups, see Setting Up Users and Groups.

Security configuration

In the application server's three-tiered architecture, security is set up at the server tier:

The application server acts as a single user with multiple connections to a database (to which applications are deployed) or a connection pool (from which data is retrieved). Acting in this manner, the application server adds extra user and object security for the data source. In effect, the application server is treated as a user with access privileges. Native data source activity and security measures are not compromised.

The application server supports HTTP, HTTP using the SSL 3.0 protocol or the TLS 1.0 Transport Layer Security protocol (HTTPS). HTTPS provides data encryption between clients and the application server to ensure privacy and data integrity.

EJBs running on the application server use the IIOP over SSL protocol to ensure privacy and data integrity. The IIOP over SSL support is provided by the ORB. The application server supports only RSA authentication for EJBs.

    For more information on the ORB's IIOP over SSL support, see the Novell exteNd Messaging Platform help.

About SSL   SSL 3.0 (developed by Netscape) provides security and privacy over the Internet. TLS 1.0 (Transport Layer Security protocol) based on SSL 3.0 (defined by Internet Engineering Task Force (IEFT)) will eventually supersede SSL 3.0. HTTPS provides data encryption between clients and servers to ensure privacy and data integrity. The SSL protocol is application-independent, allowing protocols like HTTP and FTP to be layered on top of it. The SSL protocol is able to negotiate encryption keys as well as authenticate the server before data is exchanged by the higher-level application. The SSL protocol maintains the security and integrity of the transmission channel by using encryption, authentication, and message authentication codes.

You may choose to require SSL to access your application. Because SSL affects performance, you may decide to use SSL only for specific data-sensitive portions of your site. Or you could consider using Cryptographic Hardware Integration (CHI), which enables significant application server SSL encryption/decryption performance enhancements. For information on installing and using CHI on your application server, see Using Cryptographic Hardware Integration.

About HTTPS   With HTTPS, you get a communications channel that provides privacy, user authentication, and message integrity. The application server implements SSL and TLS as follows:

• The application server must have an authentication certificate (also called public-key certificate, digital ID, or digital certificate) to make an SSL or TLS connection. The certificate is a digital "ID card" that cannot be forged. This certificate describes the server and includes a chain of trust.

• Both client and server encrypt what they send using information from both their own certificate and the certificate at the other end (if the client has a certificate). This means the sender can be sure that only the intended recipient can decrypt the data, and the recipient can be sure that the data came from the place it claims to have come from and that no tampering has occurred.

Mapping J2EE roles to existing users   You can map roles defined in a J2EE archive's deployment plan to users and groups available to the application server (Silver Security users, or users and groups from an external security system). For information on how this works, see Accessing security provider systems.

Types of encryption used for authentication

Authentication begins and ends with the client session. Both the RSA (Rivest-Shamir-Adleman) and DSA (Diffie-Hellman) encryption algorithms are based on public and private keys. The SSL and TLS protocols require the server to have an X.509 certificate containing its identity, its public key, and the identity and signature of the Certificate Authority (CA) that issued the certificate. The client authenticates the server based on the certificate it receives. The client then encrypts the public key and sends it back to the server to be used for encrypting further data transmissions. The encryption algorithms usually used are RC4, DES, and 3DES.

The client session operates in one of three modes:

Security functions

The application server security system provides four major security functions:

The application server security system handles all data integrity and data privacy functions with virtually no administrator involvement.

The remainder of this chapter describes how to implement authentication in the application server environment.

About authentication

Authentication is the process of determining user identity. Some applications identify users through a challenge, such as requesting a user ID/password pair, or through an authentication certificate. When an Anonymous user tries to access an object on your site, you can require a login or return an error. If you require a login, you can do so at either the server level or the object level. Use the SMC to configure specific objects to require a login for access. Alternatively, use the Require user authentication setting at the server level to force users to log in when they first connect to the server.

    For more information, see Enabling authentication.

Establishing a secure connection to the server

If you intend to use SSL or TLS communications, you need to:

• Obtain a server certificate and install it on the server

• Enable the RSA and/or DSA ports

• Disable HTTP (if you want to require only SSL)

• Enable TLS 1.0 and/or SSL 3.0

When doing administrative tasks such as adding users and databases to the server, you may want a secure (SSL) connection between the server and the client you are using (such as the SMC or a browser) so that all communication is encrypted.

The following three sections describe:

• Establishing a secure (SSL) connection between a Java client and the application server

• Establishing a secure (SSL) connection between an HTML client and the application server

• Establishing a secure (SSL) connection between an EJB client and the application server

Establishing a secure (SSL) connection between a Java client and the application server

Secure communications between the application server and Java clients can use either the RSA or the DSA protocol.

Because you can configure unique ports for each protocol, the port you specify depends on whether it is intended to be a runtime port for users or an administration port.

    For more information, see Setting up separate ports.

To establish a secure (SSL) connection between a Java client and the application server:

1. Install an RSA or DSA certificate on the application server.

       For information, see Using certificates.

2. Enable the RSA or DSA port(s) in the SMC.

       For information, see Enabling RSA/DSA ports.

3. Connect your client to the server using HTTPS at the DSA or RSA port.

4. In the dialog that displays, specify your server followed by the number of the runtime or administration port you want to use.

   • For an RSA port, specify https://server:RSA_port.

     For example:

       https://tara:port
     

   • For a DSA port, specify https://server:DSA_port on the command line for the hostname.

     For example:

       https://tara:443
     

NOTE:   If you want to use the RSA port default, you need only specify https://hostname on the command line. If you want an RSA connection on a port number other than 443, you must specify the port value on the command line.

Establishing a secure (SSL) connection between an HTML client and the application server

Secure communications between the application server and an HTML client (browser) use the RSA protocol.

To establish a secure (SSL) connection between an HTML client and the application server:

1. Install an RSA certificate on the application server.

       For information, see Using certificates.

2. Enable the RSA port in the SMC.

       For information, see Enabling RSA/DSA ports.

3. Open your browser to the server using HTTPS at the RSA port.

   The RSA port you specify depends on what type of operations you want to perform.

   • To run the application, specify the runtime port.

   • If you use a custom HTML administration tool, specify the administration port.

   Specify your server followed by the (optional) number of the RSA runtime or administration port:

     https://server[:port]
   

   For example:

     https://tara:443
   

NOTE:   If you want to use the RSA port default, you need only specify https://hostname on the command line. If you want an RSA connection on a port number other than the 443, you must specify the port value on the command line.

Establishing a secure (SSL) connection between an EJB client and the application server

Secure communication between the application server and EJB clients is established using the IIOP over SSL capabilities of the ORB. At startup, the application server exports the RSA certificate to the ORB. When the deployment plan of an EJB specifies a cipher suite and the application server has an RSA certificate installed, the ORB ensures that the communication is secure.

Java clients require access to the agrootca.jar file in order to participate in secure communications. This file is installed in the \Common\lib directory. This file is installed automatically for SilverJ2EEClient clients.

Communications failures   Communications failures may happen when:

• The server does not have an RSA certificate installed

• SilverJ2EEClient does not have the matching CA certificate of the server's certificate

• SilverJ2EEClient does not have the agrootca.jar file installed

    For information on specifying cipher suites for deployed EJBs, see the chapter on J2EE archive deployment in the Facilities Guide.

To establish a secure (SSL) connection between an EJB client and the application server:

1. Install an RSA certificate on the application server.

       For information, see Using certificates.

2. Enable the RSA runtime port in the SMC.

       For information, see Enabling RSA/DSA ports.

3. For HTML or Java clients, connect your browser to the server using HTTPS at the RSA runtime port:

     https://server:RSA_port_rt
   

   For example:

     https://tara:443
   

   OR

     https://tara
   

NOTE:   If your RSA runtime port uses port 443 (the default), you need only specify https://hostname on the command line. If you want an RSA connection on a port number other than 443, you must specify the port value.

For EJB applications that contain stateful session beans for which session-level failover is specified, you must also create a range of ports for IIOP SSL communications.

    For more information on creating the IIOP SSL port range, see Specifying ORB settings.

Accessing security provider systems

The system verifies users and their permission levels according to lists of groups and users that you provide. User and group information can be defined using the application server's native security system called Silver Security, or it can be obtained from an external security system. All Silver Security information is stored in the SilverMaster database. For external security, all information is obtained from the external system.

The application server recognizes users and groups from the following systems:

The application server implements the Java Naming and Directory Interface (JNDI), which connects it to native UNIX security and to Windows NT and LDAP directories:

Adding security provider access

You can use the SMC to set up access to security provider systems. After you set up access to provider directories, you can define access control for the users and groups from these external systems.

If you want to change from using Silver Security to a new security provider, make sure your administrator account has access permissions to the new security provider account.

CAUTION:    If you disable Silver Security before you grant the administrator account access to the new security provider, you will need to run SilverMasterInit -l to regain access to the application server.

    For information about setting up Silver Security users and groups, see Setting Up Users and Groups. For information about access control, see Authorization and access control.

To add security provider access:

1. Start the SMC.

2. Select the Security icon on the toolbar.

3. Select Security Providers:

   

   Any LDAP and NIS+ servers that are known to the application server are listed.

4. Select the type of provider you want to register (all providers are selected by default).

   • NT is valid only when running Windows NT. If you choose NT, it is not necessary to add an NT domain; NT provides system calls that the application server uses to discover the primary and trusted domains. But you do need to set up the server so that users can log in with their NT names. See Using NT security.

   • NIS+ is valid only when you are running Solaris.

5. To add an LDAP or NIS+ server connection, choose the appropriate item and click Add.

       For more information on adding the LDAP security provider, see Using LDAP security.

       For more information on adding the NIS+ security provider, see Using NIS+ security.

Resetting the security resource timeout

The SMC also allows you to set the security resource timeout period,which defines how often the application server reloads the list of available users and groups from defined security providers. The default value is 15 minutes.

You may want to increase this number if the information in the external system does not change frequently or if the connection to it is slow.

To reset security resource timeout:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select General:

   

4. Edit the Security resource timeout value as needed.

Using NT security

You can use various NT directory services to manage NT users and groups. For example, users logging in with their NT user name and password only have to do this once per session (unless you set additional security at the server or cluster level).

Local and global groups

Using NT users and groups can help simplify security administration. For example, defining local groups lets you combine users and global groups from multiple domains into a single group.

A local group is available only within the domain in which it is created. A global group is available within its own domain as well as any trusted domain.

Local groups defined on the server machine can include local users as well as global groups and users from the primary domain or any trusted domain. An NT local group cannot, however, contain other local groups.

    For more information on NT user groups, see your Windows NT documentation.

Speeding NT authentication   Supporting local groups can result in slower NT authentication if you have many large trusted domains. If this is a problem for you, you can speed authentication by disabling local group support — in either of two ways:

• Adding the following line to the httpd.props file (located in the application server's \Resources directory):

    http-server.com.sssw.srv.SupportNTLocalGroups=false 
  

• Programmatically setting the property PROP_SUPPORT_NT_LOCAL_GROUPS (in AgiAdmServer and AgiAdmCluster) to Boolean.FALSE

NT privileges needed when running the server as a service

To support NT users and groups, the application server requires the Act as Part of the Operating System and Log on as a Service operating system privileges. These privileges are set when the application server is configured as a service running under the default NT System account. However, if you change the service to run under a user account or if you decide to stop running the server as a service, you must make sure that these two NT system privileges are set.

If you change the service to run under a user account, the NT Control Panel automatically grants the Log on as a Service privilege to that account; however, you will need to manually configure the Act as Part of the Operating System privilege. To allow users from trusted domains to log in, you must configure the Log on Locally privilege regardless of whether or not the application server is running as a service.

    For more information on setting up Windows security, see your Windows documentation.

Using LDAP security

Lightweight Directory Access Protocol (LDAP) is a directory service that allows Internet clients to query and manage an arbitrary database of hierarchical attribute/value pairs over a TCP/IP connection. LDAP provides a specification that allows applications to communicate with it. The application server allows you to specify LDAP users and groups, display LDAP attributes, and use LDAP users and groups in access control expressions. The application server supports access to LDAP servers (such as Novell eDirectory^TM, Microsoft Active Directory and Sun One Directory Server) that support both Version 2 and Version 3 of the LDAP protocol.

Access to LDAP information

The application server interacts with an LDAP server as follows:

Connecting to LDAP servers using SSL

To prevent information about LDAP groups and users (including client credentials) from being transferred as clear text, use an SSL or TLS connection between the application server and the LDAP server.

To use SSL or TLS communications with the application server, you must already have configured your LDAP server to support SSL or TLS and have installed certificates on the LDAP server.

    For more information, see your LDAP server documentation.

NOTE:   When using SSL or TLS communications with LDAP, you can set the application server certificate to be sent to the LDAP server if it's requested. When the LDAP server is set to request or require certificates, it will attempt to verify any certificates sent to it.

Connecting to LDAP servers that support only LDAP Version 2

You can set the application server connection to use only the LDAP Version 2 protocol. By default, the application server first tries to connect to the LDAP server using LDAP Version 3. If the connection attempt fails, the LDAP server is supposed to report an error, in which case the application server will try to connect using the Version 2 protocol.

If LDAP Version 3 is not supported   This approach will not work with an LDAP server (such as Microsoft Site Server) that doesn't always report the error using LDAP Version 3. If LDAP Version 3 is not supported, you need to set the Force LDAP Version 2 option in the SMC in Step 6 in the setup procedure.

To set up LDAP security:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Security Providers.

4. Select LDAP in the provider list, then click Add.

   A wizard displays.

5. Select LDAP and click Next.

   The following panel displays:

   

6. Specify the server and (optionally) the login attribute and user name/password as follows.

   Field	What you specify
   Server	The name of the LDAP server. The server name must be recognized on your network. If the LDAP server uses a nondefault port, you must specify it as part of the server name. For example: localhost:636
   Use SSL	Use this option if the specified LDAP server and port are configured to use SSL communications.     For more information, see Connecting to LDAP servers using SSL.
   Send Certificate to Server	This option allows the application server's certificate to be sent to the LDAP server. When the LDAP server is set to request or require certificates, it will attempt to verify any certificates sent to it. If the LDAP server is set to request or require certificates (and this option is enabled), the application server's certificate is sent to the LDAP server so that it can verify it against a list of trusted CA certificates. If the LDAP server is set to request or require a certificate (and the application server does not have one), the application server will ignore the Send Certificate to Server command for certificate requests—and if the LDAP server requires a certificate, the connection will fail. You can select the Send Certificate to Server check box onlyif you have also selected Use SSL (above).
   Force LDAP Version 2	Set this option to work with an LDAP server (such as Microsoft Site Server) that does not support LDAP Version 3.     For more information, see If LDAP Version 3 is not supported.
   User Login Attribute	(Optional) If you specify a value for this property, it defines the LDAP attribute that can be used to uniquely identify a user. Make sure you pick an attribute that is unique for all users. TIP:   Specifying a value here can simplify login for LDAP users. For more information, see Simplifying login for LDAP users.
   User Name and Password	If appropriate, enter a user name and password to allow the application server access to LDAP information. The application server will use these system login credentials anytime it needs to access generic LDAP server information. If your LDAP server allows anonymous access, these account values are not required.     For more information, see Access to LDAP information.

7. Click Next.

   The following panel displays:

   

   Use this panel to specify groups on the LDAP server:

   Item	Description
   Group Location	(Required) A distinguished name that identifies the level in the hierarchy where you want to start searching for group entries. For example, to start at an organizational unit called employees that exists under the organization called myco, enter the following: ou=employees,o=myco Every group under and including employees in the hierarchy will be included.     For more information about distinguished names, see Simplifying login for LDAP users.
   Group Filter	(Required) The LDAP search filter is used to determine what constitutes a group for this LDAP server. A common usage is to specify a value of the object class attribute that identifies a group. The filter definition can be any valid LDAP search filter. For example: (objectclass=groupofuniquenames)
   Attribute of Group	Required for LDAP servers (like Netscape Directory Server) that use an attribute of a group object to define group membership.
   Attribute of User	Required for LDAP servers (like Microsoft Site Server) that use an attribute of a user object to define group membership. NOTE:   Microsoft's Active Directory supports both Attribute of Group and Attribute of User to define group membership. Specifying Attribute of User and a User/Group Attribute of memberOf is the most efficient setting.
   Group/Users Attribute	(Required) An attribute used to display all members (users) of a group in the SMC. The name you enter is the LDAP group or user attribute that defines group membership. For example: uniquemember
   Group Description Attribute	(Optional) An attribute used to identify a group description in the SMC. The name you enter is the LDAP attribute to which you want to map the description. For example: notes
   Group Additional Attributes	Select All if you want all of the specified LDAP group attributes to be listed in the SMC. Select None if you want no additional attributes to appear. The specified attributes will be displayed in a tab when you select a group in the Users & Groups panel and open the Property Inspector.     For more information, see Accessing users and groups.

8. Click Next when you have finished specifying groups.

   This panel asks you to specify users on the LDAP server:

   

9. Specify users as follows:

   Item	Description
   User Location	(Required) A distinguished name that identifies the point in the hierarchy where you want to start searching for users. For example, to start at a point (or node) entitled developers that exists under software, enter the following: ou=developers,o=software Every user under and including developers in the hierarchy will be included.
   User Filter	(Required) The LDAP search filter is used to determine what constitutes a user for this LDAP server. A common usage is to specify a value of the object class attribute that identifies a user. The filter definition can be any valid LDAP search filter. For example: (objectclass=person)
   User Description Attribute	(Optional) An attribute used to identify a user description in the SMC. The name you enter is the LDAP attribute to which you want to map the description. For example: title
   Full Name	(Optional) Specifies the full name attribute, if available. For example: cn
   Additional Attributes	Select All if you want all of the specified LDAP user attributes to be listed in the SMC. Select None if you want no additional attributes to appear. The specified attributes will be displayed in a tab when you select a user in the Users & Groups panel and open the Property Inspector.     For more information, see Accessing users and groups.

10. Click Finish.

    The SMC displays the settings under the LDAP directory. You can view the new settings anytime by selecting Users & Groups in the Security options in the SMC.

Using NIS+ security

NIS+ (Network Information Services Plus) is a name service available on SunOS 5.x and higher operating systems. Users are contained in the NIS+ table identified by passwd.org_dir, and groups by group.org_dir. After you have added users and groups, you can use them in security expressions for access control.

To set up NIS+ security:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Security Providers.

4. Select NIS+ from the provider list, then click Add.

   A wizard displays.

5. Select NIS+ and click Next.

6. Type the name of the NIS+ server in the following format:

     servername/nisDomain.com\username
   

   The server name must be recognized on your network.

Accessing users and groups

You can use the SMC to view users and groups that you have defined for any security provider.

To view users and groups:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Users & Groups.

4. Highlight an icon to view the users and groups known to the server:

   

   You can expand a selected item to show specific users and groups.

Using security provider login formats

The application server supports a number of security realms including Silver Security, NT security, LDAP security, NIS+ security, and certificate security. All except certificate security involve establishing an identity by providing user name information and a password.

When users log in they see a dialog similar to this:

If the authentication dialog is being presented by a browser, the dialog—defined by the browser—will look a little different from the dialog shown above but will consist of the same fields.

Colons cannot be used in user names or passwords

User authentication in HTTP works by taking the user name and password separated by a colon ( : ). So make sure that user names and passwords don't contain colons. With LDAP distinguished names in particular (they can be quite long), make sure no component of the name contains a colon.

User name parts

A user name is composed of three parts delimited by backslash characters: Realm\Authority\Name.

User name shortcut formats    By default, the application server allows shortcuts to the full user login name, as follows:

• Silver Security    If the user enters one part for a user name, a Silver Security user name is assumed. For example:

  emilyh is translated to SSSW\\emilyh

  NOTE:   For Silver Security, the authority is an empty string—nothing between the two backslashes. The authority is not needed, because an external security system is not used.

• Windows NT    If the user enters two parts to a user name, an NT user name is assumed, with the format domain\userName. For example:

  mydomain\craigh is translated to NT\mydomain\craigh

By default, LDAP and NIS+ names must be fully qualified, as follows:

• LDAP    Login syntax for user name: LDAP\serverName\distinguishedName

  The user must enter the entire pathname. For example:

    LDAP\myServer\cn=Nancy Smith,ou=My Company
  

• NIS+    Login syntax for user name: NisPlus\server/nisDomain\username

  The user must enter the entire pathname. Note that the authority has two components, separated by a forward slash. For example:

    NisPlus\myServer/domain1.com\jeanw
  

You can change these default login specifications, as described next.

Overriding defaults for login name components

You can override the defaults for login name components. So if you use only one type of external security system (and perhaps only one external security authority), you can allow users to provide a shortened name, thus simplifying the login procedure.

To override the defaults for login name components:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select General.

4. Specify your default realm and (optionally) your default authority, and a display name for the realm:

   Field	Description
   Default Security Realm	Defines the security realm for any login name that does not explicitly define a realm. Possible values are Silver Security, NT, LDAP, NIS+, or No Default Specified.
   Default Security Authority	(Enabled only if a default security realm has been defined) Defines the authority for any login name that does not explicitly define an authority. The application server provides a list of valid authorities based on the selected default realm.
   Security Realm display name	A String that will be displayed as the security realm in a server login dialog. This value is also passed on the WWW-Authenticate response header sent to the client.

   A full login name can always be specified, in which case the defaults are ignored.

Example   Suppose your site uses security names from a single LDAP server. You could set the following defaults:

Users that exist in the LDAP server can now just use their LDAP user name and password when logging in to the application server.

In this same example, a user that exists as part of the Silver Security security realm must now specify a full login name:

  SSSW\\SilverName

Simplifying login for LDAP users

In LDAP, a user name is specified relative to the LDAP naming hierarchy as a distinguished name (DN). The DN is a comma-separated list of nodes that contain attribute/name pairs from the leaf node where the user resides back to the root node.

By default, LDAP users logging in to the application server are required to enter the entire DN, which can be quite long. You can simplify login for LDAP users by specifying the User Login Attribute property when adding an LDAP server as a security provider. For more information on this property, see Using LDAP security.

If you have specified a User Login Attribute, when the user credentials are being verified during the login sequence, a search is performed for the specified User Login Attribute, with a value that matches the Name portion of the login user name. The search starts from a point in the LDAP hierarchy identified as User Location when defining the LDAP server to the application server (see Using LDAP security).

If the search is successful, the DN of the corresponding user (the first one found if there are multiple hits) is used to construct a fully qualified login name, and the login operation continues. If the search is not successful, the operation continues as though the Name field were the distinguished name of the LDAP user. This allows LDAP logins using either form when the attribute is set.

Example 1   Assume the following server properties are specified:

In this example, a default security realm is defined and the login attribute is set to mail. At this site, each user's mail attribute is that user's full e-mail address.

A user defined in an LDAP server named myServer, with a DN of uid=ecraig,ou=Development,ou=Billerica,o=My Company,c=US and an e-mail address of ecraig@mycompany.com (that is, a user whose mail attribute is ecraig@mycompany.com), could use a login name of either:

  myServer\uid=ecraig,ou=Development,ou=Billerica,o=My Company,c=US 

OR

  myServer\ecraig@mycompany.com

Example 2   Assume the following server properties are specified:

In this example, a default security authority has now been specified in addition to the default security realm. The login attribute has now been set to uid.

The same user as above (whose uid is ecraig) could use a login name of either:

  uid=ecraig,ou=Development,ou=Billerica,o=My Company,c=US

OR

  ecraig

Using certificates

Certificates are required when using HTTP with the SSL 3.0 and TLS 1.0 protocols (HTTPS). HTTPS provides data encryption between clients and the server to ensure privacy and data integrity. Certificates can also be used to authenticate users.

This section contains the following topics:

• About certificates

• Creating and installing server certificates using the SMC

• Creating and installing server certificates for the dispatcher

• Viewing server certificates

• Enabling RSA/DSA ports

• Turning off HTTP communications

• Allowing SSL 3.0 and TLS 1.0

• Restricting SSL cipher suites

• Managing Certificate Authorities

• Installing and managing client certificates

• Verifying SSL server certificates for Java clients

About certificates

A certificate (also called a public-key certificate, digital ID, or digital certificate) is a file that authenticates the identity of a user or a group. The certificate is a kind of license issued by a trusted organization called a Certificate Authority (CA). A CA may be an external company that offers certificate services (such as VeriSign) or an internal organization such as a corporate MIS department.

For Internet applications, it is generally a good idea to have a server certificate that is signed by a widely recognized and trusted guarantor. For intranet applications, it may be sufficient to have the guarantor be the company in which the application is running.

Both users and servers can have certificates attesting to their identity. If you want to use SSL or TLS for privacy, the application server must have a server certificate. Once it is enabled, the server may request a client certificate from the browser attesting to the identity of the user.

Advantages of certificates

Certificates provide these important security services:

Certificate support

The following table describes how the application server supports certificates:

About global certificates

What are commonly called global certificates are actually Global Secure Site IDs from VeriSign. They are a form of digital ID that allows for 128-bit encryption worldwide. (Standard VeriSign digital IDs, now called Secure Site IDs, do not allow for U.S.-based companies to use 128-bit encryption outside the U.S.)

It is up to VeriSign to certify servers as supporting Global Secure Site IDs. It is not up to a server vendor—such as Novell—to declare support for Global Secure Site IDs.

    For more information, see http://digitalid.verisign.com/server/global/help/globalFAQ.htm.

Creating and installing server certificates using the SMC

You can use the SMC for these tasks:

• Generating and installing RSA server certificates

• Generating and installing DSA server certificates

Generating and installing RSA server certificates

The SMC provides the following functions for RSA server certificates:

NOTE:   To generate a certificate for a dispatcher, you must use the command-line tool described in Creating and installing server certificates for the dispatcher.

To generate an RSA server CSR:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the RSA tab.

5. Choose Generate Request.

6. Complete the items on the panel that displays as follows:

   Field	What to specify
   Server DNS Name	The TCP/IP hostname, which may be different from your machine name. (You can issue ping localhost from the command line to determine the TCP/IP name of the local host.)
   Organization	Your company name in full unabbreviated legal form.
   Organizational Unit	(Optional) Your department within the company.
   City/Locale	(Optional) The city or locale where your company does business.
   State/Region	The full name of the state or region where your company does business. Do not abbreviate.
   Country	The country where your company does business. You must use the ISO two-letter country code. For example, the ISO code for the United States is US.

7. Click Next.

   This panel allows you to specify the size of the key pair to generate.

   The 1024 bits option usually provides an acceptable level of security. Selecting a higher level decreases the speed of the initial connection. The 512 bits option provides a low level of security.

   

8. If prompted, specify the size of the key pair to generate.

9. Click Next.

   The following panel displays:

   

   This panel shows the paths for the CSR. You may edit these paths if you choose. You will use this information later when installing the certificate.

10. Click Next:

    

11. Click Copy CSR to Clipboard to copy the contents of the CSR to the clipboard for use in the next step.

12. Follow the directions to request a certificate for your application server (for example, by using the VeriSign Web site http://digitalid.verisign.com). Once your request is approved, the certificate authority sends the new certificate back to you through e-mail.

13. Click Finish.

To back up the private key:

After you have generated a CSR, you may want to back up the private key information in case the SilverMaster database gets corrupted before you get the CSR back from the certificate issuer. If you've saved the private key, you'll still be able to install the certificate.

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the RSA tab.

5. Choose Export Private Key. A message box displays advising you to use HTTPS.

   The following panel displays:

   

6. Supply the path and file name where you want to store the RSA private key.

7. Supply a password for this file. This does not have to be the administrator's password—it just applies to the file containing the private key information.

8. Click Finish.

To install a certificate (with or without a private key):

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the RSA tab.

5. Choose Install Certificate or Install with Private Key.

   If you chose Install with Private Key, a message box displays and you are advised to use HTTPS for this procedure.

   The following panel displays:

   

6. Paste the signed certificate into the text area and click Finish.

   If you chose Install with Private Key, you are prompted for the file containing the private key and the password associated with the file:

   1. Browse to the files location.

   2. Enter the password and click Finish.

   The SMC displays a message that the update was successful.

7. Click OK.

8. Choose Restart to have the changes take effect.

To back up an RSA certificate:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the RSA tab.

5. Choose Export Certificate. You are advised to run in HTTPS mode.

6. Specify the name and location of the backup file.

7. Specify a password to protect the file.

8. Click Finish.

To import (install) an RSA certificate:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the RSA tab.

5. Choose Import Certificate. You are advised to run in HTTPS mode.

   The following panel displays:

   

6. Specify the name and location of the certificate file.

7. Specify the password used to protect the file. (This is the same password used to export the certificate.)

8. Click Finish.

Generating and installing DSA server certificates

You can use the SMC to generate and install a DSA server certificate.

To generate and install a DSA server certificate:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the DSA tab.

5. Choose Add Certificate.

   The following panel displays:

   

6. Complete the items on this panel as described below:

   Field	What to enter
   Server DNS Name	The TCP/IP hostname, which may be different from your machine name. (You can issue ping localhost from the command line to determine the TCP/IP name of the local host.)
   Organization	Your company name in full unabbreviated legal form.
   Organizational Unit	(Optional) Your department within the company.
   City/Locale	(Optional) The city or locale where your company does business.
   State/Region	The full name of the state or region where your company does business. (Do not abbreviate.)
   Country	The country where your company does business. You must use the ISO two-letter country code. For example, the ISO code for the United States is US.

7. Click Next.

8. The following panel allows you to specify the size of the key pair to generate.

   The 1024 bits option usually provides an acceptable level of security. Selecting a higher level decreases the speed of the initial connection. The 512 bits option provides a low level of security.

   

9. If prompted, specify the size of the key pair to generate.

10. Click Next.

    You are warned that any existing certificate will be overwritten.

11. To continue adding the certificate, click Finish.

Creating and installing server certificates for the dispatcher

To create and install a server certificate for the application server's dispatcher (used in clustering), you must use these command-line utilities:

The following sections include instructions for:

• Using AgDigitalIDStep1

• Using AgDigitalIDStep2

Using AgDigitalIDStep1

To enable HTTPS/SSL or TLS communications between application servers and clients in a clustered environment, you install an RSA or DSA certificate on the application server's Dispatcher.

To generate an RSA or DSA server certificate:

1. Change the working directory to the server's \bin directory.

2. At the command line, specify one of the following commands:

   Certificate type	Command
   RSA certificate	AgDigitalIDStep1
   DSA certificate	AgDigitalIDStep1 dsa

   TIP:   The titles and some of the help text may differ slightly if you are generating a DSA certificate.

   The following panel displays:

   

   TIP:   In UNIX, this utility runs using a GUI and cannot be run in a character terminal window. If you log in remotely to the UNIX machine, make sure you set your DISPLAY environment variable appropriately.

3. Complete the items on this panel as follows:

   Field	What to specify
   Server DNS Name	The TCP/IP hostname, which may be different from your machine name. (You can issue ping localhost from the command line to determine the TCP/IP name of the local host.)
   Organization	Your company name in full unabbreviated legal form.
   Organizational Unit	(Optional) Your department within the company.
   City/Locale	(Optional) The city or locale where your company does business.
   State/Region	The full name of the state or region where your company does business. Do not abbreviate.
   Country	The country where your company does business. You must use the ISO two-letter country code. For example, the ISO code for the United States is US.

4. Click Next.

   The following panel displays for you to specify the size of the key pair to generate.

   The 1024 bits option usually provides an acceptable level of security. Selecting a higher level decreases the speed of the initial connection. The 512 bits option provides a low level of security.

   

5. If prompted, specify the size of the key pair to generate.

6. Click Next.

   1. If you are generating an RSA certificate, enter a password then confirm it. This password will be used to encrypt your private key.

      TIP:   Be sure to record this password; you will need it to install the certificate.

   2. Click Next.

7. For RSA certificates, the panel shows the paths for the CSR and the password-protected private key.

   For DSA certificates, the panel shows the paths for the certificate and the private key files. You may edit these paths if you choose. You will use this information later when installing the certificate.

   IMPORTANT:   The file that contains the private key must be kept physically secure. Otherwise, anyone who can obtain the server's certificate can masquerade as the server.

8. Click Next.

   If the wizard hasn't been able to collect enough randomness information to generate cryptographically good keys from the key presses and mouse movements you have made, the following panel displays:

   

9. If prompted, type random characters in the edit box and move the mouse around to create an encrypted private key. When the wizard has enough randomness information, the OK button is enabled.

   For RSA certificates, the wizard generates the certificate signing request and private key.

   For DSA certificates, the wizard generates the certificate.

10. Click OK.

    The following panel displays:

    

11. For RSA certificates, click Copy CSR to Clipboard to copy the contents of the CSR to the clipboard for use in the next step.

    For DSA certificates, click Copy Digital ID to Clipboard for use when installing the certificate.

12. For RSA certificates, follow the directions to request a certificate for your application server (for example, by using the VeriSign Web site http://digitalid.verisign.com). Once your request is approved, the certificate authority sends the new certificate back to you through e-mail.

13. Click Finish.

You use AgDigitalIDStep2 to install the certificate. See Using AgDigitalIDStep2 next.

Using AgDigitalIDStep2

Once you receive your RSA certificate from the CA or have generated a DSA certificate using AgDigitalIDStep1, you can install the certificate using AgDigitalIDStep2.

To install an RSA or DSA certificate:

1. Start the Dispatcher using the -c (upload certificate) option.

2. Change the working directory to your server's bin directory.

3. At the command line, specify the following command:

     AgDigitalIDStep2
   

   The following panel displays:

   

4. Paste the certificate into the panel.

5. Click Next.

6. This panel asks for the path for the private key (you may need to edit the name of the private key, since the names are different for RSA and DSA certificates) and asks you to confirm your password (there is no password for a DSA private key).

7. Click Next.

   The following panel displays:

   

8. Enter the Dispatcher's name (in the server name text field) and the Dispatcher's HTTP port number.

   If you have configured separate ports for different types of operations, specify your administration port. By default, the application server listens to port 80.

9. Click Finish.

   A confirmation message displays.

10. To activate the certificate, click the Restart (server) button on the SMC.

After the server restart, the server is configured to listen:

• For HTTP requests on the HTTP port.

• For HTTPS requests at the RSA or DSA port (depending on the kind of certificate you just installed).

    For more information, see Enabling RSA/DSA ports and Specifying general server properties.

When you are ready for production, use the SMC to enable authorization. See Enabling authentication.

Viewing server certificates

To view certificates that have been installed on the server:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the Certificate List tab.

5. Choose a certificate from the dropdown.

Enabling RSA/DSA ports

By default, the application server specifies port 443 for RSA and DSA communications. You enable and modify ports for runtime and administrative access for each of the following three security protocols: HTTP, HTTPS-RSA, and HTTPS-DSA. The server does not require you to configure unique port values for the different types of access; ports having the same value will share the same socket and will allow multiple operations.

    For more information, see Setting up separate ports.

To enable and change RSA/DSA ports:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates and choose either the DSA tab or the RSA tab.

4. In the Port Settings section of the tab, under Port Settings, select any of the check boxes to enable Runtime or Admin ports for DSA or RSA:

   • Enable RSA only after you have installed an RSA server certificate from a provider such as VeriSign.

   • Enable DSA only if you have installed a DSA certificate on the server.

   TIP:   After a server certificate has been installed, the ports are automatically enabled when the server is restarted.

       For more information, see Creating and installing server certificates for the dispatcher.

5. Change the RSA and DSA port numbers of the Runtime and/or Admin ports if necessary.

   With a UNIX server, specify port numbers above 1024 if the server is not being run with root access (ports below 1024 are reserved for root access).

       For information about cipher suites, see Restricting SSL cipher suites.

6. Select Update.

7. To activate the changes, click Restart (server).

   Once ports are enabled, Java clients will verify server certificates when establishing SSL connections to the application server.

       For more information, see Verifying SSL server certificates for Java clients.

Turning off HTTP communications

You can turn off HTTP communications and allow client communications using only HTTPS or RMI.

    For more information, see Specifying ORB settings.

If you accidentally disable ports that prevent you from running the SMC (for example, if you disable all the administration ports), you will need to edit the httpd.props file to re-enable the administration port. You can enable and disable runtime ports using the SMC.

To disable HTTP communications:

1. Start the SMC.

2. Select the Configuration icon from the toolbar.

3. Select General.

4. In the HTTP Ports section, deselect the Enable HTTP Runtime Port (or the HTTP Admin ports) check box to disable.

   The server will run even if you disable all runtime ports. You must be careful how you disable runtime ports. When you disable HTTP runtime ports, the server checks to see if you have DSA or RSA runtime ports enabled. It warns if you proceed to disable the HTTP runtime port.

5. Click Update.

6. To activate the change, click the Restart button. For more information, see Restarting the application server.

Now the server will not listen on the HTTP server port.

Allowing SSL 3.0 and TLS 1.0

The application server supports SSL (Secure Sockets Layer) 3.0 and TLS (Transport Layer Security) 1.0. TLS 1.0 protocol is based on the SSL 3.0 protocol, and is sometimes referred to as SSL 3.1.

By default, SSL 3.0 and TLS 1.0 are both allowed

To allow or disallow SSL 3.0:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select General.

4. Check the SSL 3.0 checkbox to enable SSL 3.0

   To run in FIPS-mode, TLS 1.0 must be enabled and SSL 3.0 must be disabled.

5. Click Update.

6. Restart your server.

To allow or disallow TLS 1.0:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select General.

4. Check the TLS 1.0 checkbox to enable TLS1.0

   To run in FIPS-mode, TLS 1.0 must be enabled and SSL 3.0 must be disabled.

5. Click Update.

6. Restart your server.

Restricting SSL cipher suites

When an SSL connection is initialized, the browser client and the server determine a common cipher value to be used for key exchange and encryption. Various cipher values offer different types of encryption algorithms and levels of security. The application server has a full set of cipher suites that can service a range of clients by providing low, medium, and high-level encryption.

You can restrict the levels of encryption (cipher values) used by the server when communicating in HTTPS through the RSA and DSA runtime ports. This allows you to have a server capable of high-level encryption while preventing connections from lower-level security clients.

During startup, the application server reads the list of allowed cipher suites. See Restricting SSL cipher suites for the list of cipher suites that are enabled by default. You can use the SMC to change the enabled/disabled cipher suites. Only the selected cipher suites will be used to initialize the appropriate SSL socket(s).

To specify which cipher suites are allowed:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Choose the RSA or DSA tab (depending on the type of certificate that is installed).

5. Select the Enable Runtime Port check box to enable secure DSA (Java-client) and/or RSA (HTML and Java-client) communications.

6. Specify which cipher suites are allowed by clicking Cipher Suites and selecting and deselecting the cipher suites in the resulting panels, as described in the table below. When you select a cipher suite, its description displays in the panel.

7. Click OK to exit the Cipher Suites dialog and accept your changes.

8. Click Update.

9. To activate the changes, click Restart (server).

Table of cipher suites   The following table lists the cipher suites (and levels of security) supported by the application server when using secure communications (HTTPS).

* A cipher suite that is enabled, by default, at server startup.

Managing Certificate Authorities

The application server maintains a list of Certificate Authorities (CAs) for verifying client certificates. This represents the list of guarantors the server will trust. There are three common CAs installed when the server is initially configured. These CAs are from VeriSign, Inc. and represent different levels of trust: class 1 represents a certificate that has minimal trust; class 3 represents the highest level of trust.

When a user with a client certificate tries to access the server, the server first checks the list of CAs to verify that the certificate has been approved by a known party, then checks for a valid timestamp to verify that the certificate has not expired. After completing the verification, the server handles the connection request according to the Client Certificate Level parameter (which you can set using the SMC; see Installing and managing client certificates).

The application server can also server extract the CA from an unrecognized client certificate. For more information, see Installing and managing client certificates.

To install or delete a CA certificate:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Certificates.

4. Select the Authorities tab.

   This tab contains information about each CA and allows you to add new CAs to allow a broader range of clients to be trusted or to delete CAs to tighten the level of security on the server.

5. To add a CA, click Add Certificate Authority and select the file. To delete a CA, highlight it and click Delete Certificate Authority.

Installing and managing client certificates

In the HTTPS environment, a client certificate establishes the identity of a user when communicating with a server. Client certificates can be obtained from various sources, but to be useful the certificate must be signed by a guarantor (Certificate Authority or CA) trusted by the server.

The application server supports client certificates from standard Internet browsers (including Netscape and Internet Explorer) that use RSA encryption and supports X.509 certificates (which is a particular implementation of the Certificate interface used by many certificate issuers).

Client certificates and EJBs   Client certificates that use RSA encryption are also used to establish the identity of a user in the SSL environment (used by EJBs). As with the HTTPS environment, the server supports client certificates from standard Internet browsers. If you need to add a new CA to the server, see To install or delete a CA certificate:.

Enabling and installing client certificates

You can use the SMC to determine how the server will handle connection attempts from users with valid client certificates. Seven parameter options are available, each representing a different level of restriction. Two of the options will automatically install new certificates that are verified by the server and add them to the database as new users in the Certificate Security realm. You can also install the certificates manually (see Manually installing client certificates).

Each set of HTTPS ports (HTTPS-RSA HTTPS-DSA) has a single set of cipher suites associated with it. The cipher suite you select applies to all ports (runtime and administration) of that type.

NOTE:   The SMC will not allow HTTPS ports to be enabled without a valid certificate. If you try to enable an HTTPS port (using the SMC or by editing the props file) without first installing a certificate, the server error will display on startup. See The httpd.props File.

To enable client certificates on the server:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Advanced.

   Each set of HTTPS ports (HTTPS-RSA HTTPS-DSA) has a single set of cipher suites associated with it. Although the cipher suite you select applies to all ports (runtime and administration) within a protocol type, you can set each port to a different value.

   IMPORTANT:   You cannot enable an HTTPS port without first installing an HTTPS-RSA or HTTPS-DSA server certificate. If you try to enable an HTTPS port (using the SMC or by editing the props file) without first installing a certificate, the server error will display on startup.

   

4. Select an option from the dropdown list labeled HTTPS Client certificate level, then click Update:

   

   You need to restart the server only if you changed from level 0 to another level.

   Your selection determines how the server will handle all valid client certificates. The certificate verification table (below) describes each option. The options are numbered 0 (no verification) to 6 (most restrictive level).

Certificate verification table

Certificate verification level	Description
Certificate not requested or required (0)	Turns off the use of certificates for establishing a client's identity. A client that connects via HTTPS will still benefit from secure communications and can check the identity of the server, but will not be asked to present its own certificate.
Certificate requested but not required (1)	The server will request a certificate from the client. If the client does not have a certificate or has a certificate that has not been validated by the server, a connection is allowed but the user remains anonymous. If a certificate is presented for an established user, the client takes on the identity of the certificate user.
Certificate requested, not required; auto-add if not in database (2)	The server will request a certificate from the client. If the client does not have a certificate, a connection is allowed but the user will remain anonymous. If a legitimate certificate is presented but does not yet correspond to a client validated by the server, the server will automatically add the certificate, and the client takes on the identity of the newly created Certificate Security user. If a certificate is presented for an established user, the client takes on the identity of the previously established Certificate Security user.
Certificate required; auto-add if not in database (3)	The server will request a certificate from the client. If the client does not have a certificate, the connection is denied. If a legitimate certificate is presented but does not yet correspond to a client validated by the server, the server will automatically add the certificate, and the client takes on the identity of the newly created Certificate Security user. If a certificate is presented for an established user, the client takes on the identity of the previously established Certificate Security user.
Certificate required; Anonymous if not in database (4)	The server will request a certificate from the client. If the client does not have a certificate, the connection is denied. If a legitimate certificate is presented but does not yet correspond to a client validated by the server, the client is allowed to connect but remains Anonymous. If a certificate is presented for an established user, the client takes on the identity of the previously established Certificate Security user.
Certificate required for known user (5)	The server will request a certificate from the client. If the client does not have a certificate or has a certificate that does not correspond to a client previously validated by the server, the connection is denied. If a certificate is presented for an established user, the client takes on the identity of the previously established Certificate Security user.
Certificate required for known user, but remain Anonymous (6)	The server will request a certificate from the client. If the client does not have a certificate or has a certificate that does not correspond to a client previously validated by the server, the connection is denied. If a certificate is presented for an established user, the client is allowed to connect but still remains Anonymous.

Manually installing client certificates

The previous section describes parameter options that automatically add new validated certificates to the database on the server. You may prefer to install the certificates separately. This section describes how to manually add client certificates to the database. It consists of two procedures, one for the client machine and the other for the server.

To install a client certificate—client machine:

NOTE:   For this procedure to work, the certificate validation level on the server must be set to 1, 2, or 4 (see Certificate verification table).

1. Make sure you have a valid client certificate installed on your browser.

2. Open your browser and go to the following URL:

     https://server/SilverStream/Meta/Certificates?action=data
   

   where server is the name of your server.

   The server will extract the user information from the certificate and send it back to the client.

3. Save the file that the server presents to an appropriate area.

To install a client certificate—server machine:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Users & Groups.

4. Select Certificate Security.

5. Choose the New User icon at the bottom of the right pane:

   

   The following panel displays:

   

6. Choose Certificate user:

   

7. Enter the file name obtained by the client from the previous procedure (To install a client certificate—client machine:) and click Finish.

   This adds the certificate as a new user to the database on the server.

Extracting a CA from a client certificate

The application server can extract the CA from a client certificate if the CA is not installed on the server. This section consists of two procedures, one for the client machine and the other for the server.

To extract the CA from a certificate—client machine:

NOTE:   For this procedure to work, the certificate validation level on the server must be set to 1 or 2 (see Certificate verification table).

1. Make sure you have a valid client certificate installed on your browser.

2. Open your browser and go to the following URL:

     https://server/SilverStream/Meta/Certificates?action=dataCA
   

   where server is the name of your server.

   The server will extract the CA from the certificate and send it back to the client.

3. Save the file that the server presents to an appropriate area.

To extract a CA from a client certificate—server:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select the Certificates panel.

4. Select the Authorities tab.

5. Click Add Certificate Authority.

6. Browse for the location of the extracted CA, then click Open.

   The program installs the new CA to the database.

7. To activate the new CA, restart the server by clicking the Restart (server) icon.

Accessing certificate users

Certificate users are added to a security realm called Certificate Security. This realm is included in the lists of users and groups supported by the application server.

To access certificate users:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Users & Groups.

4. Navigate to a user from the Certificate Security list:

   

5. Use this panel to view current users or add users to groups.

       For more information about users and groups, see Setting Up Users and Groups.

You can use certificate users in security expressions exactly as you use other Silver Security users. For more information about security expressions, see Authorization and access control.

Updating client certificates

An X.509 certificate includes a start date and an end date. A client is not allowed to connect to the server with a certificate that has expired. You can update the certificate representing an established Certificate Security user by obtaining a new certificate and assigning it to a user already known to the application server. This ensures that any security expressions involving the existing user will continue to work properly.

Normally, an existing certificate user would present the updated certificate to the server using the URL described in Manually installing client certificates.

NOTE:   If you are running the server with one of the autoinstall parameters described previously (level 2 or 3) and an existing client certificate holder attempts to access the server with a new (updated) certificate that the server validates, that client will be installed as a new user. This client may be restricted from resources available to the previous user.

To update an existing certificate user:

1. Select the Security icon from the toolbar.

2. Select the Users & Groups panel.

3. From the Certificate Security domain, navigate to the user you want to update.

4. Click the Properties button.

   A form with three tabs displays. The General tab shows general information concerning the user. The Additional Attributes tab displays information about the certificate. The Update tab allows you to update the certificate for the selected user.

5. Select the Update tab.

6. Enter the file name for the updated certificate, then click Update.

   This replaces the old certificate with the new version without changing the identity of the user on the server.

Verifying SSL server certificates for Java clients

Java clients verify server certificates against a list of trusted CA certificates (stored in the agrootca.jar file) when establishing an SSL connection to the application server. If a certificate cannot be verified, the SSL connection cannot be established.

To use SSL communications, you must have one of the following server certificates installed on your application server:

Using the agrootca.jar file to verify RSA certificates

Clients verify the application server's certificate against a list of trusted CA certificates that are stored in the agrootca.jar file. At startup, the client reads in the list of CAs and then checks all server certificates against the contents of the agrootca.jar file to verify that certificates are signed.

You should include all trusted root CAs in the agrootca.jar file and remove any untrusted CAs. Clients will trust only those server certificates that were signed by the root CA certificates in the JAR file.

If you generate your own RSA certificates using a tool such as Netscape Certificate Server, you should put the CA certificate of the Certificate Server into the agrootca.jar file and then distribute the JAR file to each client machine running SilverJ2EEClient. The agrootca.jar file should be stored in SilverJ2EEClient's Common\lib directory.

NOTE:   The agrootca.jar file is used by the application server only when user code tries to connect to another server using SSL (such as in the case of a servlet).

Simplified secure port configuration   You can use the application server's RSA port to provide secure communications between the server and Java clients, HTML clients, and EJBs.

Command-line option for self-signing DSA server certificates

If your organization uses self-signed DSA certificates to provide data encryption between the application server and clients, you should use the +Dsssw.ssl.nocacheck command-line option when you run SilverJ2EEClient. This option prevents the client from attempting to verify the certificate authority. For example:

  SilverJ2EEClient +Dsssw.ssl.nocacheck server database warfile

Enabling authentication

You can require user authentication and activate related settings. You set authentication settings when you are ready to deploy applications that require authentication for both HTTP user/password protection and HTTPS-RSA client certificates.

    For more information, see Setting up separate ports.

To enable user authentication:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select General:

   

4. Activate the security options as follows:

   Item	Description
   Require user authentication	Requires users when first accessing the server to authenticate themselves, either through a certificate or user name/password. Once authenticated, users do not have to be authenticated again during the session. Setting this option disallows Anonymous users; if you don't set this option, a user can access the server without logging in or sending a certificate, in which case the user is known as Anonymous. If you are using this option with HTTPS, activate Client certificate level in HTTPS. You can also require login on a per-object basis. See Changing access.
   Disable HTML directory listing	Disables the listing of server directory contents in a browser when the browser points to the directory's URL. Prevents users from seeing directory contents. If this option is turned on, the server returns a FORBIDDEN error.
   Allow users to modify own account	By default, users can change their own user properties. You can turn off this privilege by deselecting this check box. If this privilege is turned off, only administrators (users with Read Server Configuration and Modify Server Configuration permissions) can change user properties.     For more information, see Editing user properties.
   Security resource timeout	Specifies how frequently the application server will upload current lists of users and groups from the NT, LDAP, and/or NIS+ servers, which would include any updates to these lists.     For more information, see Resetting the security resource timeout.

5. For changes to take effect, click Update.

Using Cryptographic Hardware Integration

Cryptographic Hardware Integration (CHI) enables significant application server SSL encryption/decryption performance enhancements on machines with the application server and a supported hardware accelerator card.

    For information about the supported cards, see the application server Release Notes.

To use CHI, you need to:

1. Install a supported hardware accelerator card on the machine where the application server is installed

       For information about installing and setting up the card, see your hardware card's documentation.

2. Install CHI on the machine (see To install CHI: below)

3. Configure the server using the SMC (see To configure the application server to use the hardware accelerator card: below)

To install CHI:

1. Invoke chiVersionInstall.exe (the CHI installer).

2. Follow the prompts to install CHI into your application server's installation directory.

You can later uninstall CHI separately if you want.

To configure the application server to use the hardware accelerator card:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Advanced.

4. Select Use Hardware Accelerator.

5. Specify your accelerator card.

6. Specify the slot number and PIN, which you can get or set up from the utility software that came with the card.

7. Click Update.

8. Restart the server.

Managing trusted clients

You can use the SMC to set up a list of clients that are trusted by an application server when receiving an asserted identity in EJB calls. For standalone servers, this is a server-level property. For servers running in a cluster, this is a cluster-level property—any trusted clients set up on a single server are propagated to all servers in the cluster.

To add a client to the list of trusted clients:

1. Start the SMC.

2. Select the Security icon from the toolbar.

3. Select Advanced.

4. In the Trusted Clients section of the Advanced tab, choose Add.

   You are prompted for the client name.

5. Enter the client's host name.

   The entry can contain the asterisk wild card character(*)—for example:

     *.mydomain.com
   

   OR

     server*.mydomain.com
   

   OR

     *
   

   If you use the asterisk, it should be the last character in a section of the URL. Any characters following the asterisk in a section are ignored. In the example shown above, if server* were shown as server*1, the 1 would not be included in the list.

Configuring FIPS-compliant mode

This section describes how to configure the application server to run in the Federal Information Processing Standards (FIPS) mode. The application server is FIPS-ready by default. You need to follow the procedures below to FIPS-enable the application server, the dispatcher, and client connections (these includes outbound connections from the application server, SMC, or SilverJ2EEClient).

NOTE:   Silver Security is not FIPS-compliant. To be FIPS-compliant, you must use LDAP or another user registry mechanism for managing users and passwords.

To configure the application server to run in FIPS-approved mode:

1. Use the SMC to disable SSL 3.0 and enable TLS 1.0.

       For more information, see Allowing SSL 3.0 and TLS 1.0

2. Use the SMC to disable all of the cipher suites except:

   • SSL_RSA_WITH_3DES_EDE_CBC_SHA

   • SSL_RSA_WITH_DES_CBC_SHA

   • TLS_RSA_WITH_AES_256_CBC_SHA

   • TLS_RSA_WITH_AES_128_CBC_SHA

       For more information, see Restricting SSL cipher suites

To run SilverCmd, SilverJ2EEClient, and the SMC in FIPS-approved mode:

1. Disable SSL 3.0 and enable TLS1.0:

   1. Open ciphersuitesclients.props file (located in the \Common\lib).

   2. To disable SSL 3.0, make sure that the file includes the uncommented line:

        NOSSL3 
      

   3. To enable TLS, make sure the NOTLS1 command is removed from the file or commented like this:

        #NOTLS1
      

       For more information about the configuration file, seeAbout the cipher suite configuration file.

To configure the dispatcher to run in FIPS-approved mode:

• Modify Common/lib/ciphersuites.props

or

• Supply your own configuration file using the -ciphersuites command line option at startup.

      For more information about the configuration file, seeAbout the cipher suite configuration file.

Other FIPS-compliance considerations:  

• Sun's JSSE and JCE implementations are not FIPS-approved. Using them in a deployed application will cause the server to be noncompliant.

• If your application uses URL or URLConnection, you will very likely remain in compliance. The URLStreamHandlerFactory uses Phaos SSLava which is based on a Phaos Crypto module. However, if you call URL.setURLStreamHandlerFactory() to another implementation, then you will become noncompliant.

About the cipher suite configuration file

The cipher suite configuration file is a Java properties file. The legal entries are:

• NOSSL3—When present, disallows SSL 3.0

• NOTLS1—When present, disallows TLS 1.0

• NONTLM— When present, disallows NTLM authentication in Composer

• ciphersuitename=Priority#—An optional integer

The cipher suite names are sorted descending according to priority#. If no priority# is specified, the cipher suite has the lowest priority.

The application server does not support all of the alias names of cipher suites. (See Restricting SSL cipher suites for the list of supported cipher suites.) The cipher suite configuration files are located in the Common/lib folder or in a JAR file:

• For client side, the file is named ciphersuitesclient.props

• For server side, the file is named ciphersuites.props

Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved.  more ...