Client Authentication with SSLMost of you will be aware that I’m in the process of setting up a new box for the website. As part of that process, I’m strengthening some of the administration functions. Specifically, I’m adding client authentication to make that that only my browser can access these features. In short, only specific people will be able to access certain areas of my website. These people will be authenticated using client authentication.
If you’re actually looking for how to set up an https server, please try Apache with SSL.
Or if you’re looking for something more simple than certificates, you could just use passwords.
But first, let me introduce a few terms and explain a few things in order to give you a bit of background.
- Secure Socket Layer – This protocol is commonly used on websites when encryption is required (not quite, but see https below). Most websites selling goods should be using SSL. If they aren’t, the information passed between your browser and their website is in clear text, readable by anyone who can sniff it. Now that’s unlikely that someone will, but it is quite possible.
- HyperText Transmission Protocol, Secure – This is the protocol used between the browser and the website. Underneath, it’s just SSL. This is why some websites start with http://www.example.org/ and others are https://secure.example.org/. Those using https are using the secure version of the http protocol.
- OpenSSL is a project which delivers the SSL protocol, tools, and libraries in a freely available package. This is what FreeBSD uses for its SSL implementation.
- Client Authentication
- This is the ability of a webserver to verify who is at the other end of the browser. There is more than one way to authenticate a client, but we will be concentrating on certificates (you could also look at using passwords). More correctly the website requests that a certificate be provided. As you read this article it will become clearer just how this process is performed.
Introducing SSL and Certificates using SSLeay by Frederick J. Hirsch.
We’re going to be using X.509 certificates so perhaps this document might be useful:
Certificates tell us who is who. A certificate ensures that the website you are talking to is indeed the website you think it is and who it says it is. But how can you trust that a certificate hasn’t been forged. Because it’s been signed by someone you trust. Well, not necessarily someone that you personally trust, but someone that is widely regarded as a Trusted Authority. For example, Baltimore, RSA, VeriSign and, Thawte each issue certificates. If I look at my MS IE browser, I can find a long list of trusted root certicate authorities. Your broswer probably contains a similar list. https and SSL is all about trust. This trust has to start somewhere. Usually it starts with a signing authority which is trusted implicitly. From there, anything signed by that authority can be trusted. And so on… My description is a rather simplistic approach to what can be a very complex matter. But it should suffice for what we’re trying to accomplish here. The whole idea of SSL is to get the data securely between a web server and a client. That is accomplished by encryption. The first time a client accesses a web server that uses SSL, the client is presented with an the certificate. This information allows the client to determine three important things:
- The certificate has not expired yet.
- The certificate was created for the web server now being accessed.
- The certificate is signed by someone the client trusts.
Certificate AuthorityFor this step, I found HOWTO: Creating your own CA with OpenSSL by Pheng Siong Ng to be very useful. With this information, I was able to create my own certification authority (CA) with OpenSSL (note that VeriSign is also a CA, albeit a much better known CA than the one you just created). Then I used that CA to sign a certificate request. This is what VeriSign would do if you ask them for a certificate. If you have more than one web server in your organisation, it is a good idea to have the same CA sign all of the certificates. The HOWTO document referenced above actually does more than just create a CA. It also shows you how to create a server certificate and then sign it. I think it’s important to distinguish between the two processes, so I will break up the HOWTO steps into two sections:
- Creation of a CA
- Server Certificate
Certificate Authority – creationI’ll outline the steps I took but please refer to the primary document for full information on what I’m doing here.
- Create a directory where I can keep all my work in one clearly defined place:
mkdir ~/CAThis is where I did all my CA work.
- Copy CA.pl and openssl.cnf into ~/CA. First, I had to find these files. I used
$ locate CA.pl /usr/src/crypto/openssl/apps/CA.pl /usr/src/crypto/openssl/apps/CA.pl.in /usr/src/crypto/openssl/doc/apps/CA.pl.pod
/usr/src/crypto/openssl/apps/openssl.cnf. If you don’t have /usr/src loaded, you can get these files directly from the CVS repository. Please take the revision which is relevant to the version of FreeBSD you have installed. For example these are the files you want for FreeBSD 4.3 as of the time of writing:
- Apply the patch supplied by Ng Pheng Siong. This extends the date range of the certificate. The default value for my script was 365 days. The patch changes it to three years. I actually opened CA.pl and searched for $DAYS and manually replaced all instances with -days 1095.
- Create the new CA:
perl CA.pl -newcaNow ~/CA/demoCA/cacert.pem contains the certificate for your new [personal] certificate authority.
Server Certificate – creation
In this section we’ll create a server certificate request and then sign that request using the CA we created in the previous section.
- Generate a certificate request.
perl CA.pl -newreq
- Sign that request. This is what a Trusted Authority does for you.
perl CA.pl -signHad you wanted a third party to sign your certificate for you, you would send the certificate request to them, they would sign it, and send it back to you. You would use that certificate. Since we are not going to do this, we will sign our own certificate. That is why our certificate will be known as Self Signed SSL Certificate.
- I then extracted the private key into a separate file:
openssl rsa < newreq.pem > newkey.pem
File names should reflect file contents
For ease of use, I moved things around so the file names reflected the file contents.
mv newcert.pem server_cert.pem mv newkey.pem server_key.pem mv newreq.pem server_req.pem
OK. What did I just do?In summary, you now have the following items:
~/CA/demoCA/cacert.pem– the CA’s certificate. You’ll need to move this to your web server. See later in this article. This is destined for
server_cert.pem– the server certificate you signed. This will be used in a later step to create a client side certificate which you can load into your browser. This will become
server_key.pem– the plain text (encrypted) private key for the server certificate. Private keys are the secret part of the certificate. Therefore we don’t want them to be world readable.
server_req.pem– the encrypted private key for the server certificate and the original certificate request.
Create the secure area of your website
The creation of an https server is beyond the scope of this article. Perhaps Apache with SSL will help you with that. What I’m going to show you is how to allow clients to visit most of the website but require authentication to visit a particular URL. I found exactly what I wanted at the How To section of the mod_ssl website. I’m using the mod_ssl port on my web server.
In this example, we want to control access to the
/stuff section of our website.
For example, people browsing to
http://www.example.org/stuff/ will require
a certificate. If you want to secure a different area of your website, make adjustments to
the below as appropriate.
I actually used a greatly reduced version of the information found in the “second method” listed
at the above URL. I added this to the VirtualHost defined for my server:
SSLEngine on SSLProtocol all SSLCipherSuite HIGH:MEDIUM SSLCertificateFile /usr/local/etc/apache/ssl.crt/server_cert.pem SSLCertificateKeyFile /usr/local/etc/apache/ssl.key/server_key.pem SSLVerifyClient none SSLCACertificatePath configuration/certificates SSLCACertificateFile configuration/certificates/cacert.pem <Location /stuff> SSLVerifyClient require SSLVerifyDepth 1 </Location>
I’ll explain some of the above with the following:
After setting up the above directives, you should verify the settings:
- created when we made our own CA. It is the certificate for the CA. This was the first part in the CA HOWTO.
- the server cerficate which we created during the second part of the CA HOWTO
- The key for the cerficicate. Keep this safe and secure.
- This is similar but still quite different from a
Directorydirective and I’ve come to like it better. It allows you to specify the URL instead of the file system.
Locationis URL specific, and not [necessarily] related to the file system at all. It is with the location directive that I specify the secure area of the website.
- This directive mandates that the client has to present a valid Certificate.
- directive indicates that the client client certificate can be self-signed or has to be signed by a CA which is directly known to the server (i.e. the CA’s certificate is under SSLCACertificatePath). In this case, if the secure area of the webserver is https://example.org/stuff/.
and make any changes as necessary. Then I would stop and start the server. This is necessary because you are changing certificate information./usr/local/sbin/apachectl configtest
You should then check for any error messages:/usr/local/etc/rc.d/apache.sh stop /usr/local/etc/rc.d/apache.sh start
$ tail /var/log/httpd-error.log [notice] caught SIGTERM, shutting down [notice] Apache/1.3.20 (Unix) PHP/4.0.6 mod_ssl/2.8.4 OpenSSL/0.9.6 configured -- resuming normal operations
Converting the certificate to pkcs12 format
The signed server certificate to be converted into the format used by programs such as Netscape, MSIE and MS Outlook. Fortunately, I’ve been pointed at the right place by my friend Eric Rosenquist. To do the conversion I used this command:
Make up a password, use it, and remember it. This password will be required when you go to import the certificate into your browser. Remember it.$ openssl pkcs12 -export -in server_cert.pem -inkey server_key.pem -out iestuff.p12 Enter Export Password: Verifying password - Enter Export Password:
Security considerationsBe careful with your certificates and keys. If someone steals your certificate, they can’t be authenticated over SSL as you unless they also have your private RSA key. Your private key is included in the .p12 file. Thus, if someone gains access to your .p12 file, they can impersonate you. Simply being aware of this is a good start.
Import the certificateIf you were to browse to your secure area now, you would be warned about the site certificate. Since we know we created our own certificate, we could view the certificate to verify that it’s the one we expect, and then click on Yes to proceed. Then you will be presented with a message asking which certificate you wish to use. You would also be given a list of certificates to select from. This step allows you to import a certificate into your browser. Instructions are supplied only for MSIE. You’ll need the
iestuff.p12created in the previous section. Then perform these steps:
- select Tools | Internet Options | Content | Certificates | Import….
Or you could just double click on the .p12 file…
- From the Certificate Wizard Import Wizard, click on Next
- Use the Browse button to select the
- click on Next
- Enter the password you used to create the pkcs12 file
- click on Next
- I selected the default option to automatically store the certificate and clicked on Next
- click on Finish
Revoking a certificateA CA can revoke a certificate it has issued. This may be for a number of reasons but a prime reason would be a certificate compromise: someone has accessed the private key associated with a certificate and it needs to be revoked for security reasons. Each CA should publish a list of revoked certificates. This list is known as a Certificate Revocation List (CRL). Normally these lists are publically availble so that a server can check it before accepting a given certificate. That said, in my instance, I’m not doing a CRL yet, because I’m the only person using these certificates.
These resources might help:
- Security Solutions with SSL – slide show from ApacheCon 2001
- modSSL SSLCARevocationFile documentation
- Certificate Revocation: When Not To Trust
Browsing againI found that I had to stop and restart my broswer in order for the certificate to “take”. I think it caches old results from the previous attempts. After a restart, I broswed again to the secure area of my website. I was presented, again, with the security alert message. But if you created a certificate which matches the name of your website, you should see this picture instead. After accepting that server certificate, I was presented with the list from before, only this time, it contained my imported certificate. I selected that certificate. Had I had more than one certificates installed on my browser, I would have choosen the right one for the site I’m browsing. After the certificate was selected, the server authenticated me, and I was allowed into the secure area of my website.
I thank the following people, who appear in no particular order, for their help in composing this article.
- Ryan Wamsley
- Pointing out some errors and suggesting some additions.
- Sean O’Riordain
- Reviewing, providing some hints, and some terminology lessons.
- Yonatan Bokovza
- Suggestions for clarification, initial review.
- Sylvain Maret
- For reminding me about CRL
SSL is a protocol for ensuring that your communications are encrypted and secure. OpenSSL is an implementation of SSL. Certificates are used to ensure people and/or websites are who they say they are. You can use SSL client certificates to restrict access to various areas of your websites. Or indeed the whole website (I didn’t cover that part, but that is easily extended; read the modSSL how to). The above should get you started. If you had to do something different, please add your comments.