test

Oracle iPlanet Web Proxy Server 4.0.14 Administration Guide

Chapter 5 Using Certificates and Keys

This chapter describes the use of certificates and keys authentication to secure Proxy Server. Proxy Server incorporates the security architecture of all iPlanet servers, and is built on industry standards and public protocols for maximum interoperability and consistency.

This chapter assumes familiarity with the basic concepts of public-key cryptography, including encryption and decryption, public and private keys, digital certificates, and encryption protocols.

This chapter contains the following sections:

Securing Administration Server Access

The Administration Server which is a web-based user interface used to manage, add, remove, and migrate servers, needs to be secured.

The default Administration Server page starts in HTTP mode. The available Proxy Server instances are displayed as a list under the heading of Manage Servers. To administer any Proxy Server instance, click on the name from the list. When you click the name of a Proxy Server instance, the Server Manager page for that instance is displayed.

From the Server Manager page you can go back to the Administration Server page by clicking on the Manage Servers link at the top left corner in the Server Manager page.

The security features like certificate based authentication, creating a trust database, configuring SSL, requesting and installing certificates, setting security preferences, and so on, apply both to Administration Server and the individual Proxy Server instances. For security related configurations of Administration Server, use the Preferences tab, and the Security tab that appear on the Administration Server page. For security configurations related to Proxy Server instances, use the Preferences tab, and the Security tab that appear on the Server Manager page for that Proxy instance.

To start the Administration Server in secure mode, you need to access it using HTTPS instead of the default HTTP.

The security features are described in detail in the following sections.

Certificate-based Authentication

Authentication is the process of confirming identity. In the context of network interactions, authentication is the confident identification of one party by another. Certificates are one way of supporting authentication.

A certificate consists of digital data that specifies the name of an individual, company, or other entity, and certifies that the public key included in the certificate belongs to that entity.

Both clients and servers can have certificates. Server authentication refers to the confident identification of a server by a client. Identification of the organization assumed to be responsible for the server at a particular network address. Client authentication refers to the confident identification of a client by a server, or identification of the person assumed to be using the client software. Clients can have multiple certificates, much like a person might have several different pieces of identification.

A certificate is issued and digitally signed by a Certificate Authority, or CA. The CA can be a company that sells certificates, or a department responsible for issuing certificates for your company’s intranet or extranet. You decide which CAs you trust enough to serve as verifiers of other people’s identities.

A certificate includes the following information.

Note –

A server certificate must be installed before encryption can be activated.

Creating a Trust Database

Before requesting a server certificate you must create a trust database. In Proxy Server, the Administration Server and each server instance can have its own trust database. The trust database should only be created on your local computer.

When you create the trust database, you specify a password to be used for a key-pair file. You also need this password to start a server using encrypted communications. For a list of guidelines to consider when choosing a password, see Choosing Strong Passwords.

In the trust database you create and store the public and private keys, referred to as your key-pair file. The key-pair file is used for SSL encryption. You use the key-pair file when you request and install your server certificate. The certificate is stored in the trust database after installation.

The key-pair file is stored encrypted in the following directory.

server-root/alias/proxy-serverid-key3.db

The Administration Server can have only one trust database. Each server instance can have its own trust database.

ProcedureTo Create a Trust Database

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Create Database link.

  3. Type a password for the trust database.

  4. Type the password again and click OK.

Using password.conf

By default, the Proxy Server prompts the administrator for the key database password before starting up. To restart an unattended Proxy Server, you must save the password in a password.conf file. Do this only if your system is adequately protected, so that this file and the key databases are not compromised.

Typically, you cannot start a UNIX SSL-enabled server with the /etc/rc.local or the /etc/inittab files because the server requires a password before starting. Although you can start an SSL-enabled server automatically if you keep the password in plain text in a file, doing so is unsafe. The server’s password.conf file should be owned by root or the user who installed the server, with only the owner having read and write access to the file.

On UNIX, leaving the SSL-enabled server’s password in the password.conf file is a large security risk. Anyone who can access the file has access to the SSL-enabled server’s password. Consider the security risks before keeping the SSL-enabled server’s password in the password.conf file.

On Windows, if you have an NTFS file system, you should protect the directory that contains the password.conf file by restricting access, even if you do not use the file. The directory should have read and write permissions for the Administration Server user and the Proxy Server user. Protecting the directory prevents others from creating a false password.conf file. You cannot protect directories or files on FAT file systems by restricting access to them.

Starting an SSL-Enabled Server Automatically

ProcedureTo start an SSL-Enabled Server Automatically

  1. Make sure SSL is enabled.

  2. Create a new password.conf file in the config subdirectory of the Proxy Server instance.

    • If you are using the internal PKCS #11 software encryption module included with the Proxy Server, type the following information:internal:your-password

      • If you are using a different PKCS #11 module for hardware encryption or hardware accelerators, specify the name of the PKCS #11 module, followed by the password, for example:nFast:your-password

        You will always be prompted to supply a password when starting the Proxy Server, even after the password.conf file has been created.

Using Sun Crypto Accelerator Keystore

The Sun Crypto Accelerator 4000 card provides optimized, scalable SSL operations at speeds much greater than a system CPU can achieve.

ProcedureTo Configure Proxy Server to Use Sun Crypto Accelerator

  1. Install the Sun Crypto Accelerator 4000 board.

  2. Initialize the Sun Crypto Accelerator 4000 board.

  3. Install Proxy Server 4.0.10 (preferably as root).

  4. Create a trust database in the proxy instance.

    For more information about creating a trust database, see Creating a Trust Database.

  5. Enable the Sun Crypto Accelerator 4000 board.

ProcedureTo Enable the Sun Crypto Accelerator 4000 Board for Proxy Server

  1. Set the user and realm using the command secadm.

  2. Copy the directory “server-root/bin/proxy” to the directory “server-root/bin/https”.

    This step is required to enable the script ipsslcfg to locate the command modutil.

  3. Edit the script /opt/SUNWconn/bin/iplsslcfg and provide the path to modutil.

  4. Execute /opt/SUNWconn/bin/iplsslcfg.

  5. Select option 1. Configure Sun ONE Web Server for SSL.

    Note –

    The option 1 denotes configuration of Web Server for SSL. Select the same option 1 for Proxy Server configuration also.

  6. Specify the Proxy Server 4.0.10 installation directory and select y to proceed.

    Module Sun Crypto Accelerator gets added to the database.

  7. Restart the administration server.

  8. After the restart, select Security->Request Certificate->Cryptographic Module.

    The list displays the following: SUNW acceleration only, Internal, and keystore_name. Each keystore has its own entry in the list.

  9. Select the keystore.

    Do not select the option SUNW acceleration only, while creating server certificates.

Requesting and Installing a VeriSign Certificate

VeriSign is Proxy Server’s preferred Certificate Authority. The company’s technology simplifies the certificate request process. VeriSign has the advantage of being able to return its certificate directly to your server.

After creating a certificate trust database for your server, you can request a certificate and submit it to a CA (Certificate Authority). If your company has its own internal CA, request your certificate from that department. If you plan to purchase your certificate from a commercial CA, choose a CA and ask for the specific format of the information they require.

The Administration Server can have only one server certificate. Each server instance can have its own server certificate.

ProcedureTo Request a VeriSign Certificate

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Request VeriSign Certificate link.

  3. Review the steps listed on the page that displays and click OK.

    The VeriSign Enrollment Wizard walks you through the process.

ProcedureTo Iinstall a VeriSign Certificate

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Install VeriSign Certificate link.

  3. Unless you plan to use an external encryption module, select Internal from the Cryptographic Module drop-down list.

  4. Type your key-pair file password or PIN.

  5. Select the Transaction ID to retrieve from the drop-down list and click OK.

Requesting and Installing Other Server Certificates

In addition to VeriSign, you can also request and install certificates from other Certificate Authorities. Your company or organization might provide its own internal certificates. This section describes how to request and install other types of server certificates.

This section contains the following topics:

Required CA Information

Before you start the request process, make sure you know what information your CA requires. The format of the requested information varies by CA, but you might typically be asked to provide the information listed below. Most of this information is usually not required for certificate renewals.

All information is combined as a series of attribute-value pairs called the distinguished name (DN), which uniquely identifies the subject of the certificate.

If you are purchasing your certificate from a commercial CA, you must contact the CA to find out what additional information they require before they issue a certificate. Most CAs require that you prove your identity. For example, they want to verify your company name and who is authorized by the company to administer the server, they also might ask whether you have the legal right to use the information you provide.

Some commercial CAs offer certificates with greater detail and veracity to organizations or individuals who provide more thorough identification. For example, you might be able to purchase a certificate stating that the CA has verified that you are the rightful administrator of the www.example.com computer, and also that you are a company that has been in business for three years, and have no outstanding customer litigation.

Requesting Other Server Certificates

ProcedureTo Request Other Server Certificates

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Request Certificate link.

  3. Specify whether this is a new certificate or a certificate renewal.

    Many certificates expire after a set period of time, such as six months or a year. Some CAs will automatically send you a renewal.

  4. Specify how you want to submit the request for the certificate:

    • To submit the request using email, select CA Email Address and enter the appropriate email address for such requests.

      • To submit the request using the CA’s web site, select CA URL and type the appropriate URL for such requests.

  5. From the Cryptographic Module drop-down list, select the cryptographic module to be used for the key-pair file when requesting the certificate.

  6. Type the password for your key-pair file.

    This password is specified when you created the trust database, unless a cryptographic module other than Internal is selected. The server uses the password to obtain your private key and encrypt a message to the CA. The server then sends both your public key and the encrypted message to the CA. The CA uses the public key to decrypt your message.

  7. Provide your identification information, such as name and phone number.

    The format of this information varies by CA. Most of this information is usually not required for certificate renewals.

  8. Double-check your work to ensure accuracy, and then click OK.

    The more accurate the information, the faster your certificate is likely to be approved. If your request is going to a certificate server, you will be prompted to verify the form information before the request is submitted.

    The server generates a certificate request that contains your information. The request has a digital signature created with your private key. The CA uses a digital signature to verify that the request was not tampered with during routing from your server computer to the CA. In the rare event that the request is tampered with, the CA usually contacts you by phone.

    If you chose to email the request, the server sends an email message containing the request to the CA. Typically, the certificate is then emailed to you. If you specified a URL to a certificate server, your server uses the URL to submit the request to the certificate server. You might get an email response or a response by some other means, depending on the CA.

    The CA notifies you if it agrees to issue you a certificate. In most cases, the CA sends your certificate using e-mail. If your organization is using a certificate server, you may be able to search for the certificate using the certificate server’s forms.

    Note –

    Not everyone who requests a certificate from a commercial CA is given one. Many CAs require you to prove your identity before issuing a certificate. Also, approval often can take anywhere from one day to several weeks. You are responsible for promptly providing all necessary information to the CA.

    Install the certificate once you receive it. In the meantime, you can still use your Proxy Server without SSL.

Installing Other Server Certificates

Your certificate from the CA is encrypted with your public key so that only you can decrypt it. Only by entering the correct password for your trust database can you decrypt and install your certificate.

The three types of certificates are:

A certificate chain is a hierarchical series of certificates signed by successive Certificate Authorities. A CA certificate identifies a Certificate Authority and is used to sign certificates issued by that authority. A CA certificate can in turn be signed by the CA certificate of a parent CA, and so on, up to a root CA.

Note –

If your CA does not automatically send you its certificate, request it. Many CAs include their certificate in the email with your certificate, and both certificates are installed by your server at the same time.

Your certificate from the CA is encrypted with your public key so that only you can decrypt it. The Proxy Server uses the key-pair file password you specify to decrypt the certificate when it is installed. You can either save the email somewhere accessible to the server, or copy the text of the email and be ready to paste the text into the Install Certificate form, as described in the following procedure.

ProcedureTo Install Other Server Certificates

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Install Certificate link.

  3. Next to Certificate For, select the type of certificate to install:

    • This Server

      • Server Certificate Chain

      • Certification Authority

        For more information about specific settings, see the online Help.

  4. Select the cryptographic module from the drop-down list.

  5. Type the key-pair file password.

  6. Type a certificate name only if you selected Server Certificate Chain or Certification Authority in Step 3.

  7. Provide certificate information by doing one of the following:

    • Select Message Is In This File and then type the full path name to the file that contains the CA certificate.

      • Select Message Text (with headers) and then copy and paste the content of the CA certificate. Be sure to include the Begin Certificate and End Certificate headers, including the beginning and ending hyphens.

  8. Click OK.

  9. Indicate whether you are adding a new certificate or renewing an existing certificate.

    • Add Certificate if you are installing a new certificate.

      • Replace Certificate if you are installing a certificate renewal.

        The certificate is stored in the server’s certificate database. For example:

        server-root/alias/proxy-serverid-cert8.db

Migrating Certificates From Previous Versions

When migrating from Sun ONE Web Proxy Server 3.6 (also known as Sun iPlanet Web Proxy Server) to iPlanet Web Proxy Server 4, your files, including your trust and certificate databases, are updated automatically.

Make sure that the Proxy Server 4 Administration Server has read permissions on the old 3.x database files. The files are alias-cert.db and alias-key.db, located in the 3.x-server-root/alias directory.

Key-pair files and certificates are migrated only if security is enabled for your server. You can also migrate keys and certificates by themselves using the Migrate 3.x Certificates option under the Security tab in the Administration Server and the Server Manager. For information about specific settings, see the online Help.

In previous versions, a certificate and key-pair file were referred to by an alias that could be used by multiple server instances. The Administration Server managed all of the aliases and their constituent certificates. In Proxy Server 4, the Administration Server and each server instance have their own certificate and key-pair file, referred to as a trust database instead of an alias.

The trust database and its constituent certificates are managed from the Administration Server for the Administration Server itself, and from the Server Manager for server instances. The certificate and key-pair database files are named after the server instance that uses them. If, in the previous version, multiple server instances shared the same alias, when migrated the certificate and key-pair file are renamed for the new server instance.

The entire trust database associated with the server instance is migrated. All CAs listed in your previous database are migrated to the Proxy Server 4 database. If duplicate CAs occur, use the previous CA until it expires. Do not attempt to delete duplicate CAs.

Proxy Server 3.x certificates are migrated to the supported Network Security Services (NSS) format. The certificate is named according to the Proxy Server page from which it was accessed, that is, from the Administration Server Security tab or the Server Manager Security tab.

ProcedureTo Migrate a Certificate

  1. From your local computer, access either the Administration Server or the Server Manager and select the Security tab.

  2. Click the Migrate 3.x Certificates link.

  3. Specify the root directory where the 3.6 server is installed.

  4. Specify the alias for this computer.

  5. Type the administrator’s password and click OK.

Using the Built-in Root Certificate Module

The dynamically loadable root certificate module included with Proxy Server contains the root certificates for many CAs, including VeriSign. The root certificate module enables you to upgrade your root certificates to newer versions in a much easier way. In the past, you were required to delete the old root certificates one at a time and then install the new ones one at a time. To install well-known CA certificates, you can now simply update the root certificate module file to a newer version as it becomes available through future versions of the Proxy Server.

Because the root certificate is implemented as a PKCS #11 cryptographic module, you can never delete the root certificates it contains. The option to delete will not be offered when managing these certificates. To remove the root certificates from your server instances, disable the root certificate module by deleting the following entry in the server’s aliasdirectory:

If you want to restore the root certificate module, you can copy the extension from server-root/bin/proxy/lib (UNIX) or server-root\\bin\\proxy\\bin (Windows) into the alias subdirectory.

You can modify the trust information of the root certificates. The trust information is written to the certificate database for the server instance being edited, not back to the root certificate module itself.

Managing Certificates

You can view, delete, or edit the trust settings of your own certificate and certificates from CAs installed on your server.

ProcedureTo Manage Certificates

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Manage Certificates link.

    • If you are managing a certificate for a default configuration using the internal cryptographic module, a list of all installed certificates with their type and expiration date is displayed. All certificates are stored in the directory server-root/alias.

      • If you are using an external cryptographic module, such as a hardware accelerator, you must first type your password for each specific module and click OK. The certificate list will update to include certificates in the module.

  3. Click the name of the certificate you want to manage.

    A page appears with management options for that type of certificate. Only CA certificates allow you to set or unset client trust. Some external cryptographic modules will not allow certificates to be deleted.

  4. Specify the desired action.

    The following options are available:

    • Delete certificate or Quit for certificates obtained internally

      • Set client trust, Unset server trust, or Quit for CA certificates

        Certificate information includes the owner and who issued it. Trust settings allow you to set client trust or unset server trust. For LDAP server certificates, the server must be trusted.

Installing and Managing CRLs and CKLs

Certificate revocation lists (CRLs) and compromised key lists (CKLs) make known any certificates and keys that either client or server users should no longer trust. If data in a certificate changes, such as when a user changes offices or leaves the organization before the certificate expires, the certificate is revoked, and its data appears in a CRL. If a key is tampered with or otherwise compromised, the key and its data appear in a CKL. Both CRLs and CKLs are produced and periodically updated by a CA. Contact your specific CA to obtain these lists.

This section describes how to install and manage CRLs and CKLs.

ProcedureTo Install CRLs or CKLs

  1. Obtain a CRL or CKL from your CA and download it to a local directory.

  2. Access either the Administration Server or the Server Manager and click the Security tab.

  3. Click the Install CRL/CKL link.

  4. Select either:

    • Certificate Revocation List

      • Compromised Key List

  5. Type the full path name to the associated file and click OK.

    The Add Certificate Revocation List or Add Compromised Key List page appears, listing CRL or CKL information. If a CRL or CKL already exists in the database, a Replace Certificate Revocation List or Replace Compromised Key List page appears.

  6. Add or replace the CRL or CKL.

ProcedureTo Manage CRLs and CKLs

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Manage CRL/CKL link.

    The Manage Certificate Revocation Lists /Compromised Key Lists page appears, listing all installed CRLs and CKLs and their expiration dates.

  3. Select a certificate from either the Server CRLs or Server CKLs list.

  4. Select Delete CRL or Delete CKL to delete the CRL or CKL. .

  5. Quit to return to the management page

Setting Security Preferences

Once you have a certificate, you can begin securing your server. Proxy Server provides many security elements, which are discussed in this section.

Encryption is the process of transforming information so it is unintelligible to anyone but the intended recipient. Decryption is the process of transforming encrypted information so that it is intelligible again. Proxy Server supports the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) encryption protocols.

A cipher is a cryptographic algorithm (a mathematical function) used for encryption or decryption. SSL and TLS protocols contain numerous cipher suites. Some ciphers are stronger and more secure than others. Generally speaking, the more bits a cipher uses, the harder decrypting the data will be.

In any two-way encryption process, both parties must use the same ciphers. Because a number of ciphers are available, you must enable your server for those most commonly used.

During a secure connection, the client and the server agree to use the strongest cipher they can both have for communication. You can choose ciphers from the SSL 2.0, SSL 3.0, and TLS protocols.

Note –

Improvements to security and performance were made after SSL 2.0. Do not use SSL 2.0 unless you have clients that are incapable of using SSL 3.0. Client certificates are not guaranteed to work with SSL 2.0 ciphers.

The encryption process alone is not enough to secure your server’s confidential information. A key must be used with the encrypting cipher to produce the actual encrypted result, or to decrypt previously encrypted information. The encryption process uses two keys to achieve this result: a public key and a private key. Information encrypted with a public key can be decrypted only with the associated private key. The public key is published as part of a certificate. Only the associated private key is safeguarded.

For a description of the various cipher suites and more information about keys and certificates, see Introduction to SSL.

You can specify which ciphers your server can use. Unless you have a compelling reason not to use a specific cipher, you should select them all. You might not wish to enable ciphers with less than optimal encryption.

Caution – Caution –

Do not select Enable No Encryption, Only MD5 Authentication. If no other ciphers are available on the client side, the server defaults to this setting and no encryption occurs.

This section contains the following topics:

SSL and TLS Protocols

Proxy Server supports the SSL and TLS protocols for encrypted communication. SSL and TLS are application independent, and higher-level protocols can be layered transparently on them.

SSL and TLS protocols support a variety of ciphers used to authenticate the server and client to each other, transmit certificates, and establish session keys. Clients and servers may support different cipher suites, or sets of ciphers, depending on factors such as which protocol they support, company policies on encryption strength, and government restrictions on export of encrypted software. Among other functions, the SSL and TLS handshake protocols determine how the server and client negotiate which cipher suites they will use to communicate.

Using SSL to Communicate With LDAP

You should require your Administration Server to communicate with LDAP using SSL.

Note –

In this scenario Proxy Server acts as SSL client and must have imported the root CA certificate which signs SSL server LDAP certificate. In case the SSL certificate for LDAP was not issued by a well known CA, the CA root key used must be imported to Proxy Server key store.

ProcedureTo enable LDAP with SSL connection on your Administration Server

  1. Access the Administration Server and click the Global Settings tab.

  2. Click the Configure Directory Service link.

  3. In the table that displays, click the link for the directory service.

    The Configure Directory Service page displays. If the LDAP-based directory service has not yet been created, select LDAP Server from the Create New Service of Type drop-down list, and then click New to configure the directory service. For more information about the specific fields that display for an LDAP-based directory service, see the online Help.

  4. Select Yes to use SSL for connections, and then click Save Changes.

Tunneling SSL Through the Proxy Server

When you are running a Proxy Server (proxy) in the forward direction and a client requests an SSL connection to a secure server through the proxy, the proxy opens a connection to the secure server and copies data in both directions without intervening in the secure transaction. This process is known as SSL tunneling, and is illustrated in the following figure.

Figure 5–1 SSL Connection

Diagram showing an SSL connection from a client to a secure server through the proxy server

To use SSL tunneling with HTTPS URLs, the client must support both SSL and HTTPS. HTTPS is implemented using SSL with normal HTTP. Clients without HTTPS support can still access HTTPS documents using the Proxy Server’s HTTPS proxying capability.

SSL tunneling is a lower-level activity that does not affect the application level (HTTPS). SSL tunneling is just as secure as SSL without proxying. The existence of the proxy in between does not in any way compromise security or reduce the functionality of SSL.

With SSL, the data stream is encrypted, so the proxy has no access to the actual transaction. Consequently, the access log cannot list the status code or the header length received from the remote server. This process also prevents the proxy, or any other third party, from eavesdropping on the transactions.

Because the proxy never sees the data, it cannot verify that the protocol used between the client and the remote server is SSL. Therefore the proxy also cannot prevent other protocols from being passed through. You should restrict SSL connections to only well-known SSL ports, namely port 443 for HTTPS and 563 for SNEWS, as assigned by the Internet Assigned Numbers Authority (IANA). If sites run the secure server on some other port, you can make explicit exceptions to allow connections to other ports on certain hosts by using the connect://.* resource.

The SSL tunneling capability is actually a general, SOCKS-like capability that is protocol independent, so you can also use this feature for other services. Proxy Server can handle SSL tunneling for any application with SSL support, not just the HTTPS and SNEWS protocols.

Configuring SSL Tunneling

The following procedure describes how to configure your Proxy Server to tunnel SSL.

ProcedureTo configure SSL tunneling

  1. Access the Server Manager for a server instance and click the Routing tab.

  2. Click the Enable/Disable Proxying link.

  3. Select the connect://.*.443 resource from the drop-down list.

    The connect:// method is an internal proxy notation that does not exist outside of the proxy. See Technical Details for SSL Tunneling for more information about connect.

    To allow connections to other ports, you can use similar URL patterns in a template. For more information about templates, see Chapter 16, Managing Templates and Resources.

  4. Select Enable Proxying Of This Resource and click OK.

    Caution – Caution –

    If the proxy is misconfigured, someone can use the proxy to make it appear that a telnet connection is coming from the proxy host rather than the actual connecting host. Therefore do not allow any more ports than absolutely necessary, and use access control on your proxy to restrict the client hosts.

Technical Details for SSL Tunneling

Internally, SSL tunneling uses the CONNECT method with the destination host name and port number as a parameter followed by an empty line:

CONNECT energy.example.com:443 HTTP/1.0

The following example shows a successful response from the Proxy Server, followed by an empty line:

HTTP/1.0 200 Connection establishedProxy-agent: Oracle-iPlanet-Proxy-Server/4.0

The connection is then set up between the client and the remote server. Data can be transferred in both directions until either closes the connection.

Internally, to benefit from the typical configuration mechanism based on URL patterns, the host name and port number are automatically mapped into a URL such as this:

connect://energy.example.com:443

connect:// is an internal notation used by Proxy Server to make configuration easier and more uniform with other URL patterns. Outside of the Proxy Server, connect URLs do not exist. If the Proxy Server receives such a URL from the network, it marks the URL as invalid and refuses to service the request.

Enabling Security for Listen Sockets

You can secure your server’s listen sockets by doing the following:

Note –

You can enable security only in reverse proxy mode and not in forward proxy mode.

Turning Security On

You must turn security on before you can configure the other security settings for your listen socket. You can turn security on when you create a new listen socket or edit an existing one.

ProcedureTo Turn Security on When Creating Listen Sockets

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Add Listen Socket link.

  3. Provide the required information.

    Note –

    Use the Edit Listen Sockets link to configure the security settings after a listen socket has been created.

  4. To turn security on, select Enabled from the Security drop-down list, and then click OK.

    If a server certificate has not been installed, your only choice will be Disabled. For more information about specific settings, see the online Help.

ProcedureTo Turn Security on When Editing Listen Sockets

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link.

  3. Click the link for the listen socket you want to edit.

  4. Select Enabled from the Security drop-down list, and click OK.

    If a server certificate has not been installed, your only choice will be Disabled.

Selecting Server Certificates for Listen Sockets

You can configure listen sockets in either the Administration Server or the Server Manager to use server certificates you have requested and installed.

Note –

At least one certificate must be installed.

ProcedureTo Select a Server Certificate for a Listen Socket

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link.

  3. Click the link for the listen socket you want to edit.

  4. Select Enabled from the Security drop-down list, and click OK.

    If a server certificate has not been installed, your only choice will be Disabled.

  5. Select a server certificate from the drop-down Server Certificate Name list for the listen socket, and then click OK.

Selecting Ciphers

To protect the security of the Proxy Server, you should enable SSL. You can enable the SSL 2.0, SSL 3.0, and TLS encryption protocols and select the various cipher suites. The SSL and TLS protocols can be enabled on the listen socket for the Administration Server. Enabling SSL and TLS on a listen socket for the Server Manager sets those security preferences for specific server instances. At least one certificate must be installed.

Note –

Enabling SSL on a listen socket applies only when the Proxy Server is configured to perform reverse proxying.

The default settings allow the most commonly used ciphers. Unless you have a compelling reason for not using a specific cipher suite, you should select them all.

The default and recommended setting for TLS Rollback is Enabled. This setting configures the server to detect “man-in-the-middle version rollback” attack attempts. Setting TLS Rollback to Disabled might be required for interoperability with some clients that incorrectly implement the TLS specification.

Disabling TLS Rollback leaves connections vulnerable to version rollback attacks. Version rollback attacks are a mechanism by which a third party can force a client and server to communicate using an older, less secure protocol such as SSL 2.0. Because SSL 2.0 protocol has known deficiencies, failing to detect “version rollback” attack attempts makes intercepting and decrypting encrypted connections easier for a third party.

ProcedureTo Enable SSL and TLS

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link, and then click the link for the listen socket you want to edit.

    For a secure listen socket, the available cipher settings are displayed.

    If security is not enabled on the listen socket, no SSL and TLS information is listed. To work with ciphers, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.

  3. Select the checkboxes corresponding to the required encryption settings and click OK.

  4. Select both TLS and SSL 3.0 for Netscape Navigator 6.0. For TLS Rollback also select TLS, and make sure both SSL 3.0 and SSL 2.0 are disabled.

    Once SSL has been enabled on a server, its URLs use https instead of http. URLs that point to documents on an SSL-enabled server are formatted as : https://servername.domain.dom:port, for example, https://admin.example.com:443

    If you use the default secure HTTP port (443), you do not need to enter the port number in the URL.

Configuring Security Globally

Installing an SSL-enabled server creates directive entries in the magnus.conf file, the server’s main configuration file for global security parameters.

SSLSessionTimeout

The SSLSessionTimeout directive controls SSL 2.0 session caching. The syntax is:

SSLSessionTimeout seconds

where seconds is the number of seconds until a cached SSL session becomes invalid. The default value is 100. If the SSLSessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 100 seconds.

SSLCacheEntries

Specifies the number of SSL sessions that can be cached.

SSL3SessionTimeout

The SSL3SessionTimeout directive controls SSL 3.0 and TLS session caching. The Syntax is:

SSL3SessionTimeout seconds

where seconds is the number of seconds until a cached SSL 3.0 session becomes invalid. The default value is 86400 (24 hours). If the SSL3SessionTimeout directive is specified, the value of seconds is silently constrained to be between 5 and 86400 seconds.

ProcedureTo Set Values for SSL Configuration File Directives

  1. Access the Server Manager for a server instance.

  2. Ensure that security is enabled for the listen socket you want to configure.

    For more information, see Enabling Security for Listen Sockets.

  3. Manually edit the magnus.conf file and provide values for the following settings:

    • SSLSessionTimeout

    • SSLCacheEntries

    • SSL3SessionTimeout

    For more information about magnus.conf, see Oracle iPlanet Web Proxy Server 4.0.14 Configuration File Reference.

Using External Encryption Modules

Proxy Server supports the following methods of using external cryptographic modules such as smart cards or token rings:

You must add the PKCS #11 module before activating the FIPS-140 encryption standard.

This section contains the following topics:

Installing the PKCS #11 Module

Proxy Server supports Public Key Cryptography Standard (PKCS) #11, which defines the interface used for communication between SSL and PKCS #11 modules. PKCS #11 modules are used for standards-based connectivity to SSL hardware accelerators. Imported certificates and keys for external hardware accelerators are stored in the secmod.db file, which is generated when the PKCS #11 module is installed. The file is located in the server-root/alias directory.

Using the Tool modutil to Install PKCS #11 Modules

You can install PKCS #11 modules in the form of .jar files or object files using the modutil tool.

ProcedureTo Install PKCS #11 modules using the Tool modutil

  1. Make sure that all servers, including the Administration Server, have been stopped.

  2. Go to the server-root/alias directory containing the databases.

  3. Add server-root/bin/proxy/admin/bin to your PATH.

  4. Locate modutil in server-root/bin/proxy/admin/bin.

  5. Set the environment.

    • On UNIX: setenv

      LD_LIBRARY_PATH server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • On Windows, add it to the PATH

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      You can find the PATH for your computer listed underserver-root/proxy-admserv/start.

  6. In a terminal window, type modutil.

    The options will be listed.

  7. Perform the actions required.

    For example, to add the PKCS #11 module in UNIX, enter:

    modutil -add (name of PKCS#11 file) -libfile (your libfile for PKCS #11) -nocertdb -dbdir . (your db directory)

Exporting with the tool pk12util

Using pk12util enabless you to export certificates and keys from your internal database and import them into an internal or external PKCS #11 module. You can always export certificates and keys to your internal database, but most external tokens will not allow you to export certificates and keys. By default, pk12util uses certificate and key databases named cert8.db and key3.db.

ProcedureTo Export a Certificate and Key From an Internal Database

  1. Go to the server-root/alias directory containing the databases.

  2. Add server-root/bin/proxy/admin/bin to your PATH.

  3. Locate pk12util in server-root/bin/proxy/admin/bin.

  4. Set the environment.

    • On UNIX:

      setenv LD_LIBRARY_PATH/server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

    • On Windows, add it to the PATH

      LD_LIBRARY_PATH server-root/bin/proxy/bin

      You can find the PATH for your computer listed under: server-root/proxy-admserv/start.

  5. In a terminal window, type pk12util.

    The options will be listed.

  6. Perform the actions required.

    For example, in UNIX type

    pk12util -o certpk12 -n Server-Cert [-d /server/alias] [-P https-test-host]

  7. Type the database password.

  8. Type the pkcs12 password.

ProcedureTo Import a Certificate and Key Into an Internal or External PKCS #11 Module

  1. Go to the server-root/alias directory containing the databases.

  2. Add server-root/bin/proxy/admin/bin to your PATH.

  3. Locate pk12util in server-root/bin/proxy/admin/bin.

  4. Set the environment.

    For example:

    • On UNIX:

      setenv LD_LIBRARY_PATH/server-root/bin/proxy/lib:${LD_LIBRARY_PATH}

      • On Windows, add to the PATH

        LD_LIBRARY_PATH server-root/bin/proxy/bin

        You can find the PATH for your computer listed under server-root/proxy-admserv/start.

  5. In a terminal window, type pk12util.

    The options will be listed.

  6. Perform the actions required.

    For example, in UNIX enter:

    pk12util -i pk12_sunspot [-d certdir][-h “nCipher”][-P https-jones.redplanet.com-jones-]

    -P must follow -h and must be the last argument.

    Type the exact token name including capital letters and spaces between quotation marks.

  7. Type the database password.

  8. Type the pkcs12 password.

Starting the Server With an External Certificate

If you install a certificate for your server into an external PKCS #11 module, for example, a hardware accelerator, the server will not be able to start using that certificate until you edit the server.xml file or specify the certificate name as described below.

The server always tries to start with the certificate named Server-Cert. However, certificates in external PKCS #11 modules include one of the module’s token names in their identifier. For example, a server certificate installed on an external smartcard reader called smartcard0 would be named smartcard0:Server-Cert.

To start a server with a certificate installed in an external module, you must specify the certificate name for the listen socket on which it runs.

ProcedureTo Select the Certificate Name for a Listen Socket

If security is not enabled on the listen socket, certificate information will not be listed. To select a certificate name for a listen socket, you must first ensure that security is enabled on the listen socket. For more information, see Enabling Security for Listen Sockets.

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link.

  3. Click the link for the listen socket that you want to associate with a certificate.

  4. Select a server certificate from the Server Certificate Name drop-down list for the listen socket and click OK.

    The list contains all internal and external certificates installed.

    You could also require the server to start with that server certificate instead, by manually editing the server.xml file. Change the servercertnickname attribute in the SSLPARAMS to:

    $TOKENNAME:Server-Cert

    To find what value to use for $TOKENNAME, go to the server’s Security tab and select the Manage Certificates link. When you log in to the external module where Server-Cert is stored, its certificates are displayed in the list in the $TOKENNAME:$NICKNAME form.

    If you did not create a trust database, one will be created for you when you request or install a certificate for an external PKCS #11 module. The default database created has no password and cannot be accessed. Your external module will work, but you will not be able to request and install server certificates. If a default database has been created without a password, use the Create Database page on the Security tab to set the password.

FIPS-140 Standard

The PKCS #11 APIs enable communication with software or hardware modules that perform cryptographic operations. Once PKCS #11 is installed on your Proxy Server, you can configure the server to be FIPS-140 compliant. FIPS stands for Federal Information Processing Standards. These libraries are included only in SSL 3.0.

ProcedureTo Enable FIPS-140

  1. Install the plug-in following the FIPS-140 instructions.

  2. Access either the Administration Server or the Server Manager and click the Preferences tab.

  3. Click the Edit Listen Sockets link.

    For a secure listen socket, the Edit Listen Sockets page displays the available security settings.

    To work with FIPS-140, ensure that security is enabled on the selected listen socket. For more information, see Enabling Security for Listen Sockets.

  4. Select Enabled from the SSL Version 3 drop-down list, if not already selected.

  5. Select the appropriate FIPS-140 cipher suite and click OK:

    • Enable Triple DES with 168–bit encryption and SHA authentication (FIPS)

      • Enable DES with 56–bit encryption and SHA authentication (FIPS)

Setting Client Security Requirements

After you have performed all of the steps to secure your servers, additional security requirements can be set for your clients.

Client authentication is not essential to an SSL connection, but it does give extra assurance that encrypted information is being sent to the correct parties. You can use client authentication in a reverse proxy to make sure that your content server does not share information with unauthorized proxies or clients.

This section contains the following topics:

Requiring Client Authentication

You can enable the listen sockets for your Administration Server and each server instance to require client authentication. When client authentication is enabled, the client’s certificate is required before the server sends a response to a query.

Proxy Server supports authenticating client certificates by matching the CA in the client certificate with a CA trusted for signing client certificates. You can view a list of CAs trusted for signing client certificates on the Manage Certificates page through the Security tabs.

You can configure the Proxy Server to refuse any client that does not have a client certificate from a trusted CA. To accept or reject trusted CAs, client trust must be set for the CA. For more information, see Managing Certificates.

Proxy Server logs an error, rejects the certificate, and returns a message to the client if the certificate has expired. You can also view which certificates have expired on the Manage Certificates page.

You can configure your server to gather information from the client certificate and match it with a user entry in an LDAP directory. This process ensures that the client has a valid certificate and an entry in the LDAP directory. It can also ensure that the client certificate matches the one in the LDAP directory. To learn how to do this, Mapping Client Certificates to LDAP.

You can combine client certificates with access control, so that in addition to being from a trusted CA, the user associated with the certificate must match the access control rules (ACLs). For more information, see Using Access Control Files.

ProcedureTo Require Client Authentication

  1. Access either the Administration Server or the Server Manager and click the Preferences tab.

  2. Click the Edit Listen Sockets link.

  3. Click the link for the listen socket for which you are requiring client authentication.

  4. Use the Client Authentication drop-down list to require client authentication for the listen socket, and click OK.

Client Authentication in a Reverse Proxy

In a reverse proxy, you can configure client authentication according to any of the following scenarios:

For information about how to configure these scenarios, see Setting Up Client Authentication in a Reverse Proxy.

Setting Up Client Authentication in a Reverse Proxy

Client authentication in a secure reverse proxy provides further insurance that your connections are secure. The following instructions explain how to configure client authentication according to the scenario you choose.

Note –

Each scenario assumes that you have both a secure Client-to-Proxy connection and a secure Proxy-to-Content-Server connection.

ProcedureTo Configure the Proxy-Authenticates-Client Scenario

  1. Follow the directions for configuring the secure Client-to-Proxy and secure Proxy-to-Content Server scenario in “Setting up a Reverse Proxy” in Chapter 14, Using a Reverse Proxy.

  2. Access the Server Manager for a server instance and click the Preferences tab.

  3. Click the Edit Listen Sockets link, and then click the link for the desired listen socket in the table that displays.

    (Use the Add Listen Socket link to configure and add listen sockets.)

  4. Specify client authentication requirements:

    1. To permit access to all users with valid certificates:

      In the Security section, use the Client Authentication setting to require client authentication on this listen socket. If a server certificate has not been installed, this setting will not be visible.

    2. To permit access to only those users who have both valid certificates and are specified as acceptable users in access control:

      1. In the Security section, leave the Client Authentication setting set to off. If a server certificate has not been installed, this setting will not be visible.

      2. On the Server Manager Preferences tab for this server instance, click the Administer Access Control link.

      3. Select an ACL, and then click the Edit button.

        The Access Control Rules For page displays (authenticate first, if prompted).

      4. Turn access control on (select the Access control Is On checkbox if not already selected).

      5. Set your Proxy Server to authenticate as a reverse proxy.

        For more information, see Setting up a Reverse Proxy.

      6. Click the Rights link for the desired access control rule, specify access rights in the lower frame, and then click Update to update this entry.

      7. Click the Users/Groups link. In the lower frame. Specify users and groups, select SSL as the authentication method, and click Update to update this entry.

      8. Click Submit in the upper frame to save your entries.

        For more information about setting access control, see Chapter 8, Controlling Access to Your Server.

ProcedureTo Configure the Content Server-Authenticates-Proxy Scenario

  1. Follow the directions for configuring the secure Client-to-Proxy and secure Proxy-to-Content-Server scenario in Setting up a Reverse Proxy.

  2. On your content server, turn client authentication on.

    You can modify this scenario so that you have an unsecure client connection to the Proxy Server, a secure connection to the content server, and the content server authenticates the Proxy Server. To do so, you must turn encryption off and require the proxy to initialize certificates only as described in the following procedure.

ProcedureTo Configure the Proxy-Authenticates-Client and Content Server-Authenticates-Proxy scenario

  1. Follow the directions for configuring the Proxy-Authenticates-Client scenario in To Configure the Proxy-Authenticates-Client Scenario.

  2. On your content server, turn client authentication on.

Mapping Client Certificates to LDAP

This section describes the process that the Proxy Server uses to map a client certificate to an entry in an LDAP directory. Before mapping client certificates to LDAP, you must also configure the required ACLs. For more information, see Chapter 8, Controlling Access to Your Server.

When the server receives a request from a client, the server asks for the client’s certificate before proceeding. Some clients send the client certificate to the server along with the request.

The server tries to match the CA to the list of trusted CAs in the Administration Server. If a match does not exist, Proxy Server ends the connection. If a match exists, the server continues processing the request.

After verifying that the certificate is from a trusted CA, the server maps the certificate to an LDAP entry by doing the following:

The server uses a certificate mapping file called certmap.conf to determine how the LDAP search is performed. The mapping file tells the server what values to take from the client certificate such as the end user’s name, email address, and so on. The server uses these values to search for a user entry in the LDAP directory, but first the server must determine where in the LDAP directory to start the search. The certificate mapping file also tells the server where to start.

Once the server knows where to start the search and what to search for, it performs the search in the LDAP directory (second point). If it finds no matching entry or more than one matching entry, and the mapping is not set to verify the certificate, the search fails.

The following table lists the expected search result behavior. You can specify the expected behavior in the ACL. For example, you can specify that the Proxy Server accepts only you if the certificate match fails. For more information about how to set the ACL preferences, see Using Access Control Files.

Table 5–1 LDAP Search Results

LDAP Search Result  

Certificate Verification ON  

Certificate Verification OFF  

No entry found 

Authentication fails 

Authentication fails 

Exactly one entry found 

Authentication fails 

Authentication succeeds 

More than one entry found 

Authentication fails 

Authorization fails 

After the server finds a matching entry and certificate in the LDAP directory, the server can use that information to process the transaction. For example, some servers use certificate-to-LDAP mapping to determine access to a server.

Using the certmap.conf File

Certificate mapping determines how a server looks up a user entry in the LDAP directory. You can use the certmap.conf file to configure how a certificate, designated by name, is mapped to an LDAP entry. You edit this file and add entries to match the organization of your LDAP directory, and to list the certificates you want your users to have. Users can be authenticated based on user ID, email address, or any other value used in the subjectDN. Specifically, the mapping file defines the following information:

The certificate mapping file is found in the following location:

server-root/userdb/certmap.conf

The file contains one or more named mappings, each applying to a different CA. A mapping has the following syntax:

certmap name issuerDNname:property [value]

The first line specifies a name for the entry and the attributes that form the distinguished name found in the CA certificate. The name is arbitrary and can be defined to whatever you prefer. However, issuerDN must exactly match the issuer DN of the CA that issued the client certificate. For example, the following two issuer DN lines differ only in the spaces separating the attributes, but the server treats these two entries as different:

certmap sun1 ou=Sun Certificate Authority,o=Sun,c=UScertmap sun2 ou=Sun Certificate Authority, o=Sun, c=US

Note –

If you are using Oracle Directory Server Enterprise Edition and experiencing problems in matching the issuer DN, check the Directory Server error logs for useful information.

The second and subsequent lines in the named mapping match properties with values. The certmap.conf file has six default properties. You can also use the certificate API to customize your own properties. The default properties are:

Table 5–2 Attributes for x509v3 Certificates

Attribute  

Description  

c

Country 

o

Organization 

cn

Common name 

l

Location 

st

State 

ou

Organizational unit 

uid

UNIX/Linux userid 

email

Email address 

For more information about these properties, refer to the examples described in Sample Mappings.

Creating Custom Properties

The client certificate API can be used to create your own properties. Once you have a custom mapping, you reference the mapping as follows:

name:library path_to_shared_libraryname:InitFN name_of_init_function

For example:

certmap default1 o=Sun Microsystems, c=US default1:library /usr/sun/userdb/plugin.so default1:InitFn plugin_init_fn default1:DNComps ou o c default1:FilterComps l default1:verifycert on

Sample Mappings

The certmap.conf file should have at least one entry. The following examples illustrate the different ways certmap.conf can be used.

Example #1 certmap.conf File With Only One Default Mapping

certmap default defaultdefault:DNComps ou, o, cdefault:FilterComps e, uiddefault:verifycert on

Using this example, the server starts its search at the LDAP branch point containing the entry ou=orgunit, o=org, c=country, where the italicized text is replaced with the values from the subject’s DN in the client certificate.

The server then uses the values for e-mail address and user ID from the certificate to search for a match in the LDAP directory. When an entry is found, the server verifies the certificate by comparing the one sent by the client to the one stored in the directory.

Example #2 certmap.conf File With Two Mappings

The following example file has two mappings: one for default and another for the US Postal Service.

certmap default defaultdefault:DNCompsdefault:FilterComps e, uid

certmap usps ou=United States Postal Service, o=usps, c=USusps:DNComps ou,o,cusps:FilterComps eusps:verifycert on

When the server receives a certificate from anyone other than the US Postal Service, it uses the default mapping, which starts at the top of the LDAP tree and searches for an entry matching the client’s email address and user ID. If the certificate is from the US Postal Service, the server starts its search at the LDAP branch containing the organizational unit and searches for matching email addresses. Also the server verifies the certificate. Other certificates are not verified.

Caution – Caution –

The issuer DN (that is, the CA’s information) in the certificate must be identical to the issuer DN listed in the first line of the mapping. In the previous example, a certificate from an issuer DN that is o=United States Postal Service,c=US will not match because the DN has no space between the o and the c attributes.

Example #3 Searching the LDAP Database

The following example uses the CmapLdapAttr property to search the LDAP database for an attribute called certSubjectDN, whose value exactly matches the entire subject DN taken from the client certificate. This example assumes that the LDAP directory contains entries with the attribute certSubjectDN

certmap myco ou=My Company Inc, o=myco, c=USmyco:CmapLdapAttr certSubjectDNmyco:DNComps o, c myco:FilterComps mail, uid myco:verifycert on

If the client certificate subject is:

uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

the server first searches for entries that contain the following information:

certSubjectDN=uid=Walt Whitman, o=LeavesOfGrass Inc, c=US

If one or more matching entries are found, the server proceeds to verify the entries. If no matching entries are found, the server uses DNComps and FilterComps to search for matching entries. In this example, the server searches for uid=Walt Whitman in all entries under o=LeavesOfGrass Inc, c=US.

Setting Stronger Ciphers

The Set Cipher Size option on the Server Manager Preferences tab presents a choice of 168-bit, 128-bit, or 56-bit secret key size for access or no restriction. You can specify a file to be served when the restriction is not met. If no file is specified, Proxy Server returns a Forbidden status.

If you select a key size for access that is not consistent with the current cipher settings under Security Preferences, Proxy Server displays a warning that you need to enable ciphers with larger secret key sizes.

The implementation of the key size restriction is based on an NSAPI PathCheck directive in obj.conf, rather than Service fn=key-toosmall. This directive is:

PathCheck fn="ssl-check" [secret-keysize=nbits] [bong-file=filename]

where nbits is the minimum number of bits required in the secret key, and filename is the name of a file to be served if the restriction is not met.

PathCheck returns REQ_NOACTION if SSL is not enabled, or if the secret-keysize parameter is not specified. If the secret key size for the current session is less than the specified secret-keysize, the function returns REQ_ABORTED with a status of PROTOCOL_FORBIDDEN if bong-file is not specified. If , bong-file is specified, the function returns REQ_PROCEED, and the path variable is set to the bong-file filename. Also, when a key size restriction is not met, the SSL session cache entry for the current session is invalidated, so that a full SSL handshake occurs the next time the same client connects to the server.

Note –

The Set Cipher Size form removes any Service fn=key-toosmall directives found in an object when it adds a PathCheck fn=ssl-check.

ProcedureTo Set Stronger Ciphers

  1. Access the Server Manager for a server instance and click the Preferences tab.

  2. Click the Set Cipher Size link.

  3. From the drop-down list, select the resource to which to apply stronger ciphers, and then click Select. You can also specify a regular expression.

    For more information, see Chapter 16, Managing Templates and Resources.

  4. Select the secret key size restriction:

    • 168 bits or larger

      • 128 bits or larger

      • 56 bits or larger

      • No restrictions

  5. Specify the file location of the message to reject access, and click OK.

    For more information about ciphers, see Introduction to SSL.

Other Security Considerations

Other security risks exist beyond someone trying to break your encryption. Networks face risks from external and internal hackers, using a variety of tactics to gain access to your server and the information on it. In addition to enabling encryption on your server, you should take extra security precautions. For example, put the server computer in a secure room, and do not allow individuals you do not trust to upload programs to your server. This section describes some of the key things you can do to make your server more secure.

This section contains the following topics:

Limiting Physical Access

This simple security measure is often forgotten. Keep the server computer in a locked room that only authorized people can enter. This policy prevents anyone from hacking the server computer itself. Also, protect your computer’s administrative (root) password, if you have one.

Limiting Administration Access

If you use remote configuration, be sure to set access control to allow administration from only a few users and computers. If you want your Administration Server to provide end-user access to the LDAP server or local directory information, consider maintaining two Administration Servers and using cluster management. The SSL-enabled Administration Server then acts as the master server, and the other Administration Server is available for end-users’ access. For more information about clusters, see Chapter 6, Managing Server Clusters.

You should also turn encryption on for the Administration Server. If you do not use an SSL connection for administration, be cautious when performing remote server administration over an unsecure network. Anyone could intercept your administrative password and reconfigure your servers.

Choosing Strong Passwords

You use a number of passwords with your server: the administrative password, the private key password, database passwords, and so on. Your administrative password is the most important password, because anyone with that password can configure any and all servers on your computer. Your private key password is the next most important. Anyone who has your private key and your private key password, can create a fake server that appears to be yours, or intercept and change communications to and from your server.

A good password is one you will remember but others will not guess. For example, you could remember MCi12!mo as “My Child is 12 months old!” An example of a bad password is your child’s name or birthday.

Creating Hard-to-Crack Passwords

Use these guidelines to create a stronger password. You do not have to incorporate all of the following rules in one password, but the more rules you use, the better your chances of making your password hard to guess. Some tips:

Changing Passwords or PINs

Change your trust database/key-pair file password or PIN periodically. If your Administration Server is SSL-enabled, this password is required when starting the server. Changing your password periodically adds an extra level of server protection.

You should only change this password on your local computer. For a list of guidelines to consider when changing a password, see Creating Hard-to-Crack Passwords.

ProcedureTo Change the Trust Database/Key-Pair File Password

  1. Access either the Administration Server or the Server Manager and click the Security tab.

  2. Click the Change Key Pair File Password link.

  3. From the Cryptographic Module drop-down list, select the security token on which you want to change the password.

    By default, this token is Internal for the internal key database. If PKCS #11 modules are installed, all of the security tokens will be listed.

  4. Type your current password.

  5. Type your new password.

  6. Type the new password again and click OK.

    Make sure your key-pair file is protected. The Administration Server stores key-pair files in the directory server-root/alias.

    Know whether the file is stored on backup tapes or otherwise available for someone to intercept. If so, you must protect your backups as completely as your server.

Limiting Other Applications on the Server

Carefully consider all applications that run on the same computer as the server. Someone could circumvent your server’s security by exploiting holes in other programs running on your server. Disable all unnecessary programs and services. For example, the UNIX sendmail daemon is difficult to configure securely and can be programmed to run other, possibly detrimental, programs on the server computer.

UNIX and Linux

Carefully choose the processes started from inittab and rc scripts. Do not run telnet or rlogin from the server computer. You also should not have rdist on the server computer. This can distribute files but can also be used to update files on the server computer.

Windows

Carefully consider which drives and directories you share with other computers. Also, consider which users have accounts or guest privileges. Be careful about what programs you put on your server, or allow others to install. Other people’s programs might have security holes. Even worse, someone might upload a malicious program designed specifically to subvert your security. Always examine programs carefully before you allow them on your server.

Preventing Clients From Caching SSL Files

You can prevent pre-encrypted files from being cached by a client by adding the following line inside the <HEAD> section of an HTML file:

<meta http-equiv="pragma" content="no-cache">

Limiting Ports

Disable any ports not used on the computer. Use routers or firewall configurations to prevent incoming connections to anything other than the absolute minimum set of ports. This protection means that the only way to get a shell on the computer is to physically use the server’s computer, which should already be in a restricted area.

Knowing Your Server’s Limits

The server offers secure connections between the server and the client. It cannot control the security of information once the client has it, nor can it control access to the server computer itself and its directories and files.

Being aware of these limitations helps you understand what situations to avoid. For example, you might acquire credit card numbers over an SSL connection, but are those numbers stored in a secure file on the server computer? What happens to those numbers after the SSL connection is terminated? Be sure to secure any information clients send to you through SSL.