The SSL protocol provides transport layer security (TLS) for a secure connection between a client and server in the WAS environment. TLS runs above TCP/IP and below application protocols such as HTTP, LDAP, and IIOP, and provides trust and privacy for the transport data.
Data encryption Prevent the exposure of sensitive information while data flows across the wire. Data signing Prevent unauthorized modification of data while data flows across the wire. Client/Server authentication Ensure that you talk to the appropriate person or machine.
SSL is used by the built-in HTTP transport, the ORB, and the secure LDAP client.
The IBMJSSE provider
The SSL implementation used by the WAS is IBM Java Secure Sockets Extension (IBMJSSE), which contains a reference implementation supporting SSL and TLS protocols and an API framework. The IBMJSSE provider also comes with a standard provider, which supplies 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.
Use iKeyman to manage and test digital certificates, create key databases, 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 application server 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 WAS environment. This restriction includes applications deployed in WAS 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 IIS, BEA WebLogic Server, IBM AIX, and IBM AS/400.
- Hardware token support is limited to supported cryptographic token devices.
- 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 WAS. 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 that 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 Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List Web site.
Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List