[lug] creating client certs for apache

[D. Stimits]

...
> Keys are in pairs - public, private. The public key is published
> through the cert. The private is key used by the client to prove
> that it is associated with the cert. The client key pairs are
> unrelated to the CA or servers they might connect to. They are
> not like physical keys used in door locks.
> 
> You create the key parirs and CSRs for the authorized clients. See
> openssl genrsa and openssl req. Then you sign the CSRs with your
> CA cert (i.e. the CA private key). After that you distribute
> The CA cert, the client cert and client private key though a
> secure channel.

This is the part I don't want: I won't be distributing a server's 
private key to anyone. But I am willing to sign public keys to be used 
in web browsers and svn clients that will access the repository. The 
question is, do I demand every person involved learn to create key pairs 
and have them send me a key to sign...or can I just create a key pair 
separate from the server, but signed by the self-CA of the server, and 
give those out?

>>
>> Now as far as apache goes, once I have the keys to be accepted, the 
>> server is not hard to configure. My question is on configuration of 
>> the mozilla end...mozilla wants a PKCS12 format, which I do not have 
>> (and which will be needed regardless of whether I'm the one who 
>> generates it, or if outside individuals generate their own). I assume 
>> I have to do a conversion to this format, probably based on my cert, 
>> and then send that out to everyone. My question now is whether this 
>> assumption is correct, and if so, how do I generate a public key from 
>> my server's cert (or from the server's private key) in PKCS12 format, 
>> such that I can give it a name like "Repository X Developer"? Then I 
>> could set up apache to allow access to repository named "X" if that 
>> key is present. I could send out a "Repository Y Developer" key as 
>> well and give them automatic access to the repository named "Y".
> 
> See openssl pkcs12 for format conversion. The cert files used by IE may
> need to have a .crt extension.

This conversion has been eluding me. What I get is a stuck openssh 
process waiting for input.

> For authentication look at the SSLRequire directive for apache. You don't
> directly authorize keys. The easiest thing to do is authorize client certs
> by using info in the subject DN. The server verifies the validity of the
> client cert (e.g. the subject DN) by using the issuer info in the cert.
> Thats why you have the trusted CA list. Once the server knows the cert is
> valid it effectively asks the client to prove that it is associated with
> the cert by knowing the private key associated with the cert's public key.
> The client proves it knows the private key by being able to encrypt data
> the server can decrypt by using the public key.

Exactly...I planned on SSLRequire, plus a valid group for one 
repository, and valid user for another. The group will be able to access 
one repository without password by means of a key; nobody but one 
individual will access the other repository, and that too will be via 
key rather than password. The question is the process needed to 
distribute keys, whether I can avoid making every person create 
keys...I'd like to create a group key myself and give the public key 
out, keeping the private key so nobody else can generate them. Perhaps 
this isn't possible...maybe the mozilla browser and svn client are 
incapable of loading more than one user cert? If so I have to revert to 
passwords again, for every single svn command, and every file or 
directory browse by a browser.

D. Stimits, stimits AT comcast DOT net