[lug] creating client certs for apache

[Lee Woodworth]

D. Stimits wrote:
> I'm now looking at this:
> http://httpd.apache.org/docs/2.0/ssl/ssl_howto.html#accesscontrol
> 
> Basically I have the apache server set up to use https only for access 
> to subversion repositories. I have my own self-signed cert, 
> myserver.crt. At that URL it says I can now create client certs signed 
> by my self-signing-CA, followed by naming cert I signed it with as the 
> check for whether access is allowed or not. The apache site does not go 
> into details about the OpenSSL means of doing this, and I have a fear 
> about giving away private keys that should not be public. For fedora 
> core 4, I have:
> /etc/pki/tls/certs/myserver.crt
> 
> First, am I correct to say that despite this not being in a directory 
> labeled "private" that this crt file should be a guarded secret?
All private keys need to be protected. Where you aren't using the
private key it makes sense to keep it on removable media such as
CDs. However the apache processes need to read the server's private
key file so they can do encryption in the SSL handshake.

Note that certificates should not contain private keys.

> 
> Second, can I create multiple client certs from this server cert which 
> are each unique? What I'm getting at is that I might want to issue a 
> different cert for each person, such that if there is a problem I can 
> revoke only the one cert. Or alternatively, I might want to issue one 
> client cert for a group of people using one subversion repository via 
> https, and a different cert for a different group, and have it 
> automatically know via cert that they have access to some directories 
> but not others. All of which hinges on either making multiple unique 
> client certs from one server cert, or else creating multiple server 
> certs if I can make only one client cert per server cert. Any advice on 
> creating these certs, and keeping the right parts private, especially on 
> fedora/apache 2?
An x509 cert contains information about a subject, with the DN
being the identiying information. The cert should not have the
private key. The CA signs the cert with its private key and the
CA public key is included in the cert.

using your CA cert you can create end-entity (users/machines/groups)
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.

I did something like this 2 years ago. IIRC, the setup for
using certs for client identification is like this:
   1) Server has the private CA cert in its known/trusted root
      certs list.
   2) Server sends its host cert (CN=<host name>) to clients
      during the SSL handshake. It must be able to read
      the host cert's private key so it can encrypt data.
   3) Client has the private CA cert in its known/trusted root
      certs list.
   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.
   5) On apache 2, SSL has to be enabled for the URL space or
      the directory tree that URLs map to.
      <virtualhost ....>
         SSLEngine on
         SSLProtocol SSLv3 TLSv1
         SSLCA* ...
	SSLCert* ....
	# This asks for the client cert and fails if it isn't
	# A valid cert. Does not do anything about deciding
	# that the cert is a valid user.
         SSLVerifyClient require
	SSLVerifyDepth 1
	SSLOptions StrictRequire ...
         SSLRequireSSL
	SSLL

	# Make sure the common name part of the client's cert is a certain
         # value and that the issuer is a certain name -- adapted from the
	# examples in the apache 2.0.54 docs
         SSLRequire ( \
             %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ && \
	    ( \
               %{SSL_CLIENT_S_DN_CN} == "<common-name-1 part of cert DN>" || \
               %{SSL_CLIENT_S_DN_CN} == "<common-name-2>" \
             ) && \
	    %{SSL_CLIENT_I_DN_CN} == "<issuer-common-name>"
	)
     </virtualhost>

   6) You can also revoke certificates. See the SSLCARevocation* directives.
> 
> 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