Before requesting a server certificate, you must create a trust database. In the Sun Java System Web Server, the Administration Server and each server instance can have its own trust database. The trust database should only be created on your local machine.
When you create the trust database, you specify a password that is used for a key-pair file. You also need this password to start a server using encrypted communications. For a list of guidelines to follow when changing a password, see Changing Passwords or PINs.
You create and store the public and private keys in the trust database 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:
The Administration Server can only have one trust database. Each server instance can have its own trust database. Virtual servers are covered by the trust database created for their server instance.
To create a trust database, perform the following steps:
Access either the Administration Server or the Server Manager and choose the Security tab.
If using the Server Manager you must first select the server instance from the drop-down list.
Click Create Database link.
Enter a password for the database.
For the Server Manager, click Apply, and then Restart for changes to take effect.
By default, the web server prompts the administrator for the key database password before starting. If you want to be able to restart an unattended web server, you need to save the password in a password.conf file. Only do this if your system is adequately protected so that this file and the key databases are not compromised.
Normally, you cannot start an 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 store the password in plain-text format in a file, this is not recommended. The server’s password.conf file should be owned by root or the user who installed the server, allowing only the owner to have read and write access to the file.
On UNIX platform, 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.
If you have an NTFS file system on a windows, you should protect the directory that contains the password.conf file by restricting its access, even if you do not use the file. The directory should have read/write permissions for the administration server and the web server users. 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.
Make sure SSL is activated.
Create a new password.conf file in the config subdirectory of the server instance.
If you are using the internal PKCS#11 software encryption module that is provided with the server, enter the following information:
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:
Stop and restart your server for the new setting to take effect.
You will always be prompted to supply a password when starting the web server, even after the password.conf file has been created.