On Wed, Jul 25, 2012 at 4:03 PM, Tom Browder <tom.brow...@gmail.com> wrote:
> On Wed, Jul 25, 2012 at 12:49 PM, Ted Byers <r.ted.by...@gmail.com> wrote: > > Hi All > > Hi, Ted. I, too, have been looking for something like you have. I am > in the process of creating a Perl program that may be able to help you > (for at least part of your requirements), but I first can point you to > one of the most current references I can find for openssl > configuration: > > http://www.phildev.net/ssl/ > Hi Tom, and thanks. Sorry, I didn't realize I had sent my original message without a subject. I am an old hand at perl programming, and almost all of it is focussed on CGI programming in the context of secure web applications. But, to date, that security has been focussed on a) the server side certificates, and b) and most importantly, untainting and validating data (so a bad boy can't enter a SQL statement into a text field and blow away my DB - the infamous SQL injection attack). > > It's a little outdated in that the following openssl conf object names > are no longer valid (at least as of the latest stable release: > openssl-1.0.1c): > > # challengePassword_max > # challengePassword_min > # commonName_max > # countryName_max > # countryName_min > # emailAddress_max > > Thanks. I have my homework for tonight. ;-) > I plan to release my program on git-hub when I have it working. It is > designed for my work flow: > > + multiple virtual hosts on a single Apache server > > + one private CA for each vhost > > + all users requiring access to the private area for a vhost must have > an SSL client certificate generated and signed by that vhost's CA (and > I control the entire CA process as well as the server) > > I'd love to take a look. > I will provide the user passwords for the client certs. to my > intermediate helpers via the USPO and the individual client > certificates via e-mail. The users have to get their passwords from > the helpers via telephone. The passwords are similar to Microsoft > client keys but are case sensitive. > > USPO? You mean the postal service inthe US? Doesn't distribution of certificates via email create a vulnerability? I would have expected that using email, a) gives a bad guy a chance to steal/copy the certificate, and b) requires the use of yet another server to secure. >From what I have been reading, distribution of the keys is always one of the biggest headaches in the design of a secure system. I was thinking of something more like giving your helpers login credentials (with cryptographically sercur random user IDs and passwords) that can be used only once. They connect over the strongest SSL/TLS connection Apache supports, from whatever machine they will be using, so that the certificate can be created, signed, and installed over an encrypted channel in 'effectively' an instant. Making these things easy and intuitive for the end user, without compromising security, is a top criterion for me. > I will use known email addresses as user names and require the users > to enter it when logging onto the site. Apache will reject them if > their ssl cert and email don't match. > > I will rely on my web of trust through my intermediate helpers (all of > whom I know) to verify their assigned users (whom they know) and their > emails. > > Thanks. Let me know when I can take a look at yor script. I'd also like to hear about how you harden your servers. Cheers Ted
