debian/rules
   
Tue, 17 May 2005

Abusing Keytool

Well, We've got this horrible java portal thingee running at work as a pilot to deciding if we actually want to run some sort of single sign-on portal for staff and students... It's nice, in that I don't have to do much, other than make sure the machine runs, and the tomcat service stays up - We've got a little 'portal team' that's doing all the hard work.

So, anyway, TPTB decided they wanted a calendar portlet - sadly nothing out there for uPortal is of any usable quality, so they wanted to use a php calendar served via apache+php in the back end, to an iframe channel in the portal. Yech. But, ok. My only stipulation was that the back end server would detect if it wasn't being run in the iframe, and redirect people to the portal proper, in an attempt to stop people finding the calendar URL and accessing it directly.

Well, to cut a long story short, the production system is served over SSL, whereas the dev system isn't. The dev system worked fine, the production didn't. It boiled down to the fact that the calendar installation for the production system wasn't on SSL, and this was throwing a spanner in the works with how the portal's iframe proxy thingee was requesting the calendar pages. Solution? enable SSL on the calendar URL.

So, the private key for the SSL certificate we're using, is hidden away in a java keystore. The cert is easy to get out for apache to use, but the key isn't. So, a little googling, and I found this. Very Very useful. So, basically, you can do this:

wget http://mark.foster.cc/pub/java/ExportPriv.java
javac ExportPriv.java
keytool -list -keystore <keystore> -storepass <password>  # (to get the approprate alias)
java ExportPriv <keystore> <alias> <password> > exported.key

Viola :)

[00:08] [/Work] [permanent link]