All hacks has a history, a story of why it originally was created and how it evolved over time. The history of CrtAdm is not very dramatic, but it started with a need for a solution.
A few years ago 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 aneed 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. The first version of the server was primarily a password protected wiki. However, it was immediate clear that this was not sufficient both from a service perspective and from a security perspective. Besides of a wiki, we needed 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 buttin 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 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. There are 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 discovered Groovy and soon after Grails . So it was obvious that building a webapp using using Grail/Groovy for the cert admin, was the right thing to do. The first version of the Grails webapp had the cert machinery integrated, which wasn't proper design, but allowed my to test my 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 you are looking at 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. The second component is the webapp for creation and management of certs.
Stockholm/Sweden, 22 January 2008
Jens Riboe