What is a digital certificate?

A digital certificate is a public key that has been digitally signed by a trusted party, known as a Certificate Authority (CA). Digitally signing a public key assures the key has not been tampered with.

If you are not familiar with public keys or digital signatures, please take a moment to read "What is a digital signature?" (you should find it in the same folder you found this FAQ).


The Problem

For asymmetric encryption to work properly, public keys must be delivered in a fashion that guarantees the integrity of the key. If you have a public key that you think belongs to your friend or business partner, but in reality it belongs to an attacker, you have lost the security benefits of asymmetric encryption.

As an example, let's imagine that Alice wants to send a digitally signed message to Bob. Unfortunately, Bob does not have Alice's public key, so he cannot validate the signature. Alice attempts to solve this problem by sending her key to Bob:

Alice Bob
Alice's Public Key ----------------------------->
Alice's Message ----------------------------->
<-------------------------------- Bob's response

Bob now has Alice's public key, as well as the digitally signed message. Bob breathes easier knowing the message was not tampered with. In reality, Alice and Bob are susceptable to a "man-in-the-middle-attack".

In this attack, Alice's key is substituted with the key of a malicious person, Charlie:

Alice Charlie Bob
Alice's Public Key --------------------> Charlie's Public Key ------------------->
Alice's Message ---------------------> Charlie's Altered Message ------------>
<------------------------------- Charlie's Altered Response <--------- Bob's Response

Alice sends her public key to Bob, but it is intercepted by Charlie. Charlie swaps his public key with Alice's and sends it to Bob. Bob now has Charlie's key, but thinks it is Alice's key.

Alice signs her message and sends it to Bob. Again, Charlie intercepts the message. Charlie alters the message, throws Alice's signature away, and replaces it with a signature he creates with his own private key. Charlie sends the altered message to Bob.

Bob uses Charlie's public key to verify the signature that Charlie created. Although Bob is actually validating a signature created by Charlie, he thinks it is Alice's signature.

Bob sends a response to Alice, which Charlie intercepts and modifies. Neither Alice or Bob know their messages were altered.

Charlie could be thwarted if Bob had a means of proving the public key he received belonged to Alice.


The Solution

Digital certificates solve the problem Charlie represents. As mentioned earlier, a digital certificate is a public key that has been digitally signed by a trusted third-party (often called a Certificate Authority, or CA). Digital certificates also contain miscellaneous information such as the identity of the CA, the name of the entity the certificate was issued for, and expiration dates.

In our example, Trent will be our CA. Both Alice and Bob trust Trent, and they both have Trent's public key.

Alice creates a Certificate Signing Request (CSR). The CSR contains some basic identifying information about Alice, as well as Alice's public key. Alice sends her CSR to Trent using a secure means, such as SSL, registered mail, or perhaps delivers it in person. Trent, having good reason to believe he actually received Alice's public key, digitally signs Alice's key with his own private key. Anyone with Trent's public key can validate Alice's certificate.

So, what's the big deal? Why don't we just use a courier to get Alice's key to Bob in the first place? Presumably, Alice will want to use her public key with many people. Instead of taking the time to carefully deliver her public key hundreds or thousands of times, she only has to do it once (when she delivers it to Trent). She can send her digital certificate to anyone who wants it by any means available (such as email).

Alice does not have to worry about an attacker swapping out her public key, because Trent's signature would show the certificate had been tampered with.

For example, Alice sends her certifcate to Bob. Charlie intercepts the certificate and swaps Alice's public key with his own, and sends it to Bob. Bob attempts to validate Trent's signature (remember, Trent signed Alice's key to make the certificate). Bob is unable to validate Trent's signature, indicating the certificate has been tampered with. Bob knows he cannot trust the key in the certificate, and Charlie has been thwarted.


Trusted Root Certificates

You may have noticed a problem with trusting Trent's public key. Digital certificates only work if you can be sure you have the CA's public key, and it seems we are back at square one, when we needed a means of validating Alice's public key. How do we know we really have Trent's public key?

Certificate Authorities sign their own certificates. The self-signed certificate is often called a Trusted Root Certificate. A self-signed certificate is useful because it has identifying information, but it still cannot be validated unless we know we have the real public key of the CA.

The solution used by the well-known CAs is to flood the world with their public keys. The Trusted Root Certificates of well known CAs are imbedded in popular applications that use asymmetric encryption.

Your web browser is a good example, assuming it supports HTTPS. Internet Explorer, Netscape Navigator, Konquerer, Opera, and other popular web browsers already have the trusted root certificates of popular CA's embedded in them. For example, if you are using Internet Explorer 6.0, you can see these embedded certificates by selecting Tools-> Internet Options-> Content-> Certificates-> Trusted Root Certificates.

By having the trusted root certificates of the well-known certificate authorities, your software can easily validate a majority of the certificates it comes in contact with.