Writing

Software, technology, sysadmin war stories, and more. Feed
Sunday, August 28, 2011

Wrapping OpenSSL for the Windows folks at work

I made a lot of random tools in my role as a meta-support person. By meta, I mean I supported the people who then provided support to our customers. That support was really the service, since anyone can sell you bandwidth and servers and rack space, but finding someone who's technically clued and yet friendly isn't exactly simple.

One night, one of my friends popped up an IM screen and told me some of the newer Windows techs were too afraid to do SSL certificates for customers. As a Verisign reseller, we'd get orders, and then had to turn around, generate a key and signing request, then submit the CSR and wait. Once they issued a cert, we'd take that and the key, drop it on the server, and go on with life.

Generating the key and CSR is absolutely trivial if you're on a box with OpenSSL, and that was the case with all of the old-school techs. They ran Linux, even if the customers they supported were actually running Windows. rdesktop took care of that. But, the newer techs were all running Windows natively and didn't have OpenSSL just there. They were also afraid to grab some "playground" box and do it on that. My friend spotted this and came to me for help.

I figured that OpenSSL probably could be wrapped with something like popen() without too much trouble. I knew it probably also had library routines for this stuff, but forget that. Having gone through the process of adding OpenSSL to a TCP-based client/server system, I wasn't about to suffer through that for a quick proof-of-concept hack.

So, I wrote something which would take the various bits of input like country, locale, common name, and so forth and would cram them into OpenSSL's "req" program after creating a fresh key. Then it would read back the results and print them. Then I wrapped that in some dumb CGI library stuff I had written for other tasks, and put it on my workstation.

Total time elapsed from "hey, we need this" to "hey you, try this" was about 25 minutes. Clearly, good things happen when I have the right kind of environment. Working from home, having coincidentally eaten a bit of pizza an hour before, and being able to play my favorite music helps.

Naturally, there were a few dumb things I had to tweak, but by the next day, they were able to use it for real. There was one final hurdle before they could really be happy: they needed this stuff in PFX form. So, I went back to my machine and hacked up something which would take the key and the newly-issued cert and would make a file which worked for them.

Now, earlier, I said this was a "proof of concept" thing. The idea was to show this to the folks who wrote the provisioning and ticketing systems. Those systems *already* stored the key, signing request, and certificates, but for some odd reason we always had to generate them manually and then paste them in. We figured that it would be possible to have that thing generate them itself, and who knows, maybe even talk to Verisign through some kind of API! Removing opportunities for human error is a good thing.

Unfortunately, I think this never happened. I think they're probably still using my evil little hack, since as previously noted, my old workstation still lives.

I guess you can lead a company to automation but you can't make them embrace it.