The Secure Sockets Layer (SSL) protocol provides transport layer
security with authenticity, integrity, and confidentiality, for a secure connection
between a client and server in WebSphere Application Server. The protocol
runs above TCP/IP and below application protocols such as Hypertext Transfer
Protocol (HTTP), Lightweight Directory Access Protocol (LDAP), and Internet
Inter-ORB Protocol (IIOP), and provides trust and privacy for the transport
data.
Depending upon the SSL configurations of both the client and server, various
levels of trust, data integrity, and privacy can be established. Understanding
the basic operation of SSL is very important to proper configuration and to
achieve the required protection level for both client and application data.
Some of the security features that are provided by SSL are data encryption
to prevent the exposure of sensitive information while data flows. Data signing
prevents unauthorized modification of data while data flows. Client and server
authentication ensures that you talk to the appropriate person or machine.
SSL can be effective in securing an enterprise environment.
SSL is used by multiple components within WebSphere Application Server
to provide trust and privacy. These components are the built-in HTTP transport,
the Object Request Broker (ORB), and the secure LDAP client.
Figure 1. SSL and WebSphere Application
Server
In this figure:
- The built-in HTTP transport in WebSphere Application Server accepts HTTP
requests over SSL from a Web client like a browser.
- The Object Request Broker that is used in WebSphere Application Server
can perform Internet Inter-ORB Protocol (IIOP) over SSL to secure the message.
- The secure LDAP client uses LDAP over SSL to securely connect to an LDAP
user registry and is present only when LDAP is configured as the user registry.
WebSphere Application Server and the IBM Java Secure Socket
Extension (IBMJSSE and IBMJSSE2) providers
Configuring the JSSE provider is very similar
to configuring most other SSL implementations (for example, GSKit); however,
a couple of differences are worth noting.
- The JSSE provider supports both signer and personal certificate storage
in an SSL key file, but it also supports a separate file called a trustfile.
A trustfile can contain only signer certificates. You can put all of your
personal certificates in an SSL keyfile and your signer certificates in a
trustfile. This support might be helpful, for example, if you have an inexpensive
hardware cryptographic device with only enough memory to hold a personal certificate.
In this case, the keyfile refers to the hardware device and the trustfile
refers to a file on a disk that contains all of the signer certificates.
- The JSSE provider does not recognize the proprietary SSL keyfile format,
which is used by the plug-in (.kdb files). Instead, the JSSE provider
recognizes standard file formats such as Java Key Standard (JKS). SSL keyfiles
might not be shared between the plug-in and application server. Furthermore,
a different implementation of the key management utility must be used to manage
application server key and trustfiles.
Certain limitations exist with the Java Secure Socket Extension
(JSSE) provider:
- Customer code using JSSE and Java Cryptography Extension (JCE) APIs must
reside within WebSphere Application Server environment. This restriction includes
applications that are deployed in WebSphere Application Server and client
applications in the J2EE application client environment.
- Hardware token support is limited to the Java Cryptography Extension V1.2.1, Hardware Cryptography
IBMJCE4758
- The SSL protocol of Version 2.0 is not supported. In addition, the JSSE
and JCE APIs are not supported with Java applet applications.
WebSphere Application Server and the Federal Information Processing
Standards for Java Secure Socket Extension and Java Cryptography Extension
providers
The Federal Information Processing Standards (FIPS)-approved
Java Secure Socket Extension (JSSE) and Java Cryptography Extension (JCE)
providers are optional in WebSphere Application Server. By default, the FIPS-approved
JSSE and JCE providers are disabled. When these providers are enabled, WebSphere
Application Server uses FIPS-approved cryptographic algorithms in the IBMJCEFIPS
provider package only.
The
native z/OS SSL is not FIPS compliant. However, features in WebSphere Application
Server for z/OS that use the native SSL include:
- Internet InterORB Protocol (IIOP)
- Hypertext Transfer Protocol (HTTPS)
HTTPS can be configured to use the Channel Framework. It should be configured
when FIPS is enabled on z/OS. See
Configuring transport chains for more information.