Category Archives: Uncategorized

Keytool and foreign locale problems

Posted on by
Reply

Recently, we hit upon an very interesting(!?!) problem using Keytool inside our application.

We have a customer in Thailand who complained that the self-signed certificates generated in our application(which in turns uses Keytool) have got the Certificate “Valid From” Date and “Valid To” dates completely wrong.

The catch here is that Thai Calendar Year is 543 years ahead of the Julian Calendar. In other words, year 2006 in English Calendar is equivalent to year 2549 in Thailand Calendar.

Lets say I generate a self-signed certificate using Keytool with my machine running on Thai Locale, the Year portion of “Valid From” should be stamped as 2549(2006 is the current year + 543).

And if the validity of the certificate is 3 years, then the Year of Expiry is 2552.

But, Keytool just ignores this whole difference in the Calendars and lives with the all famous Y2K Bug!!!

The Certificate would show as Valid from 2049 to 1952!!! Howzzat???

Any amount of googling thru the java sun forums and other newsgroups, I could not find anything that talks about this problem/behavior.

Am I missing something big here??? Hope some one some day will help me resolve this mystery!

I am giving the exact keytool syntax I used for easy reference for anyone who would like to try this out 🙂

1. Generate Self Signed Certificate
keytool -genkey -keyalg rsa -sigalg sha1withrsa -keysize 1024 -storetype jceks -validity 1095 -storepass storepass -keypass keypass -dname CN=MyName,O=MyOrganization,OU=MyDepartment ST=Karnataka,L=Bangalore,C=IN -keystore test.jceks

2. Export the Certificate in .der format
keytool -export -file cert.der -keystore test.jceks -storetype jceks -storepass storepass

Issue with Gzipped Content over SSL

Posted on by
Reply

After we upgraded our web application in our customer’s place, lots of users started complaining that the webpage is not getting downloaded to their browser…

Observation

  • This issue happens only in Windows 98 and some machines with WindowsXP without any service packs. And that too only when accessing the server with HTTP 1.1 compression ENABLED. We confirmed this by requesting the customer to turn off HTTP 1.1 compression and he confirmed that the application worked fine.
  • Fortunately, we were able to reproduce this issue locally in one of our Test Machines running Win98. We found that this issue happens only when we go thru Web Server. When we accessed the application via Application Server, the issue was NOT reproduced.
  • The above observation led us to another important clue, that this issue could be something to do with SSL, as that is one major difference between Web Server and App Server.

Based on all the above observation, we concluded that this issue happens only with HTTP 1.1 enabled Browser accessing the Bali Server via SSL. And the machine is running Win98 or plain Winxp(without any service packs) operating Systems.

With the above information at hand, we started monitoring the HTTP Traffic between Browser and Server using some Network Sniffing tools and found that a particular javascript file called “FMProduct.js” seems to be the culprit. Even though the file was downloaded to the Browser, the file never got written to the Temporary Internet Files cache.

Concluding that this file is the one that could be causing all the problems we tried to take the file separately and tried to access it via Weblogic Web Server and we were successfully able to reproduce the problamatic behavior.

To eliminate the possibility of Weblogic Server in playing a role in the above erratic behavior, we hosted the FMProduct.js on Apache Web Server. And now, we were able to download the file without any problems from any browser.

Now, we concluded that apart from the combinations of SSL, HTTP1.1, Win98/xp, there is yet another variant, Weblogic Server playing a role in the erratic behavior.

We monitored the network traffic when accessing Apache Web Server as against Weblogic Web Server. We found something very interesting. That is, Weblogic serves the files in a CHUNKED manner with chunk size of 4072 bytes(we are not sure what is the significance of this number). Apache serves the whole content of the file in one chunk.

The problem occurs ONLY when the last chunk is of size between 1 to 9 bytes. In other words, if the size of the file is 4074 or 4081 or 8119 etc…
The size of compressed version of FMProduct.js is 20362 – which means 5 chunks of 4072 and the last chunk contains 2 bytes.

Resolution

It certainly seems that Microsoft has fixed this erratic behavior with SSL + HTTP 1.1 combination, and hence the latest version of Windows XP (SP2) does not have this erratic behavior.

Additionally, we shall also review our build process to see if we can add a check to see if the file size falls into this magic number and if so, try and add some more insignificant characters to increase the file size.

Please note that the above erratic behavior is NOT reproduced in Mozilla FireFox? browser.

The attached Ruby Script helps print out all the files that fall into this wierd pattern.

require “find”
if ARGV[0].nil?
puts “Usage: ruby FileChunkSizeFinder.rb [path_of_baliweb]”
exit
end

Find.find(ARGV[0]) do |file|
if File.file?(file) && File.basename(file) =~ /\.gz$/ && (1..9) === File.size(file)%4072
puts file + ” ==> ” + File.size(file).to_s
end
end

Exporting Private Key from iPlanet Web Server

Posted on by
3

In quite a few occassions, we would have to sniff SSL Traffic between the browser and a iPlanet Web Server. To sniff SSL using ClearWatch Tool, we require the Private Key file in PEM format.

IPlanet stores keys internally. Hence we need to go thru a few steps to achieve the above…

Step 1 :
Firstly, the Key will have to be exported to a PKCS#12 file.

To export to a PKCS#12 file, Use the pk12util command that ships with iplanet. This file is generally available under Servers\bin\https\admin\bin folder

Syntax :
pk12util -o exportfile -n certname [-d certdir] [-P dbprefix]

Example :
pk12util -o c:\temp\pkey.txt -n Server-Cert -d c:\iplanet\servers\alias -P dbprefix

In the above dbprefix is nothing but the prefix for the Key file available under Servers\alias folder. If the key file is xyz-key3.db, then dbprefix is ‘xyz’

Step 2 :
Once you have a pkcs12 file containing a private key, you can convert it to a PEM file by using the freely available OpenSSL tool,

Syntax :
openssl pkcs12 -in server.p12 -out server.pem -nocerts -passin pass:yourpassword -passout pass:dummy

where “server.p12” is the original PKCS#12 file you are converting and “yourpassword” is the password that is associated with the PKCS#12 file.

Step 3 :
Now, we can remove the Password Protection on the Key by running the following command.

openssl rsa -in server.pem -out server.key -passin pass:dummy

Compiling Ruby on IBM AIX

Posted on by
5

Continuing my adventure on IBM AIX v5.3 ML2 with Core Dumps, this time it was Ruby!!! My simple Ruby program would give a core dump when I tried to include ‘drb’ module in my ruby script. I was running Ruby v1.8.2.

I got some clues from some news groups that there was some problem in Ruby on AIX in the sockets area and its something to do with IPV6. I was told that if I compile Ruby by disabling ipv6, I should be ok!

Guess what! I ventured into my first experience of compiling Ruby from the Source. And wow! my problem went away and no Core Dumps 🙂

I thought I should put down the steps I went thru in compiling Ruby on AIX.
1. Download latest Ruby Source from ruby-lang.org. The latest version at this point is v1.8.4.
2. Unzip the source tar file into a specific directory.
3. Invoke configure with a parameter –disable-ipv6
4. Invoke make ruby.imp
5. Invoke make
6. Invoke make install

That’s it! You have done it!

Core Dump running Weblogic on IBM AIX? – Dont Panic!!!

Posted on by
1

I must say, I am quite fortunate to have got some good opportunity to try and run our j2ee application on IBM AIX OS.

I deployed the application and started the application. All went well until I hit upon the very famous “Core Dump – Dump Handler is Processing Signal 11”. I had to spend almost 2 to 3 hours weaving thru lots of newsgroups on the internet and figured out that the FileDescriptor Upper Limit was not set(which means its set to unlimited) there is a problem in AIX in performing a malloc() to obtain a memory segment.

This is what I learnt

This is due to an AIX issue when WLS attempts to perform a malloc() to obtain a memory segment. The WLS Posix Socket Muxer code (NativeIO and stuff) does a malloc based on the FDLimit. If it’s unlimited, AIX 4 and 5 tend to throw a malloc exception. WebLogic Server WLS made it 1025, which the user can set higher if desired.

Check out this URL for more details…

Yet another SSL Sniffing Tool

Posted on by
8

Sometime back I had blogged about ClearWatch which is a very handy SSL sniffing tool. Here, you require the Private Key of the Server for decrypting the HTTPS packets.

However often, I end up in situations having to sniff the SSL traffic of Production Systems, where I donot have access to the Private Key.

Now, I have come across another excellent tool called BurpSuite. This tool can do more in the sense that, it can sniff SSL Packets without having to provide the Private Key of the Server. Also, it allows to intercept requests/responses with specific header information and allows us to change the header data whenever required. This tool basically is a special proxy server. One has to configure the browser to go thru this proxy server for sniffing purposes.

Check it out!

Am going to attend Waterfall2006 Conference at Niagara Falls, US

Posted on by
Reply

Boy! Thanks a ton to Venkat, for letting me know of such a conference with my favorite speakers – Dave Thomas, Kent Beck etc. Since am anyway going to the US in March 2006, am planning to extend my stay in US and make sure I attend waterfall2006 conference.

I shall certainly share my experiences from the conference in my forthcoming blogs 🙂

Firefox 1.5 Upgrade – Watch out!

Posted on by
Reply

I have a great respect for Mozilla applications after having successfully making our company’s product “Firefox compliant“. Our experience revealed that, IE is very leniant and hence does not scream if we write non standard html/javascript codes. However, all we had to ensure is to make the codes standard compliant, then it automatically worked both in Firefox as well as IE.

With the same confidence, I upgraded my Firefox to the latest and great v1.5. Guess what, lots of application’s functions started to misbehave. One main issue is that we often get “Script is taking long time to complete and is not responding. Do you want to stop or continue the script?“

After lots of trial and error, I tried a hack which worked for me…

Basically, in the script function, I am setting the window.status to some value with the assumption that the browser should not scream as long as there is some update happening in the screen. Guess what? this hack worked!!!

Well, the happiness was very shortlived when I found that there is an option in Firefox called “change the status bar text” under “Advanced Javascript settings” and to add to my depression, the option is by default UNCHECKED.

Therefore, though I have a hack, the user has to change this setting for my application to work fine in Firefox 1.5.

Hope someone finds a permanent solution to this issue, or is it a Firefox issue, that one day Firefox will fix it!


JDBC Transaction Control behavior varies when using Pooled and Non Pooled Connections

Posted on by
Reply

Before going into details let us observe the below code 

try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedStatement ps =
conn.prepareStatement(Some Update Sql 1);
ps.executeUpdate(Some Update Sql 1);
conn.commit();
ps.executeUpdate(Some Update Sql 2);
} finally {
try {
if (conn != null) conn.close();          
} catch (SQLException ex) {
Debug.logError(ex, "Some Error Message");       
}
}

What will happen to the second sql updation …? Will it get committed or rolled back? There are two flavours of answer to this…

  1. When connections are not pooled
    In this case, Connection.close() method commits all the uncommitted statements (As per 9i Oracle JDBC Driver).
  2. When connections are pooled
    In this case, Connection.close() really does not close the connection but releases it to the connection pool for reuse by somebody else. In this case, situation is bit undeterministic. The outcome purely depends on how the Pool manager manages. We found in Weblogic pool management, Connection.close() results in all open cursor closure and resetting of AutoCommit flag. But the uncommitted transactions are neither committed nor rolledback. All the exlusive locks obtained for the previous updation will remain alive. This behavior continues until the same connection from the pool is assigned for somebody else and he either commits or rolled back.

Now, Consider the below piece of code,

 PreparedSQLRunner ps = null;
try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedSQLRunner.executeUpdate(Some Update Sql 1);
conn.setAutoCommit(true);
   ps = new PreparedSQLRunner();
ResultSet rs = ps.executeQuery(Some Select Sql);
   ....
} finally {
try {
if (ps != null) ps.close();            
} catch (SQLException ex) {
Debug.logError(ex, "  ");         
}
try {
if (conn != null) conn.close();            
} catch (SQLException ex) {
Debug.logError(ex, "  ");         
}
}

In the above context, what would happen to the uncommitted update sql ?

As per JDBC API specification, when we change the Auto Commit flag of a Connection object from false to true, the next immediate statement on that connection, will commits all its previous uncommitted operations (that were happened with Auto Commit Flag set false). So, the call to executeQuery method, results in the committing of the previous uncommitted updation in addition to its expected service.