This section includes the following steps to configure SSL with your IBM WebSphere Application Server.
For enabling SSL, WebSphere needs access to a user account in the local OS user registry that has permission to administer the system:
(Windows) Create a new Windows user who is part of the Administrators group and has the privilege to act as part of the operating system. (See Create a Windows user for WebSphere.)
(Linux, UNIX) The user can be a root user or another user who has root privileges. When you enable SSL on WebSphere, use the server identification and password of this user.
(Linux and Solaris) Create a shadow password file by entering pwconv (with no parameters) in the command prompt.
(Linux and Solaris) For WebSphere Application Server Local OS security registry to work, a shadow password file must exist. The shadow password file is usually named /etc/shadow and is based on the /etc/passwd file. If the shadow password file does not exist, an error occurs after enabling global security and configuring the user registry as Local OS.
Truststores and keystores can be created using ikeyman utility or admin console. To make ikeyman work properly, enure that the WebSphere installation path does not contain parentheses.
To convert a URL that begins with https, add a Signer certificate for that URL to the WebSphere server.
HTML-to-PDF conversion from the site whose certificate is added will now work from the Generate PDF service.
For an application to connect to SSL sites from inside WebSphere, a Signer certificate is required. It is used by Java Secure Socket Extensions (JSSE) to validate certificates that the remote side of the connection sent during an SSL handshake.
IBM WebSphere does not allow multiple calls to ORB.init() when Global Security is enabled. You can read about the permanent restriction at http://www-01.ibm.com/support/docview.wss?uid=swg1PK58704.
Perform the following steps to set the port to be dynamic and resolve the issue: