OC4J supports Secure Socket Layer (SSL) communication between Oracle
HTTP Server and OC4J in an Oracle Application Server environment, using
secure AJP. This is the secure version of Apache JServ Protocol, the protocol
that Oracle HTTP Server uses to communicate with OC4J.
This tutorial focuses on:
- Overview of SSL Keys and Certificates
- Using Keys and Certificates with OC4J and Oracle HTTP Server
- Enabling SSL in OC4J
- Requesting Client Authentication
- Resolving Common SSL Problems
Overview of SSL Keys and Certificates
In SSL communication between two entities, such as companies or
individuals, the server has a public key and an associated private key.
Each key is a number, with the private key of an entity being kept secret
by that entity, and the public key of an entity being publicized to any other
parties with which secure communication might be necessary.
The security of the data exchanged is guaranteed by keeping the private
key secret, and by the complex encryption algorithm. This system is
known as asymmetric encryption, because the key used to encrypt data is
not the same as the key used to decrypt data.
Asymmetric encryption has a performance cost due to its complexity. A
much faster system is symmetric encryption, where the same key is used
to encrypt and decrypt data. But the weakness of symmetric encryption is
that the same key has to be known by both parties, and if anyone
intercepts the exchange of the key, then the communication becomes
insecure.
SSL uses both asymmetric and symmetric encryption to communicate. An
asymmetric key (PKI public key) is used to encode a symmetric encryption
key (the bulk encryption key); the bulk encryption key is then used to
encrypt subsequent communication. After both sides agree on the bulk
encryption key, faster communication is possible without losing security
and reliability.
When an SSL session is negotiated, the following steps take place:
1. The server sends the client its public key.
2. The client creates a bulk encryption key, often a 128 bit RC4 key, using a specified encryption suite.
3. The client encrypts the bulk key with the server's public key, and sends the encrypted bulk key to the
server.
4. The server decrypts the bulk encryption key using the server's private key.
5. This set of operations is called key exchange. After key exchange has taken place, the client and the
server use the bulk encryption key to encrypt all exchanged data.
- In SSL the public key of the server is sent to the client in a data structure
known as an X.509 certificate. This certificate, created by a certificate
authority (CA), contains, a public key, information concerning the owner of
the certificate, and optionally some digital rights of the owner. Certificates
are digitally signed by the CA, which created them using that CA's digital
certificate public key.
- In SSL, the CA's signature is checked by the receiving process to ensure
that it is on the approved list of CA signatures. This check is sometimes
performed by analysis of certificate chains. This occurs if the receiving
process does not have the signing CA's public key on the approved list. In
that case the receiving process checks to see if the signer of the CA's
certificate is on the approved list or the signer of the signer, and so on.
This chain of certificate, signer of certificate, signer of signer of certificate,
and so on is a certificate chain. The highest certificate in the chain (the
original signer) is called the root certificate of the certificate chain.
- The root certificate is often on the approved list of the receiving process.
Certificates in the approve list are called trust points or trusted certificates.
A root certificate can be signed by a CA or can be self-signed, meaning
that the digital signature that verifies the root certificate is encrypted
through the private key that corresponds with the public key that the
certificate contains, rather than through the private key of a higher CA.
(Note that certificates of the CAs themselves are always self-signed.)
