Assumptions:
You have mod_ssl and
apache installed and apache is configured. You will also need the openssl tools.
All of these should come pre-packaged for your distribution.

Why Use mod_ssl?: On the client side, mod_ssl allows people visiting
your webpage to be able to authenticate that your website really is you. This
is something that would be very important to someone sending their credit card
information to a website, they would want to know they were sending it to the
right person(s). It also allows all traffic to your site to be sent securely,
also important to someone sending credit card information, or any sensitive data
over the wire.

On the server side, mod_ssl allows the website to authenticate the client visiting
the site. This is useful if you want to allow only certain people access to parts
or all of your website, and you don’t want to have to deal with passwords. It also
provides for the same encryption of traffic as noted above.

Becoming a Certificate Authority: The href="http://www.modssl.org/docs/2.8/ssl_glossary.html">
Certificate Authority (CA) is an individual or group that issues
certificates. Before issuing
certificates the CA should verify the authenticity of the person
requesting the certificate, that is
make sure they are who they say they are. Furthermore to have an affect
as a CA, the CA needs to have
a considerable amount of trust from its users. For this reason most
people don’t become their own CA,
and instead they leave that part up to companies like href="http://www.thawte.com/">thawte, or
verisign

For our purposes we will ignore the previous, and assume that our CA
duties will be limited
to issuing certificates to ourself, and maybe friends, and family, or
in a work environment,
maybe co-workers. The openssl toolkit has a nice script called
CA.pl that is
a wrapper around most
of the openssl commands, that will make our job as a CA easier. The
first step is locating this
on your machine. My experience is that it is rarely in a directory
already in your
href="http://www.linux-tutorial.info/cgi-bin/display.pl?9998&9998&388&0&3">$PATH
, so I
suggest using slocate
to locate the script
on your system:

[augie@goku augie]$ slocate CA.pl
/usr/share/man/man1/CA.pl.1.bz2
/usr/share/doc/libopenssl0-devel-0.9.6i/apps/CA.pl.pod
/usr/lib/ssl/misc/CA.pl

The path above in bold is the path to the executable script. From now
on we will assume that
this path is in your $PATH. The first thing to do with the CA.pl script
is create a new CA
hierarchy which we will use to help us manage our certificates.

[augie@goku augie]$ CA.pl -newca

This will create a directory called demoCA in your current working
directory. You will be asked
a series of questions, most of which you should know the answers to.
Inside your demoCA directory
is among other things a file called cacert.pem . This is your CA
certificate (or public key), and
this is what you or other people using certificates issued from this CA
will need to import into
their browsers and trust. Because if they do not know and trust the CA
that issued the certificates,
then they for sure cannot trust the certificates themselves. When you
are ready you should rename
this file and post it to your public website. Congratulations you are
now your very own Certificate
Authority!

Obtaining a Certificate: The first step to obtaining a
certificate is making a request,
which will then be sent to your Certificate Authority of choice. The
request is called a
Certificate
Signing Request (CSR),
and the CA.pl script makes making one very easy.

[augie@goku augie]$ CA.pl -newreq

You will again be asked a series of questions, all of which you should
know the answers to,
except the one about the Common Name (CN). When creating a
server certificate it is
very important that the Common Name you put down in your Certificate
Signing Request be the
same as the domain name you are trying to get a certificate for.
After answering the questions the CSR along with your server’s
private key are in a file called newreq.pem in the current working
directory. If you are going
to have this request signed by anyone but yourself I recommend
stripping out the private key
part of that file before sending it to that CA.

The following step is only if you are going to be signing this request
yourself using the CA info
we created in the previous section in the demoCA directory. The request
is signed with the CA’s
private key, using the CA.pl script it is easy:

[augie@goku augie]$ CA.pl -signreq

The default lifetime of our certificate is 365 days, this is good
enough for our test purposes.
Your new signed server certificate is in the file called newcert.pem .
The process of obtaining a client certificate is exactly the same except
you do not have to worry so much about the Common Name part of the certificate.

Using Your Certificate: Now that you have a certificate you probably
want to use it right? If you have created a client certificate you will first need
to convert its format and then import it into your browser. Your browser will expect
the certificate to be in the binary pkcs12 format to convert it do the following:

[augie@goku augie]$ CA.pl -pkcs12

The out put will be a file called newcert.p12, this is what you will import into your
browser. The new pkcs12 format file contatins both your private and public key. In mozilla
it is Edit -> Preferences -> Privacy & Security -> Certificates -> Manage Certificates
-> Import .

Using your server certificate is slightly more complicated, however the first step will
be to rename the two parts to your servers identity. Your private key is stored in the file
called newreq.pem, rename this to something more descriptive, I prefer server.key . Your
public key is in the file named newcert.pem, I like to rename this server.crt . Next you will
want to move these to a more central location for your web server to find, however I will
leave that for the next section.

Configuring Apache: The location of the following files is determined by your
version and setup of apache, however the directives themselves are standard.

I moved my server.crt and server.key to the directory /etc/ssl/apache/ . I have two
configuration files that are pertinent to this setup, they are both located in
/etc/httpd/conf.d/ and are named 40_mod_ssl.conf and 41_mod_ssl.default-vhost.conf
respectively. They are both
Includeed in my main httpd.conf file. The default
values for 40_mod_ssl.conf should be fine, except for perhaps the

SSLPassPhraseDialog directive. The default is ‘builtin’, which requires you to
pass the passphrase for your server key to the console everytime apache is restarted.
I prefer the alternate route which is to use the ‘exec’ option like so:

SSLPassPhraseDialog  exec:/etc/ssl/apache/givepass.sh

The contents of givepass.sh look like this:

#!/bin/bash
echo "password";

There may be better ways, but on my stand alone server this is fine. The defaults
for 41_mod_ssl.default-vhost.conf should be fine, however you will need to specify
the location of your
DocumentRoot, and the location of your server.key and server.crt like so:

SSLCertificateFile /etc/ssl/apache/server.crt
SSLCertificateKeyFile /etc/ssl/apache/server.key

Your location may vary of course. That is all, restart apache, and surf to your website
to test it out. Remember though, that you must import that CA certificate that you used
to sign your server certificate into your browser. This will be located in your demoCA
directory in a file called cacert.pem . A copy of this file should be placed on your website,
if this was the CA that you used to sign your server certificate (i.e. self signed certificate).

Client Authentication: You can use a client’s certificate to authenticate them on
your server, and then allow or disallow access based on that authentication. However this
takes a bit of additional configuring on the server end. The first thing you’ll need to
setup is the
SSLCACertificateFile directive. Which will house the CA certificates for all the signed
client certificate you’ll be authenticating. If you used your own CA powers to sign client
certificates this will need to point to a copy of your CA certificate. I have mine setup
like so:

SSLCACertificateFile /etc/ssl/apache/cacert.pem

Next you can setup secure directories with the following options:

SSLRequireSSL

SSLVerifyClient

SSLVerifyDepth. You can use them with a

Directory directive, or in a
.htaccess file. My .htaccess for the directory I want to secure looks like this:

SSLRequireSSL
SSLVerifyClient require
SSLVerifyDepth 1

The SSLRequreSSL directive makes it so my secure directory cannot be accessed through
normal HTTP connections only HTTPS connections. By setting the SSLVerifyClient directive
to ‘require’ I am saying that only verified clients can access my secure web directory.
And finally the SSLVerifyDepth tells my server how deep to check when verifying a client,
with a value of one, only clients who’s certificates have been issued by myself will be
allowed.

Perfect! Now only people who I have personally issued certificates to can access my
secure web directory. But what if I want an even finer level of control, and how can
I distinguish between these individual clients? One last mod_ssl directive will help
you do this,
SSLOptions:

SSLOptions StdEnvVars

This directive in your .htaccess file will pass the mod_ssl environment variables
to your server scripts. Variables like _SERVER["SSL_CLIENT_VERIFY"], _SERVER["SSL_CLIENT_S_DN_CN"],
which will tell you whether the client was verified successfully, and the client’s
Common Name (usually their real name, first and last), respectively. You can also
get all of the other client certificate information, which you could then use to
identify individual clients. As always after adding new directives to your apache
configuration, you will need to restart apache to see them work, but after doing that
you are set!