Back | Next | Contents Cams Administrator's Guide

SSL/TLS Mutual Authentication Primer

Secure Sockets Layer (SSL) is a cryptographic protocol which provides secure communications for e-commerce, e-mail and other data transfers without eavesdropping, tampering or message forgery. SSL was first introduced by Netscape in 1996 with version 3.0 of the Netscape browser. It's successor, Transport Layer Security (TLS), is an IETF standard protocol first defined in RFC 2246. The term SSL generally applies to both protocols unless otherwise specified.

From a high-level, SSL has three capabilities that may be used independently or in combination to secure content transport (or the network pipe). These capabilities are:

  1. Authenticating a (web) server to a client (usually a browser)
  2. Encrypting client/server communications
  3. Authenticating a client to a server

SSL implementations rely on the user of digital certificates, which verify the identity of people and organizations. Certificates are electronic credentials that bind the identity of the certificate owner to a pair (public and private) of electronic keys that can be used to encrypt and sign information digitally. These electronic credentials assure that the keys actually belong to the person or organization specified. Messages can be encrypted with either the public or the private key and then decrypted with the other key.

Each certificate contains at least the following information:

  • Owner's public key
  • Owner's name or alias
  • Expiration date of the certificate
  • Serial number of the certificate
  • Name of the organization that issued the certificate
  • Digital signature of the organization that issued the certificate

Certificates can also contain other user-supplied information, including a postal address, an email address and basic registration information, such as the country or region, postal code, age and gender of the user.

Most public web sites only use SSL to authenticate the web server to the client while the client remains unauthenticated to the web server. Web server authentication is easily implemented and sufficient for establishing an SSL connection while requiring users to install X.509 client certificates is prohibitively expensive and difficult for general Internet use. However, web servers can be configured to request or require that the client authenticate using an X.509 certificate. This is known as mutual authentication and is required when configuring Cams to use X.509 certificate authentication within a login module. In other words, Cams relies on successful SSL client authenticate so that the client certificate is automatically transmitted with the HTTPS request.

Web servers include instructions on how to configure them for SSL. Though instructions vary depending upon the web server, the basic ingredients are the same. An X.509 certificate, which has been signed by a trusted certificate authority (CA) or intermediary, must be installed in the web server. The word trusted implies that the browser must be configured to trust the CA that signed the web server certificate by importing its publicly available root or top-level certificate. Popular CA root certificates are pre-installed by default in all browsers and as such are intrinsically trusted. You must manually install root certificates for any CA you implement. These root certificates establish a chain of trust with the X.509 certificates they sign. If you don't install a root certificate for your CA in a browser, then your browser will prompt you to ask if you want to accept or trust the web server certificate. That's not the case for client certificates supplied from your browser to the web server. In that case, you MUST install the CAs root certificate in the web server or SSL authentication will fail (e.g., there's no practical way for a web server to prompt an administrator to accept or trust client certificates on a one by one basis). Also, CAs distribute Certificate Revocation Lists (CRLs), which are lists of serial numbers for certificates that have been revoked by the CA. Both browsers and web servers can be configured to reference or import CRLs.

When properly configured, the browser and web server use a process known as handshaking that requires no human interaction:

  • The browser sends a request for SSL communication to the web server and negotiates the cryptographic algorithms that will be used.
  • The web server provides its certificate to the browser and (optionally) requests a certificate from the browser.
  • The browser validates the web server certificate using the CA's public key and checks the CRL, if available.
  • If the web server's certificate is valid, the browser creates a master secret key, encrypts it with the web server's public key and transmits it to the web server. If the web server requested client authentication, the browser also includes its certificate (the user may be prompted to selected a client certificate to use if so configured).
  • If the browser transmitted a certificate, the web server verifies it using the CA's public key and the CRL.
  • The browser and web server use the master secret key to generate the symmetric session keys. The use of symmetric keys instead of the public keys from the digital certificates provides better performance.

When a browser or web server receives a certificate, successful authentication requires that the following questions evaluate to true:

  1. Is today's date within the certificate's validity period?
  2. Is the issuing CA for the certificate a trusted CA?
  3. Does the issuing CA's public key validate the issuer's digital signature?
  4. Is the certificate's serial number NOT listed in the current CRL? Or, is the client certificate found in the organization's LDAP directory?
  5. Does the domain name in the server's certificate match the domain name of the server itself (server authentication only)?

There is quite a bit more complexity under the hood, but we'll leave it up to you and your Google skills to find out more. The following sections provide some starting points.

Implementing your own Certificate Authority (CA)

A Certificate Authority is an entity that issues trusted digital certificates. A CA can be either a third party or implemented internally within an organization using commercial or open source software. A CA issues public key certificates, which states that the CA attests that a certificate's public key belongs to the person, organization or entity noted in the certificate. A CA's obligation is to verify an entity's credentials, so that relying parties can trust the information in the CA's certificates. If the user trusts the CA and can verify the CA's signature, then they can also verify that a public key belongs to the certificate owner.

You can purchase certificates from online CAs such as Verisign, Thawte or Comodo or you can implement your own CA. Commercial vendors including Microsoft, Red Hat and Sun Microsystems provide software to do so. You can also use OpenSSL, included free with most Linux distributions. OpenSSL is a open source toolkit that implements the SSL v2/v3 and TLS v1 protocols as well as a general purpose cryptography library. Various documents are available on how to configure OpenSSL for use as a CA. Another appendix in the Cams Administrator's Guide documents Configuring Apache 2.0 for SSL/TLS Mutual Authentication using an OpenSSL Certificate Authority. Another alternative is to use, which is a community driven CA that issues free certificates to the public.

Configuring Web Servers for SSL

SSL configuration instructions are specific to the web servers you use and are provided by the organizations that supply and support them. For your convenience, the following documentation links are instructions for some of the most common web servers supported by Cams:

Importing X.509 Certificates into Browsers

Commonly, browsers import X.509 certificates in PCKS12 binary format, though other formats may also be acceptable. Brief instructions are provide here for Internet Explorer 6.0 and FireFox 1.5.

Internet Explorer 6.0

To import a certificate, start IE and follow the instructions below:

  1. Navigate to the Tools menu and click Internet Options
  2. Click the Content tab
  3. Click the Certificates button
  4. Click the Import button
  5. Follow the wizard instructions to select the certificate file
  6. Enter the password you used to protect your certificate and private key
  7. Import client certificates into the Personal store and root certificates for the CA that signed the web server certificates into the Trusted Root Certification Authorities store
  8. Click the imported certificate and then the View button in the Certificate intended purposes group box. A dialog box will popup. Click the Details tab and then the Edit Properties button. Make sure that the Client Authentication option is checked.

For more detailed information, please see Microsoft Internet Explorer 6 Resource Kit, Chapter 6 - Digital Certificates.

FireFox 1.5

To import a certificate, start FireFox and follow the instructions below:

  1. Navigate to the Tools menu and click Options
  2. Click the Advanced icon
  3. Click the Security tab
  4. Click the View Certificates button
  5. Click the Import button and select the certificate file
  6. Enter your master password for the Software Security Device
  7. Enter the password you used to protect your certificate and private key

Back | Next | Contents