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:

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.