Thursday Oct 18, 2012

How to Convert a PFX Certificate into a JKS Certificate to configure it on WebLogic

To convert a pfx cert file to a jks file, please follow these instructions:

1. Set up the environment for the domain, by executing the script, typically located at $DOMAIN_HOME/bin.

$ . ./

2. Use OpenSSL to check the pfx certificate's content.
$ openssl pkcs12 -in <certificate.pfx> -out KEYSTORE.pem -nodes

At this point, a password for the pfx file will be requested.

Expected output:

$ openssl pkcs12 -in <certificate.pfx> -out KEYSTORE.pem -nodes
Enter Import Password:
MAC verified OK

3. Open KEYSTORE.pem file, from step 2. This should look similar to this:You will find three certificates on it and the private key:

Bag Attributes
Microsoft Local Key set: <No Values>
localKeyID: 01 00 00 00
friendlyName: le-36c42c6e-ec49-413c-891e-591f7e3dd306
Microsoft CSP Name: Microsoft RSA SChannel Cryptographic Provider
Key Attributes
X509v3 Key Usage: 10
Bag Attributes
localKeyID: 01 00 00 00
friendlyName: *
subject=/serialNumber=sj6QjpTjKcpQGZ9QqWO-pFvsakS1t8MV/C=US/ST=Missouri/L=CHESTERFIELD/O=Oracle_Corp, Inc./OU=Oracle/CN=*
issuer=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA

Bag Attributes
friendlyName: GeoTrust Global CA
subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
Bag Attributes: <Empty Attributes>
subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

4. Identify and store contents from KEYSTORE.pem certificate, to proceed and create jks files:

At this point, you will find three certificates on KEYSTORE.pem and the private key.

4.1 Private Key.

To identify the private key, look for the following headings:


Both above mentioned tags will be surrounded the private key. Go ahead and save the content of it into a file called: my_key_pk.pem. This has to include the headings.

Expected file:


4.2 Root Certificate.

To identify the Root Certificate, look for the following headings:

subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

Subject and issuer must be the same. Go ahead and save the content of it into a file called: my_key_root.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

4.3 Intermediate Certificate.

To identify an Intermediate Certificate, look for the following heading:

subject=/C=US/O=GeoTrust, Inc./CN=GeoTrust SSL CA
issuer=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA

 Subject and issuer are different only on the CN. Go ahead and save the content of it into a file called: my_key_intermediate.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

NOTE: This certificate is optional and there are some cases where it'll not be present. If this is the case, go ahead and skip this step. In any other case, this needs to be added to the identity keystore jks file.

4.4 Server Certificate.

 To identify a Server Certificate, look for the following heading:

subject=/serialNumber=sj6QjpTjKcpQGZ9QqWO-pFvsakS1t8MV/C=US/ST=Missouri/L=CHESTERFIELD/O=Oracle_Corp, Inc./OU=Oracle/

        A server certificate includes a heading called Friendly Name. Go ahead and save the content of it into a file called: my_key_crt.pem. Include all the content from BEGIN CERTIFICATE TO END CERTIFICATE, both included.

5. Create a Trust Keystore and import the Root certificate into it.

$ keytool -import -trustcacerts -file my_key_root.pem -alias my_key_root -keystore my_key_trust.jks -storepass <store_pass> -keypass <key_pass>

Expected Output:
Certificate already exists in system-wide CA keystore under alias <geotrustglobalca>
Do you still want to add it to your own keystore? [no]: yes
Certificate was added to keystore

6. Generate an Identity Keystore and import Server into it.

$java utils.ImportPrivateKey -keystore my_key_identity.jks -storepass <store_pass> -storetype JKS -keypass <key_pass> -alias server_identity -certfile my_key_crt.pem -keyfile my_key_pk.pem -keyfilepass <pfx_password>

With these instructions, two jks files will be produced:

  • my_key_identity.jks
  • my_key_trust.jks

With both files, the next step is to configure Custom Identity and Custom Trust on WebLogic Server.

Apply a BSU patch manually in Off-line Mode

To apply patch or patches in Off-line mode.

Note that you will need at least the patch-catalog.xml and one patch jar file.

BSU Patch Installation Off-line Mode
Apply patch or patches in Off-line mode
Note: To apply the patch in offline mode refer to the section 8 Using the Command-Line Interface of Using the Command-Line Interface guide available
here -


1. Make sure you have the following files inside Folder WLS_ORACLE_HOME/utils/bsu/cache_dir
- patch-catalog.xml
- XXXX.jar

Note that XXXX is the patch ID, is just a reference name.

2. Apply the patch by running the following command:

> cd WLS_ORACLE_HOME/utils/bsu/

> ./ -prod_dir=WLS_ORACLE_HOME/wlserver_10.3 -patchlist=<Patch_Id> -verbose -install

For example:

> ./ -prod_dir=/Oracle/Middleware/wlserver_10.3 -patchlist=XXXX -verbose -install

After this the patch should be applied successfully.

3. You can view the report of applied patches by running the following command:

> ./ -report -patch_id_mask=<Patch_Id>

For example:

> ./ -report -patch_id_mask=XXXX

4. Restart the server and watch the standard output logs to verify the installation.

5. If you have more patches to apply go to step 1.
6. Repeat the process on each Instance Server including the admin Server.

WebLogic Server: Where to Download the Type 4 JDBC Driver For Microsoft SQL Server.

The Type 4 JDBC driver for Microsoft SQL Server can be downloaded from the following Microsoft Download Center site:

Obtaining the correct Client IP address when a Physical Load Balancer and a Web Server Configured With Proxy Plug-in Are Between The Client And Weblogic

Some Load Balancers like Big-IP have build in interoperability with Weblogic Cluster, this means they know how Weblogic understand a header named 'WL-Proxy-Client-IP' to identify the original client ip.

The problem comes when you have a Web Server configured with weblogic plug-in between the Load Balancer and the back-end weblogic servers - WL-Proxy-Client-IP this is not designed to go to Web server proxy plug-in. The plug-in will not use a WL-Proxy-Client-IP header that came in from the previous hop (which is this case is the Physical Load Balancer but could be anything), in order to prevent IP spoofing, therefore the plug-in won't pass on what Load Balancer has set for it.

So unfortunately under this Architecture the header will be useless.

To get the client IP from Weblogic you need to configure extended log format and create a custom field that gets the appropriate header containing the IP of the client.

On WLS versions prior to 10.3.3 use these instructions:

You can also create user-defined fields for inclusion in an HTTP access log file that uses the extended log format. To create a custom field you identify the field in the ELF log file using the Fields directive and then you create a matching Java class that generates the desired output. You can create a separate Java class for each field, or the Java class can output multiple fields. For a sample of the Java source for such a class, see

Java Class for Creating a Custom ELF Field to

import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;

/* This example outputs the X-Forwarded-For field into a
custom field called MyOriginalClientIPField

public class MyOriginalClientIPField implements CustomELFLogger{
 public void logField(HttpAccountingInfo metrics,
  FormatStringBuffer buff) {

In this case we are using 'X-Forwarded-For' but it could be changed for the header that contains the data you need to use.

Compile the class, jar it, and prepend it to the classpath.

In order to compile and package the class:

1. Navigate to <WLS_HOME>/user_projects/domains/<SOME_DOMAIN>/bin
2. Set up an environment by executing: $ . ./ This will include weblogic.jar into classpath, in order to use any of the libraries included under package weblogic.*
3. Compile the class by copying the content of the code above and naming the file as:

4. Run javac to compile the class.


5. Package the compiled class into a jar file by executing:

$jar cvf0 MyOriginalClientIPField.jar MyOriginalClientIPField.class

Expected output is:

added manifest
adding: MyOriginalClientIPField.class(in = 711) (out= 711)(stored 0%)

6. This will produce a file called:


This way you will be able to get the real client IP when the request is passing through a Load Balancer and a Web server before reaching WLS.

Since 10.3.3 it is possible to configure a specific header that WLS will check when getRemoteAddr is called. That can be set on the WebServer Mbean. In this case, set that to be X-Forwarded-For header coming from Load Balancer as well.

Create a Self Signed Sertificate on WLS 10.3.5 Supporting SHA 256 Algorthim.

1) Set domain to call the keytool


2) Generate the key

$ keytool -genkey -alias selfsignedcert -keyalg RSA -sigalg SHA256withRSA -keypass privatepassword -keystore identity.jks -storepass password -validity 365

What is your first and last name?
What is the name of your organizational unit?
[Unknown]: a
What is the name of your organization?
[Unknown]: e
What is the name of your City or Locality?
[Unknown]: i
What is the name of your State or Province?
[Unknown]: o
What is the two-letter country code for this unit?
[Unknown]: U
Is CN=, OU=a, O=e, L=i, ST=o, C=U correct?
[no]: yes

3) Export the root certificate

$ keytool -export -alias selfsignedcert -sigalg SHA256withRSA -file root.cer -keystore identity.jks
Enter keystore password:
Certificate stored in file <root.cer>

4) Import the root certificate to the trust store

$ keytool -import -alias selfsignedcert -sigalg SHA256withRSA -trustcacerts -file root.cer -keystore trust.jks
Enter keystore password:
Re-enter new password:
Owner: CN=, OU=a, O=e, L=i, ST=o, C=U
Issuer: CN=, OU=a, O=e, L=i, ST=o, C=U
Serial number: 4f17459a
Valid from: Wed Jan 16 15:33:22CLST 2012 until: Thu Jan 15 15:33:22 CLST 2013
Certificate fingerprints:
MD5: 7F:08:FA:DE:CD:D5:C3:D3:83:ED:B8:4F:F2:DA:4E:A1
SHA1: 87:E4:7C:B8:D7:1A:90:53:FE:1B:70:B6:32:22:5B:83:29:81:53:4B
Signature algorithm name: SHA256withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore

5) To check the contents of the keystore

keytool -v -list -keystore identity.jks
Enter keystore password:

***************** WARNING WARNING WARNING *****************
* The integrity of the information stored in your keystore *
* has NOT been verified! In order to verify its integrity, *
* you must provide your keystore password. *
***************** WARNING WARNING WARNING *****************

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

Alias name: selfsignedcert
Creation date: Jan 18, 2012
Entry type: PrivateKeyEntry
Certificate chain length: 1
Owner: CN=example, OU=a, O=e, L=i, ST=o, C=U
Issuer: CN=, OU=a, O=e, L=i, ST=o, C=U
Serial number: 4f17459a
Valid from: Wed Jan 16 15:42:16CLST 2012 until: Thu Jan 15 15:42:16 CLST 2013
Certificate fingerprints:
MD5: 7F:08:FA:DE:CD:D5:C3:D3:83:ED:B8:4F:F2:DA:4E:A1
SHA1: 87:E4:7C:B8:D7:1A:90:53:FE:1B:70:B6:32:22:5B:83:29:81:53:4B
Signature algorithm name: SHA256withRSA
Version: 3


6) In some cases, this parameter is needed in the server start up parameters.


Otherwise, enable it from the Server configuration -> SSL -> Use JSSE checkbox.

Migrating a WebLogic Domain from a 32 to a 64 bit JVM/Architecture

Currently on 32 bit OS which presents a physical constraint when trying to allocate memory.

By limit, a 32 bit OS, will not be able to allocate more than 3 GB on a Linux environment, or 2 GB for Windows environment (not considering Physical Address Extension (PAE) implementation, which can increase the maximum allocatable memory).

When this limit is reached, a migration to a 64 bit architecture is recommended.

Below are the steps on how to install a 64 WebLogic Server version, along with a 64 Bit JVM and then how to migrate the domain to this new environment.

Weblogic Server Version: WebLogic Server Version:
OS: Linux 2.6.18-194.el5 #1 SMP Mon Jan 01 22:10:29 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
JVM:java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Oracle JRockit(R) (build R28.1.1-13-139783-1.6.0_22-20101206-0136-linux-x86_64, compiled mode)

To create migration template:

1. Execute $<WLS_HOME>/wlserver_10.3/common/bin/
2. Create Domain Template.
3. Select Domain to migrate.
4. Enter the name of template and other info. Click next.
5. Using Add Button, Select libraries you want to add under lib folder. copy jdbc data sources you would like to have under config/jdbc folder. If you want to have log4j configuration, copy log4j.xml under domain_root folder.
6. Select data base for the domain and click next.
7. Enter Admin Server Name and port numbers. Click next.
8. Enter username and password. Click next. Select No if you don want to add users/groups/roles
9. Click next until reach button create.

This will create a jar file that is needed for the next action plan.

To install and migrate domain to 64 bit architecture.

1. Install JVM Jrockit R28.1.1.13 on environment. (uncompress zip folder on a known location)
2. Go to JRockit_Home/bin and execute $ java -d64 -jar wls1034_generic.jar
3. When prompt, select JRockit JVM in browse menu, and wait for installation to finish.
4. Go to <WLS_HOME>/wlserver_10.3/common/bin and execute $ ./
5. Select Create a new Weblogic domain
6. Select Base this domain on an existing template and select browse.
7. Select jar file created on previous action plan.
8. Select Name of domain. Maintain in most cases.
9. Select user name and password. Maintain in most cases.
10. Select Jrockit SDK 1.6.0_22 and click next.
11. Confirm all JMS/JDBC/security configuration.
12. On select Optional Configuration, reconfigure if necessary.
13. Check on Configuration summary for all domain configuration.
14. Click on create, to finish up domain import.

Note: Always when installing a 64 bit WLS, it's necessary to install first the 64 JVM and then run the generic installer with the -d64 bit option. If this is not performed, the installation will be the 32 default version.

For more information, please refer:

Change the Log Level of Node Manager.

This is useful to troubleshoot issues related to Node Manager, such as problems starting a Managed Server or reasons a server could be (re)started.

To change the Log Level of Node Manager, you need to edit the file. This is usually located at:


What you need to modify is property:


Information about the appropriate values for this property is available in the Node Manager Documentation at 10.3 WebLogic Documentation (and in further releases) which states:


Severity level of logging used for the Node Manager log. Node Manager uses the same logging levels as WebLogic Server.

Default value: INFO

However, this is incorrect. WLS has its own implementation of LogLevel, but Node Manager uses the standard Log Level from the java.util.logging.Level class. Therefore, the possible values for Node Manager LogLevel, in descending order are:

  • SEVERE (highest value)
  • INFO
  • FINE
  • FINEST (lowest value)

The highest value provides only messages at the severe level. The warning level provides warning messages and severe messages, and so on. Besides those levels, ALL and OFF are also accepted.

For example, if you only want Severe messages to be logged, select SEVERE. If you need the most detailed tracing available, select FINEST.

For more information on what it will log at each level, please read the Java SE API for LoggingLevel.


Antonio De Juan Image

I was formerly a Senior Technical Support Engineer in the Middleware Application Server Team. I worked supporting Weblogic Server, Java EE, Jrockit, Coherence among other Oracle products.
You can find my new blog at :
Oracle WebLogic


« October 2012