Understanding SSL

For understanding SSL , first thing to understand is Digital Certificate.

Digitally signed CA certificate

Below is the key point which define a digitally signed certificate-
It is standard for verifying a client ,server or any third party.

It has following 4 key elements -
1. Organizational information
This section of the certificate contains information that uniquely identifies the owner of the certificate, such as organizational name and address. You supply this information when you generate a certificate using a certificate management utility.
2. Public key
The receiver of the certificate uses the public key to decipher encrypted text sent by the certificate owner to verify its identity. A public key has a corresponding private key that encrypts the text.
3. Certificate authority's distinguished name
The issuer of the certificate identifies itself with this information.
4. Digital signature
The issuer of the certificate signs it with a digital signature to verify its authenticity. This signature is compared to the signature on the corresponding CA certificate to verify that the certificate originated from a trusted certificate authority.

SSL
SSL is a process used for authenticating a caller using digitally signed certificate .The cert can be signed by third party CA authority or self signed using utility tools.
One-Way SSL
One way SSL is used by clients to authenticate the server
The service provider i.e. the server shares its digital certificate with the client and client store it in its truststore.
Truststore keystore is the certificate repository where the server/client stores all the thirdparty certificates. 
Identity keystore is the certificate repository where server/client store its own certificate
Before the actual message is transmitted the handshake needs to be done and establish the connection successfully.
Client has the servers public key ( contained in the certificate that server shared).
One important point to remember is that there is unique private-public key pair which the server has.Public key is present in the certificate and shared with the client .Private key is kept secret.Any message encrypted using a private key can be decrypted only with its unique public key .

Below are the steps to establish connection in case of One way SSL -

1. Client requests for a protected resource from the server.
2. Server sends it's certificate to the client
3. Client validates the digital signature in the received certificate against the digital signature present in the certificate which the client already has in its trust store. If the digital signature match that means the digital certificate is generated from valid CA authority and has not been tampered in between.
4.Client request the server to prove server's identity (ownership).
5. So the server sends back message encrypted using servers private key .  
6. Client validates the servers identity using servers public key which was sent as part of digital certificate.
7.On successful validation a handshake is done and connection is established between client and the server.
8. Server sends the requested resource to the client.

This is one way SSL and in case of 2 way SSL ,the server also validates the client similarly.

2 Way SSL implementation in weblogic server

1) Just about everyone who writes about it assumes you're setting it up for real and skips over the details if you don't want to get involved with a signing authority like Verisign - or, like the article above, you're using a test CA that has already been set up.

2) You have to simulate all the parts - including the bits the Verisigns and Thawtes usually take care of.
So to try to do the noble thing and save one or two of you that may be tortured with the same task, I am going to reveal the secrets of setting up Two-Way SSL using Java and Weblogic Tools using a Self-Signed CA certificate for development environments.

The tools we need for the job are:
Java keytool
BEA's modifed keytool: ImportPrivateKey
BEA's CertGen - Certificate Generator

Note: Before you start, run setDomainEnv in the bin directory of your server domain.
e.g. on Windows:
path_to_bea\user_projects\domains\my_domain\bin\setDomainEnv.cmd
1. Use CertGen to Generate Server Private Key and Certificate

What we need at the outset is for everyone to trust us. We're all going to trust each other here because I say so. That's what the selfsigned switch is all about. In the real world, we trust each other because we mutually trust a Certificate Authority (CA) like Verisign. Here we're saying "I am the CA".
java utils.
CertGen -selfsigned -certfile MyOwnSelfCA.cer -keyfile MyOwnSelfKey.key -keyfilepass mykeypass -cn "My Own Self CA"
You should see this response in the command window:
Generating a self signed certificate with common name My Own Self CA and key strength 1024

2. Create the Identity Keystore

CertGen created a unique and secret Private Key for the server we're using and the Self-signed Root Certificate for us. But Java wants them packaged up neatly into a keystore.

The one thing Java keytool doesn't do is import a ready-made private key...

Drat!

Fortunately BEA are a smart bunch and created a utility to help.
And just to make sure there was no confusion about what it does, they called it ImportPrivateKey.
Told you they were smart, didn't I?
Now run this:

java utils.ImportPrivateKey -keystore MyOwnIdentityStore.jks -storepass identitypass -keypass keypassword -alias trustself -certfile MyOwnSelfCA.cer.pem -keyfile MyOwnSelfKey.key.pem -keyfilepass mykeypass
Imported private key MyOwnSelfKey.key.pem and certificate MyOwnSelfCA.cer.pem
into a new keystore MyOwnIdentityStore.jks of type jks under alias trustself

3. Import the Certificate into a new Trust keystore
If you read the Monduke article from above, you'll know the name of the game is trust.
When the client asks the server for a connection, the server will only allow access if it trusts the signer of the client's certificate. This is going to be the "My Own Self CA" and to make it happen we need our trusty MyOwnSelf certificate packed up into a separate keystore called the Trust Keystore. When the client presents it's certificate, this is where the server will look to see if it trusts the signature of the CA.

keytool -import -trustcacerts -alias trustself -keystore TrustMyOwnSelf.jks -file MyOwnSelfCA.cer.der -keyalg RSA(Replace with equivilent ImportPrivateKey command?)
Here's the tool's response:
Enter keystore password: trustpass
Owner: CN=My Own Self CA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=My
State, C=US
Issuer: CN=My Own Self CA, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=M
yState, C=US
Serial number: ...

Trust this certificate? [no]: yes

Certificate was added to keystore

4. Configure WLS with Identity and Trust stores
Now we have an Identity Keystore for Server to Client communication (to supply certificates to the client) and a Trust Keystore for Client to Server communication (to accept certificates supplied by the client). We now need to tell Weblogic to use them.
In the Weblogic Admin Console jump to the Keystores page and choose "Custom Identity and Custom Trust"
Enter the locations of your Identity and Trust keystores, the passphrases identitypass and trustpass respectively, along with the alias in the SSL tab (I used 'trustself' above). The Private Key password in this example is 'keypassword'.
When you've saved and activated your changes in the admin console, check the Weblogic command output window to verify that your Identity and Trust keystores were loaded with no problems.

5. Test One Way SSL
Under the SSL tab, make sure Two Way Client Cert Behavior is set to "Client Certificates Not Requested".
This is important - make sure you have these entries in your config.xml file in the config directory of your domain:
false
false
trustself
If any are different, edit and save the config.xml to match, and then restart the Weblogic server.
Now browse to https://localhost:7002/console
(Assuming defaults.)
All being well, the server should present the client with a certificate.

However, the client has no reason to trust our Self-Signed Certificate yet, so it will throw up a dialog. (Also the name doesn't match that of the server. This isn't too important in a development environment - but something you'd definitely fix for production.)

6. Install the Server Certificate on the Client

To have the client trust the server permanently, we need to Install the certificate. Hit install and follow the instructions. When you next go into the Certificate Management screen you will see the "My Own Self CA" listed under "Trusted Root Certification Authorities"

7. Test Two Way SSL without Client Certs required
Now go into the WLS Admin Console and switch the
Take a look at the WebLogic server console output:
NO_CERTIFICATE

The only way we got to the page was because we set Weblogic to ignore the fact that there was no client certificate. For truly secure Two-Way SSL where only authorized clients can talk to our server, we need to put a certificate on the client to send and require that the server check it.

8. Create a client certificate using the Self-certified CA certificate
Now we basically need to set up the opposite situation on the client that we did on the server. But, of course, there are some crucial differences. Wouldn't be any fun otherwise...

It's time to generate the certificate for the client. This time we want the Certificate to identify the client machine (usually the user of the machine - you can set up one client certificate per user and have more than one on a machine if you need to), AND we want to ensure that the Client is linked to the Trusted CA Root Certificate we fabricated earlier. (This is why the ou (operating unit) of the client certificate must match the identity of the Trusted CA Certificate - in this case "My Own Self CA".)

java utils.CertGen -certfile MyClientCert.cer -keyfile MyClientKey.key -keyfilepass clientkeypass -cacert MyOwnSelfCA.cer.der -cakey MyOwnSelfKey.key.der -cakeypass mykeypass -cn "My Client" -e "my.own@self.com" -ou "My Own Self CA"

Generating a certificate with common name Client User and key strength 1024 issued by CA with certificate from MyOwnSelfCA.cer.der file and key from MyOwnSelfKey.key.der file

9. Bundle up the Certificate and Key into a Format the Browser will like (it's PKCS12 if you have to know)

Having the client certificate in bits won't be much appreciated by the browser, so we need to package it up - like a identity keystore, but in a different format that browsers like.

java utils.ImportPrivateKey -keystore MyClientCert.p12 -storepass clientpass -storetype pkcs12 -keypass clientkeypass -alias clientcert -certfile MyClientCert.cer.pem -keyfile MyClientKey.key.pem -keyfilepass clientkeypass

10. Import Trusted CA Certificate and Client Certificate into BrowserThere are essentially two pieces to the pie. First you need to import the Root CA Certificate so the browser trusts certificates sent from the server.Locate the MyOwnSelfCA.cer.der file that was made in the very first step, and import it into your browser as a Trusted Root Certification Authority (Tools > Options > Content > Certificates in IE)If using IE doesn't make you go weak at the knees, the easiest thing to do now is double-click the certificate file you just made. (MyClientCert.p12) IE will launch it's import certificate wizard and you'll be ready to roll.

If you want to make life hard for yourself, then I'll assume you know how to import client certificates in your favourite browser and move on...

11. Test Two-Way SSL

The moment of truth:

Browse to https://localhost:7002/console

This is what should happen:

Client request to server

Server response - sends certificate signed by "My Own Self CA" and requests a certificate from the client

Client examines certificate - decides to Trust it since it has the CA certificate for "My Own Self CA"

Client sends its certificate to the server, again signed by "My Own Self CA"

Server finds up "My Own Self CA" in its Trust store and decides to trust the client

Server sends requested resource back to the client in encrypted form

Client deciphers the encryption and displays the result - in this case the Weblogic Admin Console login page.