Level: Introductory Bimal Shah (bimal@us.ibm.com), Advisory Software Engineer, IBM, Intel, Microsoft,HP
Aya Zaghloul (ayazag@us.ibm.com), Software Engineer,
IBM
20 Mar 2007 Achieve data security over open communications channels with Secure Sockets Layer (SSL), which provides encryption, certificate-based authentication, and security negotiations. This article, part one of a three-part series, describes SSL and explains why you should implement it on your Integrated Solutions Console. In parts two and three, follow a step-by-step guide to learn how to implement SSL on the Integrated Solutions Console versions 5.1 and 6.0.1, respectively.
Data security over open communication networks such as the Internet will always be a strong concern for developers and customers. Therefore, it is extremely important for a any product you use to be able to achieve a secure environment.
Secure Sockets Layer (SSL), developed jointly by Netscape Communications and RSA Data Security, can accomplish this security in an efficient manner. SSL provides encryption, certificate-based authentication, and security negotiations over an established network connection, and many companies and products have adopted SSL as their communication protocol of choice.
In this series, we'll concentrate on two main topics:
- Detailed information of how SSL works
- How versions 5.1 and 6.0.1 of the Integrated Solutions Console enable SSL in its environment
This article explores SSL and explains why it should be implemented in your Integrated Solutions Console environment. Parts two and three of the series will deliver a detailed, step-by-step guide to implementing and enabling SSL on the Integrated Solutions Console 5.1 and 6.0.1.
First, what it SSL?
What is SSL?
SSL is a protocol that provides privacy and integrity between two communicating applications using TCP/IP. The data going back and forth between client and server is encrypted using a symmetric algorithm.
A public-key algorithm (RSA) is used for the exchange of the encryption keys and for digital signatures. Public key cryptography defines an algorithm that uses two keys, each of which may be used to encrypt a message. If one key is used to encrypt a message, the other must be used to decrypt it. This makes it possible to receive secure messages by simply publishing one key (the public key) and keeping the other undisclosed (the private key).
Digital certificates
This takes us into the discussion of digital certificates, which play an important role in SSL. Digital certificates mainly serve two purposes:
- To establish the owner's identity
- To make the owner's public key available
A digital certificate is issued by a trusted authority -- a certificate authority (CA) -- and it is issued only for a limited time. When its expiration date passes, the digital certificate must be replaced. SSL uses digital certificates for key exchange, server authentication, and optionally, client authentication.
The digital certificate contains specific pieces of information about the identity of the certificate owner and about the certificate authority:
- The owner's distinguished name.
- The owner's public key.
- The date the digital certificate was issued.
- The date the digital certificate expires.
- The issuer's distinguished name. This is the distinguished name of the CA.
- The issuer's digital signature.
An SSL connection is always initiated by the client using a URL starting with https:// instead of http://.
Types of SSL certificates
SSL uses certificates to verify the connection. These SSL certificates sit on a secure server and are used to encrypt the data and to identify the Web site. The SSL certificate helps to prove the site belongs to who it says it belongs to and contains information about the certificate holder, the domain that the certificate was issued to, and the name of the Certificate Authority who issued the certificate.
There are three ways of obtaining an SSL certificate:
- Use a Certificate Authority (CA) certificate
- Use a self-signed certificate
- Use a dummy certificate
Use a Certificate Authority (CA) certificate
Certificate Authorities are organizations that are trusted by the industry as a whole and whose business is the issuing of Internet certificates. An example as to where this can be obtained is from VeriSign. To obtain a CA-signed certificate, you must provide enough information to the CA so that the CA can validate your identity. The CA creates a new certificate, digitally signs it, and then delivers it to you. Popular Web browsers are pre-configured to trust certificates that are signed by certain CAs; no further client configuration is necessary in order for a client to connect, through SSL, to the server to which the certificate has been issued.
Use a self-signed certificate
A self-signed certificate is a certificate that is created by the user himself. When using a self-signed certificate, the issuer of the certificate is the same as the subject. The beauty of this solution is that it takes less time to create a self-signed server certificate than it does to obtain a CA-signed server certificate. However, the self-signed certificate requires that any client that connects to the server that installs this certificate over an SSL connection be configured to trust the signer of this certificate. Because the certificate has been self-signed, the signature is not likely to be in the client's trust file and so must be added. If it is impractical to access to every client's trust file, do not use this configuration; obtain a CA-signed certificate instead. Self-signed certificates are only useful when each client interacting with the server can be configured to trust the certificate.
Use a dummy certificate
No, this isn't a less-intelligent version. Generally, dummy certificates contain "dummy" information that serves as placeholders to be temporarily used to set up SSL and test its functions in a specific environment. The Integrated Solutions Console provides a dummy certificate along with server and client trust and key files.
So what do you do after you've gotten the certificate?
Client/server authentication
After the certificate is obtained, it must be authenticated. There are two types of SSL authentication:
- Server-side authentication
- Client-side authentication
SSL server authentication lets you confirm a server's identity. SSL-enabled client software can use standard techniques of public-key cryptography to check that a server's certificate and public ID are valid and have been issued by a certificate authority listed in the client's list of trusted CAs. This confirmation might be important if the user, for example, is sending a credit card number over the network and wants to check the receiving server's identity.
SSL client authentication lets a server confirm a user's identity. Using the same techniques as those used for server authentication, SSL-enabled server software can check that a client's certificate and public ID are valid and have been issued by a certificate authority listed in the server's list of trusted CAs. This confirmation might be important if the server, for example, is a bank sending confidential financial information to a customer and wants to check the recipient's identity.
Figure 1 is a diagram that explains this process visually:
Figure 1. The client/server authentication dance
Key file versus trust file
The SSL implementation used by the WebSphere® Application Server stores personal certificates in an SSL key file and signer certificates in a trust file. A key file contains a collection of certificates, each one of which may be presented during an SSL connection initiation in order to prove identity. A trust file contains a collection of certificates that are considered trustworthy and against which the presented certificate will be matched during an SSL connection initiation in order to assure identity.
SSL and the WebSphere Application Server
A good example of an SSL implementation is in the IBM® WebSphere Application Server. Its security is built on a layered security architecture shown in Figure 2.
Figure 2. WebSphere Application Server's layered security
The Network Security layer provides transport-level authentication and message integrity and encryption. Communication between separate WebSphere Application Servers can be configured to use SSL and HTTPS. Additionally, IP Security and Virtual Private Network (VPN) might be used for added message protection.
The 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 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 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 to prevent unauthorized modification of data while data flows across the wire.
- Client and server authentication to ensure that you talk to the appropriate person or machine.
SSL can be effective in security 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, ORB, and secure LDAP client.
The SSL implementation used by the WebSphere Application Server is IBM Java™ Secure Sockets Extension (IBM JSSE) or IBM System SSL. The IBM JSSE provider contains a reference implementation supporting SSL and Transport Layer Security (TLS) protocols and an application programming interface (API) framework. The IBM JSSE provider also comes with a standard provider that supplies RSA support for the signature-related Java Cryptography Architecture (JCA) features of the Java 2 platform, common SSL and TLS cipher suites, X.509-based key and trust managers, and PKCS12 implementation for JCA keystore certificates.
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. 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 that 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 application server. Furthermore, a different implementation of the key management utility must be used to manage application server key and trust files.
SSL and the Integrated Solutions Console
The Integrated Solutions Console provides a common Web-based administrative console framework for hosting and integrating console modules in a manner that lets customers manage solutions rather than specific IBM products. This framework includes Portlet container, Java management applications, and Eclipse Help modules.
SSL can be configured to provide confidentiality and encryption. Communication between the client browser and the Integrated Solutions Console server can be protected using SSL.
Encryption is important because the Integrated Solutions Console uses form-based authentication, which does not encrypt the user ID and password that are transmitted during login. If a console module requires access to back-end resources over secure connections, its portlets can use SSL.
Why should I care about SSL?
Why should any of this matter? Because securely (and effectively) transmitting data over open communications channels is a critical component to maintaining a modern IT system, SSL is a powerful protocol to help achieve that security, and enabling SSL in an Integrated Solutions Console environment can be a complex and challenging task. Why challenging? Data security in a Web-based application environment such as an Integrated Solutions Console environment can seem a bit vague to first-timers because IT security itself is a broad topic -- it covers many different aspects in open communication networks.
The next two articles in the series will provide an understanding of the SSL-oriented data security in an Integrated Solutions Console-based environment. First we'll cover setup and enablement of SSL for Integrated Solutions Condole 5.1 (including using dummy, self-signed, and CA certificates) and then we'll explain the same for Integrated Solutions Console 6.0.1.
Resources Learn
Get products and technologies
Discuss
About the authors  | 
| | Bimal Shah has been the Service and Support Team Lead for the Integrated Solutions Console (ISC) for the last two years. He has developed and implemented unique componentization service and support processes for the Integrated Solutions Console, which has been extremely well received by its deployers and consumers. He has worked within various groups at IBM including VM, Power Parallel Systems, AUIML, and Personal Communications (with the 3270/5250 emulator). He holds bachelor's degree in electrical engineering (India) and a master's in computer science (NJIT). |
| 
| | Aya Zaghloul joined the Integrated Solutions Console team after graduating from North Carolina State University with a bachelor's degree in computer science. For the past five years, Aya has worked in various areas of the Integrated Solutions Console team, including development, test, tooling, and currently, Service and Support. |
Rate this page
| 
