Secure Sockets Layer

 

+

Search Tips   |   Advanced Search

 

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 WAS. The protocol runs above TCP/IP and below application protocols such as HTTP, LDAP, and 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 WAS to provide trust and privacy. These components are the built-in HTTP transport, the ORB, and the secure LDAP client.

 

WAS and the IBMJSSE and IBMJSSE2 providers

The SSL implementations used by WAS are the IBM Java Secure Sockets Extension (IBMJSSE) and the IBM Java Secure Sockets Extension 2 (IBMJSSE2), which contain a reference implementation supporting SSL and TLS protocols and an API framework.

The IBMJSSE and IBMJSSE2 providers also come with a standard provider, which supplies RSA support for the signature-related J2CA 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 J2CA keystore.

A graphical tool called iKeyman also is provided to manage digital certificates. With this tool, one 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.

The HTTP and JMS transports utilize the transport channel service for asynchronous I/O. This framework requires the use of IBMJSSE2 provider for SSL. Any provider you specify other than the IBMJSSE2 provider in the SSL repertoire is ignored and the IBMJSSE2 provider is used. Other SSL transports such as IIOP over SSL and LDAP over SSL utilize the provider you specify in the SSL repertoire configuration.

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 trust file. A trust file can contain only signer certificates. We 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 JSSE provider:

• Customer code using JSSE and Java Cryptography Extension (JCE) APIs must reside within WAS environment. This restriction includes applications that are 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 IBMJSSE 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.

 

WAS and the Federal Information Processing

Standards for Java Secure Socket Extension and Java Cryptography Extension providers

The 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, WAS uses FIPS-approved cryptographic algorithms in the IBMJCEFIPS provider package only. Important: The IBMJCEFIPS module is a FIPS 140-2-approved cryptographic provider. For more information on the FIPS certification process, refer to Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List Web site.

 

See also

Configure SSL
Confidentiality
Integrity
Configuring FIPS JSSE files
Authenticity
Cryptographic Module Validation Program FIPS 140-1 and FIPS 140-2 Pre-validation List