About WebLogic SSL

WebLogic Server's implementation of the SSL technology follows the Internet standard for security between two hosts connected on an insecure network. Use SSL in WebLogic Server whenever you want to protect data by authenticating users. The SSL protocol uses public key encryption. Public key encryption is a more secure form of standard encryption, also known as symmetric key encryption.

Symmetric Key Encryption

Most people are familiar with standard encryption, in which there is a shared secret between two parties. For example, Andrew and Bob could share a secret, called a key, which would then be used as part of the algorithm for encrypting their messages to each other.

Standard encryption uses a number of different algorithms. Some are secure and use industry and government standard encryption algorithms. Some are not secure, such as the key to a secret decoder ring that came in a cereal box. However, all standard encryption schemes share the concept that both sides know the same secret. As you can imagine, the distribution of the encryption keys can be a problem. How does Andrew secretly get a message to Bob before they have shared a secret key? What if Bob and Andrew are in separate countries? Will they need to meet in person before they can exchange encrypted messages? Public key encryption provides a way out of these dilemmas.

Public Key Encryption

Public key encryption technology was developed in the late 1970s by (among other scientists) MIT Professors Rivest, Shamir, and Adleman, who gave their names to the RSA algorithm. Over time, the RSA algorithm has become a widely used and respected encryption algorithm. The RSA public key encryption algorithm enables anyone to encrypt a message for Andrew, but only Andrew can decode it.

To use public key encryption, Andrew has two keys: a public key and a private key. Andrew provides his public key to anyone and everyone. Anyone who wants to send a message to Andrew uses this public key to encrypt the message. Once encrypted, the private key is required to decrypt it. As long as Andrew keeps his private key to himself, security is ensured.

RSA encryption works in both directions. If Andrew encrypts something with his private key, then anyone can use Andrew's public key to decrypt that message. This process is called a digital signature, because only Andrew can encrypt a message that can be decrypted by his public key.

However, how do you know that the public key you have for Andrew is really Andrew's public key? In practice, this problem is solved by a technology called digital certificates.

Digital Certificates

Digital certificates contain information that enables people to associate a given public key with a given user. If you receive Andrew's public key, you can use his digital certificate to prove that it is really Andrew's public key and not an impersonator's. A digital certificate typically contains the following information, at a minimum:

• Information regarding the keyholder's identity, such as name, organization, and so forth

• The keyholder's public key

• A digital signature on the information contained in the digital certificate, via an entity called a certificate authority

Certificate Authorities

A certificate authority certifies that a given public key corresponds to a given user. For example, a certificate authority might grant a digital certificate to a user who receives mail at a given email address. The certificate authority verifies that the user definitely owns that email address through a series of email exchanges with the user. Certificate authorities sometimes require stronger proof material, such as a valid driver's license number.

How Certificate Authorities Work

Certificate authorities provide a number of well-known public keys that match highly protected private keys maintained by the certificate authority. These public keys also are included in digital certificates that can be found in all commercially available Web browsers.

A certificate authority uses its private key to sign certificates for the users that it validates. In a sense, it is vouching for every single one of those user's identities. Because the public keys of the certificate authorities are both well known and embedded in many applications, you can use them to verify the signature on the digital certificate.

Certificate Authorities and WebLogic Server

In the WebLogic Server, digital certificates and certificate authorities are used in conjunction with the SSL protocol. The SSL protocol relies on digital certificates for authenticating clients and servers.

Because each digital certificate maps to only one private key, each WebLogic Server instance has its own digital certificate. Clients connecting to WebLogic Server securely over the SSL protocol need to verify that they are connecting to the correct host. The host name entered on the digital certificate enables clients to verify that they are connecting to the intended machine.

This level of verification is required for sensitive online transactions, when customers want to do things like:

• Manage their bank accounts

• Make credit card purchases

• Manage their 401(k) program

Digital certificates help give customers peace of mind.

Commercial Certificate Authorities

Vendors such as VeriSign and Entrust are commercial certificate authorities. For a public deployment, such as an Internet e-commerce site, you must obtain a digital certificate for each WebLogic Server instance. BEA's documentation includes specific details on how to acquire digital certificates for your WebLogic Server deployment.

Notes on SSL Encryption

The SSL protocol aggregates several encryption technologies, including digital certificates, standard symmetric encryption, and public key encryption. For example, an SSL-protected data transfer connection uses all three technologies, as follows:

• First, the client requests the server's public key from the server's digital certificate.

• The client then uses that public key to encrypt a message for the server. The message contains the client information and bootstrap information for the SSL connection.

• Ultimately, the server and the client use each other's public keys to agree on a symmetric key, which they subsequently use to encrypt all the data they share.

SSL uses symmetric encryption once a secure connection has been verified because it is much more efficient from a computational standpoint. Public key encryption is very expensive in terms of CPU utilization. If you were to try to implement “bullet proof” security using public key encryption exclusively, your systems could grind to a halt while maintaining only a few simultaneous connections.

WebLogic Server SSL Usage Scenarios

WebLogic Server uses SSL in three ways:

One-Way and Two-Way Authentication

SSL uses digital certificates to authenticate both the client and the server. This mode is called two-way authentication. For two-way authentication, both the server and the client have a digital certificate from a certificate authority that both parties recognize. The server verifies the client's digital certificate while the client verifies the server's digital certificate. This provides mutual assurance that both the client and the server are whom they claim.

There is another option in the standard: The client can remain anonymous while the server is authenticated. This option is often called one-way authentication or server authentication. One-way authentication is the common mode for Internet deployments of WebLogic Server, where large-scale distribution of digital certificates is not practical. For example, imagine a bank trying to provide digital certificates to all of its customers. Most Internet deployments settle for password authentication of users in conjunction with digital certificates to authenticate servers to users.

In one-way authentication, a digital certificate provided by a certificate authority authenticates the server. The certificate authority (such as VeriSign) has its public key embedded in a digital certificate in the Web browser.