Monday, February 7, 2011

OC4J Support for Secured Socket Layer

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

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 
    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.)

ForgeRock: Open AM. Install Open AM 5.5 with Tomcat 8.0 - Part 1- Install Tomcat

This BLOG thread discusses on steps to install and configure Open AM 5.5 with Tomcat 8.0. Install Tomcat. You can always find the l...