Secure Sockets Layer
The Secure Sockets Layer (SSL) protocol provides transport layer security: authenticity, integrity, and confidentiality, for a secure connection between a client and server in the 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 desired protection level for both client and application data.
Some of the security features provided by SSL are data encryption to prevent the exposure of sensitive information while data flows across the wire. Data signing prevents unauthorized modification of data while data flows across the wire. 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.
SSL and WebSphere
Application Server
In this figure:
- The built-in HTTP transport in a WebSphere Application Server accepts
HTTP requests over SSL from a Web client like a browser.
- The Object Request Broker 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 IBMJSSE provider
The SSL implementation used by the WebSphere Application Server is IBM Java Secure Sockets Extension (IBMJSSE). The IBMJSSE provider contains a reference implementation supporting SSL and Transport Layer Security (TLS) protocols and an application programming interface (API) framework. The IBMJSSE provider also comes with a standard provider, which supplies Rivest Shamir Adleman (RSA) support for the signature-related JCA features of the Java 2 platform, common SSL and TLS cipher suites, hardware cryptographic token device, X.509-based key and trust managers, and PKCS12 implementation for a JCA keystore. A graphical tool called Key Management Tool (iKeyman) also is provided to manage digital certificates. With this tool, you can create a new key database or a test digital certificate, add certificate authority (CA) roots to the database, copy certificates from one database to another, as well as request and receive a digital certificate from a CA.
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 support both signer and personal certificate storage
in an SSL key file, but it also supports a separate file called a trust
file. A trust file can contain only signer certificates. You can put all
of your personal certificates in an SSL key file and your signer certificates
in a trust file. This might be desirable, for example, if you have an inexpensive
hardware cryptographic device with only enough memory to hold a personal certificate.
In this case, the key file refers to the hardware device and the trust file
to a file on disk containing all of the signer certificates.
- The JSSE provider does not recognize the proprietary SSL key file format, which is used by the plug-in (.kdb files). Instead, the JSSE provider recognizes standard file formats such as Java Key Store (JKS). SSL key files might not be shared between the plug-in and appserver. Furthermore, a different implementation of the key management utility must be used to manage appserver key and trust files.
Certain limitations exist with the Java Secure Socket Extension (JSSE) provider:
- Customer code using JSSE and Java Cryptography Extension (JCE) APIs must
reside within a WebSphere Application Server environment. This restriction
includes applications deployed in WebSphere Application Server and client
applications in the J2EE application client environment.
- Only com.ibm.crypto.provider.IBMJCE, com.ibm.jsse.IBMJSSEProvider, com.ibm.security.cert.IBMCertPath, and com.ibm.crypto.pkcs11.provider.IBMPKCS11 are provided as the
cryptography package providers.
- Interoperability of the IBM JSSE
implementation with other SSL implementations by vendors is limited to tested
implementations. The tested implementations include Microsoft Internet Information
Services (IIS), BEA WebLogic Server, IBM AIX, and IBM AS/400.
- Hardware token support is limited to supported cryptographic token devices. .
Tested for SSL clients Tested for SSL clients or servers IBM Security Kit Smartcard IBM 4758-23 GemPlus Smartcards IBM 4758-23 Rainbow iKey 1000/2000(USB "Smartcard" device) IBM 4758-23
- The SSL protocol of V2.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 IBMJSSEFIPS and IBMJCEFIPS provider packages only.
Note: The IBMJSSEFIPS and IBMJCEFIPS modules are undergoing FIPS 140-2 certification. For more information on the FIPS certification process and to check the status of the IBM submission, see the Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List Web site.
Authenticity
Confidentiality
Integrity