Apache is probably the most widely used web server currently available. It can be used on any form of UNIX and derivatives (Linux, *BSD, etc.) as well as other operating systems such as Windows and OS/2. It is freely available and open source, scalable, extremely configurable, and stable. All of these factors make Apache a tough choice to beat. It also provides a number of security extensions, including SSL (or HTTPS (HTTP over SSL)) support. While SSL can be used to keep data transferred over the internet secure (things such as login information, banking, online purchasing, etc.) it can also be used to form a means of authentication. With Apache, you can dispense with a traditional login mechanism and use client certificates, signed by a specific Certification Authority, in place of providing a username and password. With Apache, you can verify client certificates by depth, to ensure that a specific CA did in fact sign the client certificate. If you have complete and secure control over the CA, and sign the client cert, you can ensure that you control who gains access.
Of course, something like this cannot be used for everything and for everyone. This is useful if you’re setting up a site that a limited number of people will be accessing and you want to control who gains access.
There are a few steps to take before we can begin to deal with Apache. First, you must have a CA at your disposal. They are quite simple to setup and manage and are covered in the [selfca.php Creating and Maintaining Your Own Certification Authority] topic. Then we have to create client certificates, or provide the instructions to our users who will be using the service to generate their own and send a CSR (Certificate Signing Request) to you to sign with your CA.
Creating the Client Certificate
The client cert is quite easy to create. The user must have OpenSSL installed on their system and would then use the following commands:
$ openssl genrsa -out user.key 1024 $ openssl req -new -key user.key -out user.csr
Fields such as tthe Organization Name and Organizational Unit should be standard across your user’s client certifications. For example, if the service you are setting up is for development of a software package called Package, you might want to use an Organization Name of “Package” and an Organizational Unit of “Package Developer” or something similar. This uniquely identifies this certificate as being used for one exclusive purpose.
Once the CSR is created, the user sends the CSR (user.csr) to you to sign with your CA.
To sign the CSR, use:
$ openssl x509 -req -days 365 -CA /path/to/ca.crt -CAkey /path/to/ca.key -in user.csr -out user.crt
Send the user.crt file back to the user. At this point, the user must combine the certificate you just signed and sent back to them, and their key, to form a P12 file. The user accomplishes this by using:
$ openssl pkcs12 -export -clcerts -in user.crt -inkey user.key -out user.p12
The user then has to import user.p12 into their browser of choice. Depending upon the browser, this is done in different ways, and some browsers do not support importing P12 files.
Importing Client Certificates Into Your Browser
…TODO…
Configuring Apache
…TODO…