Generating an SSL/TLS Certificate and Key File

To use secure sockets, the server must have an SSL/TLS certificate and private key. This information is used by the SSL/TLS library functions to generate unique encryption keys for each connection and negotiate the secure connection with the client. EnterpriseOne provides a script file that can be used to generate a combination certificate/key file for use with SSL/TLS.

On Windows enterprise and deployment servers, the gencert.cmd file is used to generate a combination SSL/TLS certificate/private key file that is suitable for use with JDENET SSL/TLS. On UNIX and Linux systems, the file is called gencert.sh. On IBM System i, the command is GENCERT, which must be run from QSHELL. These files can be found in the system/bin32 (or bin64) directory on the enterprise server and also on the deployment server. The following illustration shows an example of running the script to generate a certificate. Notice that the system prompts you to enter data that is unique to your site to create the certificate/key file:

This image is described in the surrounding test.

The file generated by this script should be entered as the sslKeyFile parameter in the enterprise or deployment server JDE.INI file when using SSL/TLS. See Configuring the Enterprise Server JDE.INI File in this chapter. By default, the file is created in a directory outside the main system directory to ensure that the certificate/key file is preserved during an EnterpriseOne Tools release upgrade.

More about Certificates

It is not required to generate the certificate/key file on the server that will use it. You could, for example, generate a certificate/key file on the Deployment Server and move it to your Enterprise Server when you are ready to start using SSL/TLS.

You can also use commercially signed certificates, such as certificates validated by a company like Verisign or Cybertrust, to set up SSL/TLS for JDENET, with some caveats. The EnterpriseOne enterprise and deployment servers currently require a combination certificate and key file in PEM format. In addition, the file must not be pass-phrase protected. Currently, using a commercially signed certificate with the JDENET server does not offer any advantage over using the self-signed, internally generated certificate as described in this section.