[lug] creating client certs for apache

[Lee Woodworth]

D. Stimits wrote:
> ...
> 
>> 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 
You never send the CA's or the server's private key to anyone. Each and
every cert has its own public/private key pair. That means the CA, server,
group and individual certs each have their own associated private key.
The private key should not be included in the cert (CA, server,
client, group...) or a CSR, only the public key.

Private keys are never transmitted during the SSL session. However
each party in the conversion has to know the private key associated
with the public key it sends to the other party.

Creating a signature with a private key does not include the private
key in the signature data. If you aren't careful, the openssl tools
can end up including the private key in the cert along with the signature.

> 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?
You have to use a secure channel to distribute private keys. It doesn't
matter if it is per-individual or a single group. The standard way to not
require a secure channel is to have the clients generate thier own key
pairs, generate a CSR which then gets signed with the CA key. The CSR
and the signed cert can be sent in the clear. Note that the CSR does
not have the client's private key, only the public key. The signed
cert does not have the CA private key, only the public key.

> 
>>>
>>> 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.
I assume you mean openssl. If your private key has a pass phrase
(is encrypted) then it is probably waiting for the pass phrase without
providing a prompt (this behavior is probably to help scripts which
redirect the private key file to stdin).

> 
>> 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 
The keys are always in public/private pairs. The public key without
the private is useless for the client.

> 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.
It isn't a matter of how many certs a client can provide. The client
must have the private key for the cert it is using for the connection
to the server. The security of the protocol depends on this. How many
other clients have a copy of the cert and the private key doesn't matter,
so the distinction between group or per-individual certs is irrelevant.

> 
> D. Stimits, stimits AT comcast DOT net
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug