[lug] creating client certs for apache
blug-mail at duboulder.com
Thu Sep 8 10:56:21 MDT 2005
D. Stimits wrote:
>> using your CA cert you can create end-entity (users/machines/groups)
> This is what I want to do. I want to do this in PKCS12 format and
> distribute it to the outside world to specific individuals I trust.
>> certs with unique identifying info in the DN (Country, State,
>> Locality(city), Organization, Organizational Unit,
>> Common Name (e.g. person name, host name, group name),
>> and some other parts.
> Yes, I was basically hoping to create a public key I could hand out that
> identifies the person as belonging to a given svn project (and thus
> given web directory).
>> 4) Client UA sends its cert to the server when requested
>> during the SSL handshake. The client has access
>> to the private key for its cert so it can encrypt data.
> Here's where I start running into trouble. Configuring the apache server
> itself does not seem to be a problem, it has some nice comments in the
> ssl config file of mod_ssl. The problem I'm running into is figuring out
> creation of unique public keys to hand out to individuals or groups of
> individuals. The above item #4 leads me to believe I have been looking
> at this from the wrong angle. You say "client has access to the private
> key"...I've been thinking in terms of using the server private key to
> generate multiple unique public keys that I send to people to install in
> their browser; instead the access to private key makes me believe each
> user needs to create a self-signed key pair of their own, and then send
> *their* public key to me to install on the server.
> My initial thought: Create one unique public key for a group of people
> to access a project via the server's keys, and send that key to
> outsiders to put in their clients. Then I have to install permissions to
> access a project based on that key which I just sent out (which was
> generated based on a server key). To do the reverse would mean I have to
> get everyone involved to generate their own key pairs, and then get a
> copy of each public key to tell my server to allow that key. This
> probably means a lot of effort to get outside participants to all create
> and secure keys; instead I was hoping to do the key generation from my
> end so all the other people would have to do is import the key to their
> browser. Maybe this is not possible?
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
> 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.
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.
> 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
More information about the LUG