I give a course on Servlets and JSPs at Concordia University’s School of Extended Learning. One of the topics is SSL. I demonstrate how to create a .keystore file using Java’s keytool.exe. Then I edit Tomcat’s server.xml. Presto! All you have to do is use https rather than http and my lecture on SSL is about done. Not this time.
It worked flawlessly when I did the course last spring. This time around Tomcat delivered numerous stack traces during its start-up. The first error message stated that the certificate file could either not be found or was in the wrong format. The rest of the errors claimed that port 8443 was already in use. I had never seen this before and so I had to sheepishly tell my students that it was likely a configuration problem with my computer but it should work for them. Then it was off to the next topic on authentication.
Today I had some time to look into the problem. While my hardware/software configuration is unusual it had all worked just a few months ago. I use a 2008 2.4 Ghz Core 2 Duo MacBook with 4 GB of RAM running OS X 10.6.5. I am lusting after a MacBook Air but it tops out at 2.1 Ghz. As few of my students use a Mac and the school labs are all Windows, I run VMWare Fusion 3.1.1 running Windows 7. I like the Mac because it is excellent hardware. I hate the Mac because its GUI remains state of the art for 1995. But enough of my superfluous comments.
I use NetBeans 6.9.1 at Concordia although I use Eclipse 3.5 on the same computer at my day job as a teacher in Computer Science Technology at Dawson College. I find NetBeans a better integrated environment than Eclipse and so I find it a better teaching tool. At Concordia I can make the decision about what IDE to use on my own but at Dawson the department decided to go with the IDE more commonly found in industry. Superfluous comment alert: why can’t the Eclipse foundation get it’s sh!t together and make a Visual Editor that can compete with what NetBeans or Visual Studio has. Eclipse gives me the impression that they have written off desktop applications.
Now it’s off to Google to find the answer. Most queries using terms like Java, SSL, Tomcat and NetBeans lead to same documentation copied across a range of sites. When it comes to generating a .keystore file they all show:
keytool -genkey -alias tomcat -keyalg RSA
This does produce a .keystore file but Tomcat clearly does not like it. Then I noticed a Google reference to http://confluence.atlassian.com/display/CROWD/Configuring+Crowd+to+Work+with+SSL. It discusses how to set up SSL for their Dashboard software called Crowd. In it they simply reprint the Tomcat SSL instructions except for one new point. Here is what they wrote:
Apparently on JDK 1.6 you also need to specify the -sigalg MD5withRSA flag since -keyalg RSA will still result in SHA1 being used.
WTF! Not a word of this on the Tomcat documentation pages. Since I was doing my research on my desktop machine rather than the Mac I tested the new syntax:
keytool -genkey -alias tomcat -keyalg RSA -sigalg MD5withRSA
Started up Tomcat and entered https://localhost:8443 into IE9 and it worked flawlessly. But wait a minute, it always worked flawlessly on my desktop. I deleted the .keystore file and recreated it without the –sigalg MD5withRSA and Tomcat continued to work. I guess that’s why there was nothing about it on the Tomcat pages. So much for Atlassian having the solution. Interestingly I am looking into dashboard software so I’ll be back at this site to learn more about Crowd.
While doing my reading I came across references to Tomcat using APR, the Apache Portable Runtime dll file. I read that if APR is being used it wants an OpenSSL formatted certificate. But if it was not running it would need a JSSE formatted certificate which is what keygen produces. I examined the start-up log info on both my desktop and Macbook. I discovered that the APR was not running on my desktop but was running on the Macbook. The desktop log stated that Tomcat could not find the APR file tcnative-1.dll. But it was in Tomcat’s bin folder on both machines.
And then I finally had my epiphany. My desktop is running 64 bit Windows 7 and my Macbook is running 32 bit Windows 7. I downloaded the 64 bit version of Tomcat 6 to my desktop and it started with APR and rejected my .keystore file. Now both the desktop and the Macbook behaved the same way. I can surmise that the 32 bit version of tcnative-1.dll would not run on 64 bit Windows and so the .keystore file was accepted.
So after all this the solution was simple. First, all the Tomcat documentation is correct. All I had to do was rename tcnative-1.dll to something like tcnative-1.dll.disable and Tomcat would start without it. No more start-up errors and https worked in both 32 and 64 bit environments.
My last puzzle was why this happened at all. It did not happen in the past. The version of Tomcat was 6.0.26 and it was installed by NetBeans. I went to the Tomcat archives and started looking at previous versions. What I learned was that starting with 6.0.24 there was a Windows specific version. All the non-Windows specific zip versions do not include tcnative-1.dll. When I updated NetBeans to 6.9.1 I allowed it to install its included version of Tomcat. It used the Windows specific version for the first time with NetBeans 6.9.1.
Case closed.
Hey man!!
Thanks for your clarifying on this subject ..
Very nice explanation !!
Hello sir,
You are awesome, Thanks for the explanation. I am flattered by your searching and explanation skills. You must be the most favourite professor in the university.
Thanks again.