Weblogic wonders!!!

Webservice Security – WS-Trust and WS-SecureConversation an overview

Administrator — Fri, 03 Feb 2012 19:34:24 +0000

Webservices

“A Web Service is a system designed to support interoperable communication from machine to machine over a network. It includes an interface described in a machine-processable format (WSDL), and is typically conveyed using HTTP with XML serialization.”
Webservices exist in a wide range of architecture, technologies and software design. They provide an interaction mechanism between Business to Business applications. Webservices rely on SOAP Protocol for the interaction between the B2B applications. SOAP is and XML Based protocol that uses HTTP as its base transport protocol. Following is an example of a SOAP Request and SOAP Response

REQUEST

POST /SecureHelloWorldService/SecureHelloWorldService

HTTP/1.1 User-Agent: BEA WebLogic Server 10.3.0.0

Content-Type: text/xml; charset=utf-8 SOAPAction: “”

Host: 127.0.0.1:7000

Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Connection: keep-alive Content-Length: 187

World

RESPONSE

HTTP/1.1 200 OK Date: Tue, 24 Jan 2012 06:15:42 GMT

Transfer-Encoding: chunked

Content-Type: text/xml; charset=utf-8

SOAPAction: “” X-Powered-By: Servlet/2.5 JSP/2.1

xmlns:env=”http://schemas.xmlsoap.org/soap/envelope/”>

Hello World

Webservices Security

For a secure environment data exchange cannot happen in clear text as sensitive information might be exchanged. Also securing the communication channel for all communication is an overhead and might not be acceptable in all scenarios. Hence many specifications exist which allows to secure the data exchanged. One such framework is WS-Policy which defines how secure messages can be exchanged. To demonstrate this I have secured the above Webservice using standard policies and captured the SOAP Request and SOAP Response

@Policies({ @Policy(uri=”policy:Auth.xml”, direction=Policy.Direction.inbound), @Policy(uri=”policy:Sign.xml”), @Policy(uri=”policy:Encrypt.xml”)})

The message body is encrypted

T7MoCfhyDwXRjLrpRhZ62es3qK2jhTbY2ReS1ZSWhRaBidi8DwW5EbzNQKgudtPa8m7zxkW/ljebMV5dSvIZrJC1o+6peC111iFgPC4jMyA=

In addition to this, security tokens need to be passed for authentication and authorization purpose.

Username Password Token

weblogic

weblogic

Binary Security Token

MIICYTCCAgugAwIBAgIQsAtcv4jhs9Rpsu6m…..

…………………………………………………………………………………xuT69jAN

BgkqhkiG9w0BAQQFADB5MQswCQYDVQQGEwJVUzEQM

/wsse:BinarySecurityToken>

Following is the lists of supported tokens that can be used for authentication and authorization purposes

Lists of tokens (Table 1)

Table 1

Token Type	Description
User Name Token-Plain	Carries basic information (username and a clear text password or shared secret) for purposes of authenticating the user identity to the WSP. Communication is done in plain text so SSL over HTTPS transport must be used to protect the credentials.
Kerberos Token	Carries basic information (username and, optionally, a password or shared secret), in a Kerberos token, for purposes of authenticating the user identity to the WSP.
X.509 Token	Contains an X.509 formatted certificate for authentication using credentials created with a public key infrastructure (PKI). In this case, the WSC and WSP must trust each other’s public keys or share a common, trusted certificate authority.
SAML-Holder-Of-Key Token	Uses the SAML holder-of-key confirmation method whereby the WSC supplies a SAML assertion with public key information as the means for authenticating the requester to the web service provider. A second signature binds the assertion to the SOAP payload. Can use either SAML v1.x or SAML v2.
SAML-Sender Vouches Token	Uses the SAML sender-vouches confirmation method whereby the WSC adds a SAML assertion and a digital signature to a SOAP header. A sender certificate or public key is also provided with the signature. Can use either SAML v1.x or SAML v2.

Key Exchange using WS-Trust

In the model above it’s the responsibility of the server to validate the tokens, signatures and perform authentication and authorization. This again can be an overhead, especially if the numbers of clients are very high. Also if the client is not known to the Service, it becomes difficult to establish a trust with the client. To address this situation WS-Trust standard has been adopted. In this model, the responsibility of establishing the trust has been assigned to a third party. Clients request for a Security Token from a Secure Token Server (STS). Once they get the token, they present the token to the Service. The exchange mechanism and standard format of the token has been provided in WS-Trust specification. In my test, I used opensso (an open source STS Server) and captured the request-response interaction as depicted in Figure below.

1)Client requests for a Security token to a Secure Token Server

http://demo

…. wsse:SecurityContextToken wsse:ReqIssue http://localhost:7001//SecureHelloWorldService/SecureHelloWorldService

2)Secure Token Server provides the token to the Client.

….

…

3)Using the token, the service is invoked.

http://quoteservice

….

…

4)Response from the service

Hello World

References

1) Webservices Vulnerabilities, Security Compass Inc 2007
2) WS Trust Specification

http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf

3) WS Security Specification

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

4) Open SSO STS Solution

http://en.wikipedia.org/wiki/OpenSSO

http://www.oracle.com/technetwork/testcontent/opensso-091890.html

Converting certificate formats

Administrator — Wed, 25 Jan 2012 11:23:36 +0000

Converting Certificate from JKS to P12 Format

keytool -importkeystore -srckeystore Fabrizio.jks -destkeystore Fabrizio.p12 -srcstoretype JKS -deststoretype PKCS12 -srcstorepass weblogic1 -deststorepass weblogic1 -srcalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -destalias {4d390f81-7f7a-4a0a-ae76-9a5ea5ba567f} -srckeypass weblogic1 -destkeypass weblogic1

Converting certificate from PFX to JKS Format

java -classpath ./jetty-6.1.1.jar org.mortbay.jetty.security.PKCS12Import Fabrizio.pfx Fabrizio.jks

Converting certificate from P12 to PFX Format

1. Import the certificate in the browser using certificate import wiward by double clicking on the p12 certificate.
2. Go to Internet Options > Content > Certificates > Personal
3. Choose your certificate and click export.
4. Select Yes Export the Private Key
5. Select Personal Information Exchange Format and provide the password.
6. Store the file as .pfx.

Thread Dumps

anandraj — Wed, 05 Oct 2011 04:26:16 +0000

There could be scenarios like Server Hang, Crashes, Performance delays where you might need to capture Thread Dumps for further analysis.

Thread dumps provide a snapshot of the current active threads. It provides the stack trace of all the java threads in the JVM.

There are different ways to capture thread dumps; some are based on the operating systems.

On Windows:

Go to the server standard output and press a Control + Break and copy the thread dump onto a file

On UNIX/ Linux

Find the process id for your server

Ps –ef | grep java
Kill -3

WebLogic utilities to capture thread dumps

1. webLogic.Admin utility

a. Open a command prompt , set the classpath running /bin/setDomain.env

b. Execute the below command

java weblogic.Admin -url t3://localhost:7001 -username weblogic -password weblogic1 THREAD_DUMP

Note: Thread Dump will be printed to the servers standard out (by default, the shell in which the server is running).

2. Using Admin Console

a. Log into the Admin Console , click on the server

b. Click onto the Server –> Monitoring –> Threads

c. Click on the Dump Thread Stack

3. Using WLST (WebLogic Scripting Tool)

a. Save and execute the below snippet as ThreadDump.py

************************************

connect(‘weblogic’,'weblogic1′,’t3://localhost:7001′)

cd(‘Servers’)

cd(‘AdminServer’)

threadDump()

disconnect()

exit()

************************************

Note: The thread dumps get stored in the location from where you run the WLST script

If your Server is running as windows service, then follow the below steps

1. Open a command prompt and execute the below command

WL_HOME\bin\beasvc -dump -svcname:service-name

There are other tools that can be used to capture thread dumps for example jrcmd (for JRockit) ,Samurai etc.

NOTE: It is recommended to capture a set of 6-7 thread dumps at an interval 8-10 seconds to find a pattern in the thread execution.

Cheers,

Wonders Team

How and Why we need to SECURE our Web Server

Shiva Shankar — Tue, 26 Jul 2011 14:55:19 +0000

Introduction: Over the year’s internet and the internet based applications had revolutioned our life. They had created many new global business opportunities for enterprises conducting online business. However, the security risks associated with conducting e-business have resulted in security becoming a major factor for online success or failure.

Any high-profile hacking attack has proven that web security still remains a serious issue for any business that’s running its operations online. Web servers are one of the most targeted public faces of an organization, because of the sensitive data they usually host. Hence, securing web server is as important as securing the website or web application itself. If we have a secure web application and an insecure web server, or vice versa, it still puts business at a huge risk. Therefore, it is important for us to have a secured web server.

What is a Web Server?? A Web Server can be defined as an HTTP protocol dependant server used for re-direction of the client requests to the appropriate application servers. Following is the pictorial representation of the purpose of a web server:

*Security Implementation in Apache Web Server: Below is the schematic representation of the communication with a secured web server.

The security implementation inside the web server is implemented in two different steps:-

1) Installation of SSL Certificate

2) By following the security guide lines

Installation of certificate:- The installation of the SSL certificates for apache servers involves the following stages:

1. Create a Certificate Signing Request (CSR)
2. Apply online
3. Installing your Certificate
4. Displaying your Secure Site Seal

For a webserver generate a CSR and a private key, use the following command: openssl req -config openssl.cnf -new -out my-server.csr

2. Removes the pass phrase from the private key because it contains the entropy information for creating the key and could be used for cryptographic attacks against your private key using the command:

rsa -in privkey.pem -out my-server.key

3. Use the below command to generate the self signed certificate (later replace this with the certificate from Certifying Authority)

x509 -in my-server.csr -out my-server.cert -req -signkey my-server.key -days 365

4. Create an Apache/conf/ssl directory and move my-server.key and cert into it

5. Open the httpd.conf file and add the following lines:

LoadModule ssl_module modules/mod_ssl.so

6. Add the following to the end of httpd.conf:

        SSLMutex sem

        SSLRandomSeed startup builtin

        SSLSessionCache none

        SSLLog logs/SSL.log

        SSLLogLevel info

        SSLEngine On

        SSLCertificateFile conf/ssl/my-server.cert

        SSLCertificateKeyFile conf/ssl/my-server.key

Restart the Apache server and access the applications with the SSL mode.

Following are some of the tips and guidelines implementing, will help our apache servers to be more and more secured:-

1) Update the Apache Server with the latest security patched and fix pack. (stable version of Apache)

2) Hide the Apache Version number, and other sensitive information as below inside httpd.conf:

                       ServerSignature Off

                       ServerTokens Prod

Note: ServerSignature Off tells apache not to display the server version on error pages, or other pages it generates.

ServerTokens Prod tells apache to only return Apache in the Server header, returned on every page request.

3) Many at times the apache installation run as anonyms or root, make sure that the apache is running under its own user account and group. You can check this information in httpd.conf:

        User apache

        Group apache

4) Make sure that apache doesn’t use/access any of the files outside its web root directory (this is the location where we have all of apache files):

                 Order Deny,Allow

                 Deny from all

                 Options None

                 AllowOverride None

                 Order Allow,Deny

                 Allow from all

5) In typical operation, Apache is started by the root user. Set the right permissions on ServerRoot Directories as follows:

mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs

6) **Server Side Includes (SSI) presents an administrator with several potential security risks like increased load on the server, etc. Hence, turn off server side includes by Options directive inside a Directory tag inside the httpd.conf file. Set Options to either None or –Includes.

7) Allowing users to execute ***CGI scripts in any directory should only be considered if:

Ø You trust your users not to write scripts which will deliberately or accidentally expose your system to an attack.

Ø You consider security at your site to be so feeble in other areas, as to make one more potential hole irrelevant.

Ø You have no users, and nobody ever visits your server

8) Watch logs to keep up-to-date about what is actually going on against your server you have to check the Log Files. They will give you some understanding of what attacks is thrown against the server and allow you to check if the necessary level of security is present.

chown -R root:root /usr/local/apache

               chmod -R o-rwx /usr/local/apache

Note: /usr/local/apache is Apache installation directory

9) Lower the time out and restrict request body requests as follows:

               Timeout 45

               LimitRequestBody 1048576

10) Restrict the accessing of resource by using the IP restriction:

               Order Deny,Allow

               Deny from all

               Allow from 127.0.0.1

Note: **Server Side Include page is typically an HTML page with embedded command(s) that are executed by the Web server.

***CGI program is any program designed to accept and return data that confirms to the CGI specification. The program could be written in any programming language, including C, Perl, Java, or Visual Basic. CGI programs are the most common way for Web servers to interact dynamically with users

References:

1) http://httpd.apache.org/docs/2.0/misc/security_tips.html

2) http://www.google.com

3) http://www.modssl.org/docs/2.8/ssl_reference.html

All Server States using WLST

anandraj — Wed, 20 Jul 2011 06:26:53 +0000

This is an extension to my earlier post which gives the runtime attributes about the alive servers.

http://weblogic-wonders.com/weblogic/2011/03/16/weblogic-server-runtime-using-wlst/

However there could be scenarios where you might want to keep a track of all the server states like RUNNING, SHUTDOWN etc in the domain.

The below WLST script provides a list of all the servers in the domains and their respective server states. To check the servers which are in shutdown state.

Steps:-

1. Script to monitor all the Server States in the domain.

a. Save the below script AllServerStatus.py on to your local machine.

**************************************************************************

username = 'weblogic'

password = 'weblogic1'

URL='t3://localhost:7001'

connect(username,password,URL)

domainConfig()

serverList=cmo.getServers();

domainRuntime()

cd('/ServerLifeCycleRuntimes/')

for server in serverList:

name=server.getName()

cd(name)

serverState=cmo.getState()

if serverState=='SHUTDOWN':

print '**** Shutdown Servers ****'

print 'Server *****'+ name +'***** State *****'+serverState

break

print 'Server *****'+ name +'***** State *****'+serverState

cd('..')

**************************************************************************

2. Execute the WLST Script

a. Set the CLASSPATH by running the setDomainEnv script from the

Alternatively you can set the CLASSPATH by specifying the –cp argument while executing the WLST Script

For Ex: java –cp $BEA_HOME/wlserver_10.3/server/lib/weblogic.jar weblogic.WLST AllServerStatus.py

Downloads

You can download the WLST script from the below link.

serverStateAll.py

Note: Save the script as AllServerStatus.py

References:

http://download.oracle.com/docs/cd/E11035_01/wls100/config_scripting/monitoring.html

Regards,

Wonders Team.

Certificate Management in WebSphere Application Server

Shiva Shankar — Wed, 06 Jul 2011 18:41:48 +0000

Before, trying to understand about the certificate management, installation of certificates inside the WebSphere application server we should first understand why we need ssl communication and what is the impact of not installing the certificates.

During the olden days whenever we want to make any banking transaction (e.g.: depositing the money, with draw money, transfer money, etc), make a reservation for Air travel, etc… we used to visit the branches, stand in the queue and wait for our turn and complete the transaction. But, in present day with time constraint, busy world none of us wants to waste time being in queue. Thanks to the internet based applications which made every work possible with a finger click. But, always a question remains how about the security to these transactions on the internet??.

The JSSE (JAVA Secured Socket Extension) is a set of packages that enable secure Internet communications. It implements a Java technology version of Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It includes functionality for data encryption, server authentication, message integrity & optional client authentication.

SSL configuration: SSL configuration help us in making secured communication between the application deployed inside the websphere and external client (browser) by encapsulating the data as required by JSSE. These certificates inside the websphere are mainly of 2 different types. They are as follows:-

(a) Self Signed certificates ( or Internal or Default Certificates)

(b) Signer Certificates (or Digital Certificates)

Self Signed Certificates: From websphere application server 6.1 onwards the self signed certificates are created automatically during the profile creation .i.e., whenever the profile is federated to cell self signed certificated are created automatically. The management of these self signed certificates is automatically taken care. The expiration of these certificates is monitored on a pre-defined schedule with notifications sent to system logs and email-sending capabilities. The certificates will be automatically replaced before expiration, by default, and, there will of course be a warning prior to the certificate replacement.

Signer Certificates: A signer certificate represents certificate and public key associated with some personal certificate. The signer certificate explicitly trusts connections made to or by the owner of the associated personal certificate. The signer certificate is typically made completely public by the owner of the personal certificate, but it’s up to the receiving entity to determine if it is a trusted signer prior to adding it to the trust store.

Following are the steps involved for installing the SSL signer certificates:-

1) **Invoke the ikeyman from the profiles bin directory.

2) In the IBM Key Management Utility, click on Key Database File and then New

3) Choose Key database type and select JKS. Give any name to keystore like Test_key.jks.

4) Click the Browse button and give location where we want to store keystore file.

5) Click OK. Enter a password and click OK.

6) Click Create then New Certificate Request to bring up the Create New Key and Certificate Request window.

7) Type a Key Label, Common Name, Organization, Locality, State, and select a Country. Select 1024 for Key Size.

8) Click on Key Database File and then Open. Locate the keystore file that you created when you generated the CSR. Type the password and click OK.

9) Select Signer Certificates from the pull-down list.

10) Click the button to Add…

11) Login to WAS console with the valid credentials and Expand “Security” link at left hand side pane.

12) Click on “SSL certificate and key management”.

13) Click on “SSL configurations” link.

14) Click on “Key stores and certificates” link.

15) Select the scope by clicking on CellDefaultTrustStore (or NodeDefaultTrustStore) link from the list.

16) Click on “Signer certificates” link.

17) Click on Add button.

18) Give alias name as “Test_Cert”.

19) Give filename as complete path of “Test_Cert.cer” on server.

20) Click apply and then OK and restart all the WAS server instances.

Regards,

Weblogic-wonders Team

Installation of WAS Fix pack

Shiva Shankar — Wed, 06 Jul 2011 06:14:34 +0000

Steps to install the Fixpack:-
Following is the step-by-step approach for installing the fixpacks for WebSphere Application Server environment:-

(1) Take the back-up of the existing configuration. You run the below command to take the backup of the existing
configuration from the individual profiles-
(a) ./backupConfig.sh name_config.zip (unix)
(b) backupConfig.bat name_config.zip (windows)

(2) Download the update installer (for WAS6.1 use http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg24012718)

Note: While downloading the update installer make sure that the version of update installer is more than your websphere application server installation. Check the WAS version by running the below commands from appserver profiles bin folder) :

(a) ./versionInfo.sh (unix)

(b) versionInfo.bat (windows)

(3) Now, we can start the installation of fix pack to the existing WAS installation by using the following two different ways-
(a) Silent Mode — Generally, this mode is used for windows or UNIX based OS
(b) Graphical Mode — This mode is generally used for windows based OS

Graphical User Interface: Following are the steps for installation of fix packs using the GUI mode:-

(1) Download the required fix pack from the official IBM support Web site (http://www-01.ibm.com/support/docview.wss?rs=180&uid=swg27004980#ver61) in to temporary directory updi_root /maintenance directory.

(2) Make the current working directory: updi_root.

(3) Ensure that you stop all running processes. (we can use ps -ef|grep java and kill -9)

(4) Launch the Update Installer. For example:
(a) Windows – update.bat
(b) Windows Vista – update.exe
(c) AIX,HP-UX,Linux,Solaris – ./update.sh

(5) The Welcome panel will display. Click Next.

(6) The system will prompt for the location of the product that you want updated. Click Next.

(7) The system will present the choices of Install or Uninstall maintenance. The install option is the default. Click Next.

(8) The system will prompt for the maintenance location where packages can be found. Enter the directory name containing the packages, or browse for the required directory. Click Next.

(9) The following options exist for installing a fix pack:
(a) For installing the fix pack without the feature pack, select the desired fix pack. Click Next.
(b) For installing the fix pack with the feature pack, select the desired fix pack. Another panel is displayed that prompts you to install the enabling interim fix. Click Next.

(10) Before the installation, the Confirmation panel will confirm which packages will be installed.

(11) After the installation, the Summary panel will list which packages have been installed.

(12) After you install the fix pack, check the installation log to verify that the install was successful. The log can be found at app_server_root /logs/update/maintenance_package.install.

Note: (1) By any one of the following messages in the log file we can confirm the status of fix pack installation.
(a) INSTCONFSUCCESS – The operation was a success.
(b) INSTCONFPARTIALSUCCESS – The operation was partially successful, refer to the log for more details.
(c) INSTCONFFAILED – The operation failed, refer to the log for more details

(2)*** The update installer and WAS installation should be installed by using the same user id belonging to the group id.

regards,

weblogic-wonders team

BASIC Authentication in Websphere Application Server

Faisal — Fri, 01 Jul 2011 12:19:16 +0000

1 ) Secure the application resources using the descriptor (web.xml)

index.jsp

Constraint-0

Constraint-0
/*

pegaadmin

NONE

BASIC

pegaadmin

2) Deploy the application on Websphere Application Server.

3) Go to

Enterprise Applications > Test_Basic_war > Security role to user/group mapping

You will see the application role configured in the web.xml. Map the users to this role from WAS Console.

Step 4) Go to

Security> Secure administration, applications, and infrastructure and Check Enable application security.

Restart your Server.

Step 5) Access your application, you will be prompted for authentication.

Let us know if you face any issues.

Cheers!

Wonders Team

Analyzing WebSphere Thread Dump

Administrator — Wed, 25 May 2011 10:58:28 +0000

We can take thread dump on WAS using wsadmin tool in the following way.

D:\IBM\WebSphere\AppServer\profiles\ProcessCommander\bin>wsadmin.bat
WASX7209I: Connected to process “server1″ on node WKHANFXPNode02 using SOAP conn
ector; The type of process is: UnManagedProcess
WASX7029I: For help, enter: “$Help help”
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*]
WebSphere:name=JVM,process=server1,platform=proxy,node=WKHANFXPNode02,j2eeType=J
VM,J2EEServer=server1,version=6.1.0.0,type=JVM,mbeanIdentifier=JVM,cell=WKHANFXP
Node01Cell,spec=1.0
wsadmin>$AdminControl invoke $jvm dumpThreads

This will create a java core file in the following directory

D:\IBM\WebSphere\AppServer\profiles\ProcessCommander

javacore.20110511.174141.9628.txt

We need to download IBM Thread Dump Analyzer from here

Start the tool using the following command

E:\tools\jca412>java -Xmx515m -jar jca412.jar

Open the thread dump from

File > Open Thread Dumps

Then click on Analysis > Thread Details.

This will give you details of all the threads.

SSL configuration for WebLogic Server

anandraj — Wed, 25 May 2011 10:49:41 +0000

These days the enterprise applications have grown more complex and boast a great deal of sensitive and critical data online. Cyber security has become more than important these days to secure the data.

Secure Sockets Layer plays a pivotal role in how a sensitive data can be protected, accessed over a network.

Secure Sockets Layer (SSL) provides secure connections by allowing two applications connecting over a network connection to authenticate the other’s identity and by encrypting the data exchanged between the applications. Authentication allows a server and optionally a client to verify the identity of the application on the other end of a network connection. Encryption makes data transmitted over the network intelligible only to the intended recipient.

It provides transport level security by usage of the SSL certificates which are provided by the Industry standard Certificate Authorities like Verisign, GeoTrust, GoDaddy etc.

WebLogic Server supports SSL on a dedicated listen port which defaults to 7002. To establish an SSL connection, a Web browser connects to WebLogic Server by supplying the SSL listen port and the HTTPs protocol in the connection URL, for example, https://myserver:7002.

The below post describes the complete procedure about procuring the certificate, installing and configuring the certificate to the WebLogic Server.

1: Generating and procuring the certificate:

a: Open a command prompt and set the environment by running the setDomainEnv script.

b: Generate the private – public key pair. For demonstration we would use keytool java utility to do so. However we can use other utilities like openssl etc.

keytool -genkey -alias client -keyalg RSA -keysize 2048 -keystore identity.jks -storepass password -keypass password

c: Generate a Certificate Signing Request (CSR) and send it to Certifying Authority.

keytool -certreq -keyalg RSA -keysize 2048 -alias client -file certreq.csr -keystore identity.jks -storepass password

The CA would return with the certificate reply and the RootCA and sometimes an intermediateCA certificate.

d: Import the certificates into the keystore, this can be done in two ways either by importing the certificates in an order of RootCA, intermediateCA and then Certificate reply. Or we can create a certificate chain clubbing them in an order into a .pem file.

For demo, we would create a certificate chain file CertChain.pem and import it into the identity keystore overriding the private key alias which is client in this example.

keytool -import -file CertChain.pem -alias client -keystore identity.jks -storepass password

e: Create a trust keystore, this can be done my importing your RootCA certificate into another keystore that constitutes the trust.

keytool -import -file rootCA.cer -alias RootCA -keystore trust.jks -storepass password

To verify the contents of the keystore, you can use the below command,

Keytool –list –v –keystore -storepass

2: Configuring the keystore on the WebLogic Server.

a: Log into the Admin Console, select the server on which you want to configure the SSL certificate.

Server –> Click on the Keystore tab. By default it points to the Demo Certificates.

From the dropdown list select the “Custom Identity and Custom Trust” option.

Enter the identity and trust keystore details.

b: Configure the identity of the server:

Click on the SSL tab and enter the alias of the private key i.e. client in this case and the keypass password.

NOTE: If you enable the SSL for a WebLogic Server, by default it would be One Way SSL. If you want to change to Two Way SSL, you would require to select the two way SSL behavior from the Advanced option list.

c: Configure the SSL port.

By default it would be 7002.

Go to server –> General tab –> Specify and enable SSL port.

You can see the below messages in the server logs which indicate that the certificates are loaded.

3: Test the setup:

You can test the setup by accessing the admin console (if SSL is configured for Admin Server) or any application deployed on the server by accessing it on https protocol.

https://localhost:7002/console

Now verify whether the right certificate is configured or not.

Click on the certificate details and you would find the details about the identity and the RootCA along with the certificate chain.

NOTE: For a production environment make sure that CN (Common Name) of the certificate matches with the server host name.

You can also use self signed certificates or trial certificates for testing purpose. However is it not recommended to use them in production environment.

You can get the Verisign trail certificates from the below link.

http://www.verisign.com/ssl/free-30day-trial/

For further reading :

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/secmanage/ssl.html

Regards,

Wonders Team