M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering Handout 20 - April 3, 2002

Hands-on 6: Web Certificates

Note: this hands-on is new for Spring 2003, and will have bugs. You are encouraged to check back frequently for revisions and clarifications. Please send questions or bug reports to 6.033-tas@mit.edu.

The goal of this hands-on is to give an introduction to X.509 certificates and how the Web uses them to authenticate servers via the Secure Sockets Layer (SSL) protocol. Certificates and Certificate Authorities (CAs) are described in detail in Section G of chapter 6 in the class notes. In addition, some basic material on certificates can be found at http://www.rsasecurity.com/rsalabs/faq/4-1-3.html.

X.509 certificates

X.509 certificates bind a public key to a "subject" field, which describes a person or entity. (The certificate typically also contains restrictive attributes limiting its use to a certain period and for certain purposes.) For example, a server certificate might contain the following subject:

/C=US/ST=Massachusetts/L=Cambridge/O=Massachusetts Institute of Technology/OU=Information Systems/CN=webmail.mit.edu

This certificate corresponds to an entity located in Cambridge, Massachusetts, US, in the Organizational Unit Information Systems of the Organization Massachusetts Institute of Technology. Most importantly, it indicates that the Common Name of the entity is webmail.mit.edu: the CN field of Web server certificates is always the DNS name of the Web server. For other types of certificates, the Common Name might be a person's name, or a description of the role of the public key.

Certificate chains

When you connect to a secure Web page (such as this hands-on accessed via HTTPS instead of HTTP), your browser will typically inform you of this with a "lock" icon in the status bar. Double-clicking on the lock should give you the Page Info for the current page, which should include a button to view the server's certificates. (Page Info can often also be accessed via a menu option.) In some modern Web browsers (for example, Mozilla 1.2.1 on Athena), this will also show the certificate chain the browser used to reach a root CA from the server's certificate.

The command-line openssl s_client program initiates an SSL connection to a server and prints diagnostic messages, including the server certificate chain sent to the client. Type the following command at the Athena prompt: 

% openssl s_client -connect webmail.mit.edu:443
This connects to the SSL server running on port 443 (the standard port for HTTP over SSL) on the server webmail.mit.edu.

It first prints the results of server certificate verification (in this example, it should fail); certificates are identified by their subject fields. s_client next prints the certificate chain sent from the server to the client; the s: lines correspond to a certificate's "subject", while the i: lines correspond to its "issuer". Next, it prints just the server's certificate, encoded in a format known as PEM (named after Privacy Enhanced Mail, an older protocol which, like SSL, uses X.509 certificates). It then prints a list of acceptable client certificate CAs, if the server specified any. Finally, it displays some summary diagnostics about the established SSL connection, and waits for input from the user. For example, typing GET / HTTP/1.0 followed by two carriage returns will cause the server to return its root page over the secure channel. Alternatively, simply typing Control-D or Control-C into the terminal will shut down the connection (the former does a "soft" close, while the latter does a "hard" shutdown).

In the previous example, s_client could not verify the server's certificate, because it was not provided with any trusted base of root CA certificates. Download the files mit-ca.pem and lcs-ca.pem into your home directory; these are root CA certificates in PEM format. You can view the structure of certificates in PEM format with the openssl x509 command: 

% openssl x509 -in mit-ca.pem -text -purpose
% openssl x509 -in lcs-ca.pem -text -purpose
In addition to viewing the root CA certificates, try saving the webmail.mit.edu certificate into a file and viewing it with openssl x509.

The simplest way to make the root certificates available to s_client is to concatenate them into a single file: 

% cat mit-ca.pem lcs-ca.pem > root-cas.pem
Then, add -CAfile root-cas.pem to the s_client command line. It should now be able to verify the webmail.mit.edu server certificate. In the language of the class notes, the -CAfile option means "the public keys in the specified certificates speak for all SSL servers".

  1. Use s_client to connect to webmail.mit.edu, student.mit.edu, and ca.lcs.mit.edu. (Note that student.mit.edu shuts down for backup early every morning, so do this before midnight.) Copy the verified certificate chain diagnostic from each into your assignment. Also, draw a box-and-arrows diagram showing which certificates certify which other certificates.
  2. Make a list of everything that you must trust in order to be confident that s_client is really connected to the correct server and not to an imposter.
  3. What is the problem with the way you obtained the MIT and LCS root CA certificates? Suggest how this could have been made more secure.
  4. Which CAs issued the root certificates mit-ca.pem and lcs-ca.pem? Why might this signature be useful?
  5. How does the structure of the ca.lcs.mit.edu certificate chain differ from the other two? How might this be an advantage? A disadvantage?
  6. How does the LCS root CA relate to the lcs.mit.edu DNS domain? How does the MIT root CA relate to the lcs.mit.edu DNS domain?
  7. In general, how does the SSL certificate hierarchy (of CAs) relate to the DNS hierarchy (of domains)? Why might this be a problem?

Please turn in the answers to these questions in Thursday's recitation.

Go to 6.033 Home Page Questions or Comments: 6.033-tas@mit.edu