DateCalc released
DateCalc is a small stand-alone Java program that provides simple command-line date expression calculations such as
yes> java -jar datecalc-2.0.jar today yesterday.day.end today.day(12) "today.format(d MMMM yyyy)" date(2006-10-03).day.end month(-1).month.end.day.start today.month.name tomorrow.day.name2008-02-18 13:38:40
2008-02-17 23:59:59
2008-03-01 13:38:40
18 februari 2008
2006-10-03 23:59:59
2008-01-31 00:00:00
februari
tisdag
A few years ago I was working with a shell script that was a batch front-end for a complex system handling monitoring data. This script was intended to be run from cron every month to create a monthly summary report. Typically, it executed early morning the 1st of every month, producing a report for the last month.
The problem was to compute date-time of the first and last seconds of the previous month. I needed a simple way to express dates such as “give me the end time of the last day of the previous month “. As a well-known fact months can be 28, 30, 31 (and 29) days long. I couldn’t find a convenient command that gave me the answers. Unix date was of no help.
That problem inspired me to create a small Java class that solved the immediate problem. Later I refined it and made it more versatile.
When I was about to release the first public version, I started to scrutinize my design and realized it could be better. I therefor re-wrote all of it and improved the simplicity of the operators and the separation of concerns in the design.
CrtAdmLib released
Today I have released my latest hack - CrtAdmLib. It is a small shrink-wrapped library for generating certificates and CRLs for revocation. From a generated root (CA) certificate, it can generate both server and client certificates. It can convert to and from PEM format for both certificates, keys and CRLs. It can convert to and from PKCS12 for client certificates intended for HTTPS with client certificate authentication.
So, what’s the point? One can use OpenSSL or Java KeyStore. The answers are simplicity and portability. If you ever tried to create client certificates for HTTPS client-side authentication using openssl (or even worse keystore), you realized it (1) takes a while to understand all the steps and (2) it’s a convoluted multi-step process and (3) it’s not really platform independent, when have to stick to shell scripts to smooth out the process.
The background of this library goes back a couple of years, when I was working for an international company within a geographical dispersed professional services organization. For traditional type of companies, you normally pick up informal information around the coffee table. That is simply not possible, when you are working for a company when you never meet your colleagues. Clearly, there was a need for a central place to collect highly technical but internal information. The solution provided at the time, was a VPN connection to internal servers. However, being at customers 100% of the time combined with the observation that customers, in general, never let you plug-in your own laptop to their networks, formed a catch-22 situation.
The solution I created was an independent site, hosted at some hosting company, with a wiki, a Subversion repo, Maven repo, Blog space and a general file storage. The security problem was solved by HTTPS access, guarded by client certificate authentication. Based on client certs, it was easy to provide access to all other services using simple HTTPS. The first version of the certificate generation system was a collection of shell scripts written by one of my colleagues. The launch of the new site - with all its services -became instantly a success.
However, over time it became apparent how much administration it was to manage new certs, re-send lost certs, revoke certs and more. Because, it was my site I did all the administration. So a better solution was needed. This resulted in a Spring based webapp, still using some modified shell scripts. I saw the need to maintain meta information, so the a directory became sort of a database with certs and additional information. This solution was superior to the previous one. A newly created cert could be emailed to the user with a button click and a cert could be revoked with another button click, which behind the scene created a new CRL and reloaded Apache.
All good then? No, my Java heart felt a sting, because I had a non-portable solution, not 100% Java and despite the improvement, still had some maintenance struggles. When the orginal project started I had very limited and shallow knowledge of cryptographic certificates. After I created the new webapp, I realized that I still viewed certs as something magic. I therefore started to investigate a 100% Java solution. I found many sources on the net, however non that really “got to the meat”.
A radical change came when I got my hands on Beginning Cryptography with Java , which describes everything indepth using the Bouncy Castle crypto provider. After some inital spikes trying different ideas, I got something working and coherent. At this time I wasn’t working for that company any longer, so my interest was purely self-educational. During the same time period I was investigating cert generation in Java, I also discovered Groovy and soon after Grails. So it was obvious for me that building a webapp using using Grail/Groovy for the cert admin webapp, was the right thing to do. The first version of my Grails webapp had the cert machinery integrated, which wasn’t proper design, but atleast allowed me to test the design ideas.
Finally at last, to round this story up. I decided to split the webapp and the library starting over from scratch. The first component is the cert generation library I’m writing about right now. It’s a 100% Java solution (not implemented in Groovy), and can be used separately as a component in another cert admin webapp, or called from a set of scripts using the CLI.
The second component is the webapp for creation and management of certs, which I still have to develop. Stay tuned…
Blog created
Now is this blog created and just need some stuff to put there.
-
Jens Riboe
