X.509 Certificates and Information Access

1. Introduction

Public key encryption was first introduced into web browsers by Netscape but was rapidly taken up by Microsoft in IE. The technology involved in the browser certificate infrastructure is based on the X.500 directory standards. The relevant certificate standard is X.509. The X.509 certificate format differs from that employed in PGP and the trust model is significantly different as well. The X.509 model is hierarchical and relies on Certificate Authorities which issue certificates to their staff, members or clients.

This session takes a practical look at certificates, certificate authorities and access control in the web browser environment and gives the opportunity to think about how useful such technology might be in a HE/FE information environment.

2. Certificate Authorities

If one is to trust a digital certificate that has not physically been given to one directly by the signer, then there is a need for 'trust at a distance'. That is one trusts something because someone that one trusts says it is alright to do so. The 'someone' in the world of digital cryptography is often a Certificate Authority (CA).

What is a Certificate Authority?

A Certificate Authority (CA) is a body that 'signs' a declaration attesting to certain information about something or someone being what it claims to be. An example in the paper world is a University Registry issuing a Degree Certificate. It places a signature and seal onto a document which details the degree awarded and the person to whom it applies, after careful checking that the information is correct. In the world of digital certificates, this signature/seal is information about the CA which is bound to the credentials of the someone or something and then encrypted with the CA's private key. The information about holder and issuer of the certificate can be inspected using the CA's public key, which is made freely available.

An individual or body (like a university), which wishes to make use of such 'signed' certificates in the digital world needs to either become its own CA (in the same way that it does with Degree Certificates) or pay a Trusted Third Party (such as VeriSign or Thawte) to either sign all certificates or a single institutional certificate which it can then in turn use to sign other certificates within the institution.

Certificate Authority Certificates

Given that a University has established its own Certificate Authority, people who are to trust the certificates that it signs, need copies of the CA public key so that they can decrypt the credentials found on signed certificates and thus tell whether or not the certificate being presented is genuine or a forgery. The CA certificate is simply a 'self-signed' certificate containing the public key of the Certificate Authority, which can be used to decrypt the signature on certificates which the CA has signed. This public key cannot be used to sign further certificates, just to check the signatures on other certificates.

3. Server Certificates

There are hundreds of thousands of servers around the world which claim to belong to specific organisations. How do we know when we access a web server www.amazon.co.uk that it actually belongs to a reputable Internet bookseller and not a conman who will take your credit card details and never send you anything in return?

What is a Server Certificate?

An answer to the above problem would be to install a certificate in the web server at www.amazon.co.uk which is signed by someone that we all trust to have checked out the credentials of the server owner before signing the certificate. In this way we can have a much greater degree of confidence that we are dealing with a well known Internet bookseller than would otherwise be the case.

What are SSL Enabled Web Servers?

Since all this certificate stuff actually involves strong encryption techniques, it makes sense that if you wish to be sure about who you are dealing with, you might conduct your whole transaction (asking for information, the information sent back and anything that you might send to the server - such as your credit card details) using encryption. Secure Sockets Layer (SSL) is a low level protocol which enables such encryption of transactions between server and client and, in the way that it was implemented in web servers/browsers, to use public key encryption to deploy X.509 digital certificates to authenticate the server and/or browser.

A web server which is SSL enabled (such as Apache running mod_SSL or Apache-SSL) provides for encrypted transactions and X.509 digital certificates. By default these services are offered on port 443 or to servers running https protocols rather than http.

Accessing an SSL-enabled Server without its CA Certificate Installed

The first practical exercise in this session is to see what happens if you try to access an https (SSL enabled server) using a browser which is not able to verify the authenticity of the certificate being presented by the server (because it has no knowledge of the CA which signed the certificate installed in the server).

Point your browser at the following web page:-

https://tyndrum.cent.gla.ac.uk/Intro.html

Try this in either or both of Netscape and IE and note the results in the spaces below.

a) Netscape

b) Internet Explorer

As part of this exercise you will have been hit with a number of dialog boxes and confusing questions. This is the experience that users get when they access SSL enabled servers which their browser is unsure whether or not to trust. The tone of the warnings is such that you might reasonably think that you are living very dangerously indeed by trusting such servers at all. The situation is of course no worse than trusting a regular http server without SSL, except that in this latter case you are communicating with the server in plain text rather than using strong encryption as is the case with the SSL enabled server.

Loading a CA Certificate into a Web Browser

Most browsers come with a whole set of CA certificates from the likes of VeriSign and Thawte already installed, but not of course our locally home grown CA. It would be much better if our browser was able to verify the certificate presented by our server which is signed by our own CA. To achieve this we have to install the public key certificate of the CA which issued the server certificate. In this case it is a body which calls itself 'Intranet Project CA'.

The procedure for doing this is slightly different in Netscape and IE, but both start with a visit to the following URL:-

http://tyndrum.cent.gla.ac.uk/smpcert.html

This page asks you to indicate which type of browser you are using and will send a file to your browser in a format appropriate to the browser concerned. The Netscape format is a ASCII encoded format called PEM, whilst the IE format is a binary format called DER. Both browsers guide you through the process of installing the CA certificate and both issue warnings about the dire consequences of doing so.

a) Netscape

If you wish to see the certificate which you have installed, do the following:-

1. Click on the padlock icon at the bottom left of your browser.
2. Under "Certificates" click on "Signers".
3. Scroll down the list to see the Intranet Project CA which you installed.
4. Highlight the Intranet Project CA and click on the "Edit" button to examine the certificate details.

b) Internet Explorer

If you wish to see the certificate which you have installed, do the following:-

1. From the "Tools" menu select "Internet Options".
2. Select the "Content" tab.
3. Click on the "Certificates" button.
4. Select the "Trusted Root Certification Authority" tab.
5. Scroll down the list to see the Intranet Project CA which you installed.
6. Highlight the Intranet Project CA and click on the "View" button to examine the certificate details.

Notes

The main point to bear in mind when installing a CA certificate is that your browser will subsequently trust any certificate signed by that CA. It is crucial therefore that the CA maintains excellent security, so that its signature cannot find its way onto dodgy certificates and that it has suitable policies and practices for the checking of the credentials of those presenting certificates to it for signature. In the case of VeriSign class 1 certificates, their security is excellent, but their checking policy is simply that the e-mail address presented in the credentials is deliverable and that the correct fee has been paid!!

Accessing an SSL-enabled Server with its CA Certificate Installed

Close your browser and restart it, so that it forgets that it has already seen our SSL enabled server and then repeat the first practical exercise and see what happens if you try to access an https (SSL enabled server) using a browser which is able to verify the authenticity of the certificate being presented by the server (because the CA certificate is now installed in the browser).

Point you browser again at the following web page:-

https://tyndrum.cent.gla.ac.uk/Intro.html

Try this in either or both of Netscape and IE and note the results in the spaces below.

a) Netscape

b) Internet Explorer

The result should be that all the warnings have gone away and it is as easy as accessing www.easyjet.com whose servers are signed by VeriSign which your browser also knows about!!

4. User Certificates

So far we have dealt with the problem of establishing confidence in who the server belongs to, but the server has no idea who you are. If we could deal with this problem, we could use such knowledge to control access to information.

What is a User Certificate?

A user certificate is similar to a server certificate except that instead of carrying credentials pertinent to a server, it carries credentials relating to an individual or group of individuals. A user certificate is slightly more complex from our point of view, since we have to deal with both the public and private keys. There are two ways to issue user certificates.

• Do all the work at the CA machine and give the user a file to take away which contains both the private key and the CA signed certificate. During the generation process the user will be required to provide a secret passphrase to protect his/her private key. Some institutions generate certificates en mass and store them in individual user file spaces on servers which the users have access to.
• Generate the keys in the user's browser (during which time the user will be required to provide a secret passphrase to protect his/her private key) and send the public key to the CA for certification as a 'Certificate Request'. The CA then returns the certificate to the e-mail address specified in the user's public key. CAs who operate in this way provide a web page which fronts a cgi script which causes the relevant things to happen.

Loading User Certificates into a Web Browser

For the sake of this session, we are all going to make use of a certificate which simply attests to the fact that we are taking part in this workshop. The certificate was generated for this purpose and the certificate and private key are stored in a PKCS#12 file on the server. This file is protected by a password, which is needed to install the certificate and private key in your browser. This password is NOT the passphrase which is needed to use the private key associated with the certificate. For this session we are not going to use the private key, so you do not need to have the private key passphrase.

Point your browser at the following file:-

http://tyndrum.cent.gla.ac.uk/certs/digicertwrsh.p12

and save it in the root directory of your C: drive.

a) Netscape

To install the certificate:-

1. Click on the padlock button at the bottom left of your browser.
2. Under "Certificates" click on "Yours".
3. Click the "Import a Certificate" button.
4. Create a password for your Certificate Store. This password is needed to access the certificates which you store in the cert7.db certificate and key3.db private key files which reside in your Netscape profile. If you lose the password, you lose all the certificates and private keys in your browser.
5. Identify the PKCS#12 file (which you downloaded) on your C: drive.
6. The password to this PKCS#12 file is 'dcwone'.

To examine the certificate once it is installed:-

1. Click on the padlock button at the bottom left of your browser.
2. Under "Certificates" click on "Yours".
3. Highlight the certificate and click on the "View" button to examine the certificate details.

b) Internet Explorer

To install the certificate:-

1. From the "Tools" menu select "Internet Options".
2. Select the "Content" tab.
3. Click on the "Certificates" button.
4. Select the "Personal" tab.
5. Click the "Import" button.
6. Identify the PKCS#12 file (which you downloaded) on your C: drive.
7. The password to this PKCS#12 file is 'dcwone'.

To examine the certificate once it is installed:-

1. From the "Tools" menu select "Internet Options".
2. Select the "Content" tab.
3. Click on the "Certificates" button.
4. Select the "Personal" tab.
5. Highlight the certificate and click on the "View" button to examine the certificate details.

Note that certificates are stored in the Registry in IE and are not protected by a password.

Using Users Certificates for Controlling Access to Information

Having installed a user certificate we can now use it to access web pages which are configured to require a certificate with certain attributes before the page may be seen.

The pages on the https://tyndrum.cent.gla.ac.uk document tree are as follows.

                                   |   
  --------------------------------------------------------------------
  |                      |                      |                     | 
 mars                 neptune                 pluto                 saturn
  |                      |                      |                     |
alpha.html           alpha.html             alpha.html            alpha.html
beta.html            beta.html              beta.html             beta.html
delta.html           delta.html             delta.html            delta.html

Explore the pages and see which ones you get access to and which you do not. A separate sheet which you will be given later will explain the conditions attached to access of each of the pages.

There is another certificate with different attributes available in the PKCS#12 file b-gatescert.p12 if you wish to install that and carry out further experimentation, its password is 'wjgtwo'.

5. Finally

To conclude this session, here are a few points about the use of X.509 certificates in a web environment.

• CA certificates issued by external trusted third parties are only necessary if you wish to have encrypted transactions with the general public (credit card transactions for instance), who will not have the opportunity to install your CA certificate and would have no particular reason to trust it even if you offered it to them.
• A local self-signed CA should be adequate for information access control within an institution.
• Certificates could be generated en mass and stored in an LDAP directory server for access by the users concerned via a password.
• In Netscape your CA certificate could be installed into a cert7.db file which you install in browsers as part of setting them up.
• The user profile in Netscape can be configured to be on a networked drive which is part of a user's personal filestore. Appropriate user certificates could be installed on that drive to be available to the user when they log in, and be unavailable to the next user if the first user logs out.
• Installing user certificates into the certificate store on a local drive would potentially make them available to any user of that machine (this is a particular problem with IE where they are stored in the Registry of the machine). In Netscape the effect of this could be mitigated by users having different personal profiles and use of certificate store passwords in situations where two or three different individuals share a machine (as opposed to public access machines).
• There is considerably more flexibility in access control via the attributes on X.509 certificates than access control via IP addresses.

6. Resources

Educause have a resource page dealing with PKI issues at:-

http://www.educause.edu/netatedu/groups/pki/resources.html

There is a good overview of Digital Certificates and Encryption in relation to SSL on the Novell site at:-

http://www.novell.com/documentation/lg/nas4nw/usnas4nw/nasnwenu/security.html

The Certificates used in this session were generated using the OpenSSL software from:-

http://www.openssl.org/

On the Apache Web Server, SSL is provided by mod_ssl from:-

http://www.modssl.org/

There are two documents which describe how to set up OpenSSL and use it to establish your own CA at:-

http://www.pseudonym.org/ssl/ssl_cook.html

http://www.pseudonym.org/ssl/wwwj-index.html
(title of this document refers to SSLeay but article is about OpenSSL)