A digital certificate is a digital document that certifies that a certain public key is owned by a particular user. This document is signed by a third party called the certificate authority (or CA). The following illustration might help get an idea of what a digital certificate is:
Of course, the certificate is encoded in a digital format (no, you don't get a paper diploma so you can brag to your pals that "you really are who you claim to be" :-) The important thing to remember is that the certificate is signed by a third party (the certificate authority) which does not itself take place in the secure conversation. The signature is actually a digital signature generated with the CA's private key. Therefore, we can verify the integrity of the certificate using the CA's public key.
Having a certificate to prove to everyone else that your public key is really, truly, honestly yours allows us to conquer the third pillar of a secure conversation: authentication. If you digitally sign your message with your private key, and send the receiver a copy of your certificate, he can know for sure that the message was sent by you (because only your public key can decrypt the digital signature... and the certificate assures that the public key the receiver uses is yours and no one else's)
However, all this is true supposing you trust the certificate. To be more exact, you have to trust the CA that signs the certificate. Believe it or not, there are no fancy algorithms to decide when a CA is trustworthy... you must decide by yourself whether you trust or don't trust a CA. This means that the public-key system you use will generally have a list of 'trusted CAs', which includes the digital certificates of those CAs you will trust (each of these certificates, in turn, include the CA's public key, so you can verify digital signatures).
You have to decide which CAs make it into the list. Some CAs are so well known that they are included by default in many public-key systems (for example, web browsers usually include VeriSign and GlobalSign certificates, because many websites use certificates issued by those companies to authenticate themselves to web browsers). Of course, you can add other CAs to the 'trusted list'. For example, if your department sets up a CA, and you trust that the department's CA will only issue certificates to trustworthy people, then you could add it to the list.
Now that we've gone through the basics, let's take a look at the format in which digital certificates are encoded: the X.509 certificate format. An X.509 certificate is a plain text file which includes a lot of information in a very specific syntax. That syntax is beyond the scope of this document, and we'll simply mention the four most important things we can find in an X.509 certificate:
Subject: This is the 'name' of the user. It is encoded as a distinguished name (the format for distinguished names will be explained next)
Subject's public key: This includes not only the key itself, but information such as the algorithm used to generate the public key.
Issuer's Subject: CA's distinguished name.
Digital signature: The certificate includes a digital signature of all the information in the certificate. This digital signature is generated using the CA's private key. To verify the digital signature, we need the CA's public key (which can be found in the CA's certificate).
As you can see, this information we can find in an X.509 certificate is the same which was shown in the illustration at the beginning of this page (name, CA's name, public key, CA's signature).
Names in X.509 certificates are not encoded simply as 'common names', such as "Borja Sotomayor", or "Certificate Authority XYZ", or "Systems Administrator". They are encoded as distinguished names, which are a comma-separated list of name-value pairs. For example, the following could be my distinguished name:
O=University of Deusto, OU=Department of Software Engineering, CN=Borja Sotomayor
So what do "O", "OU", and "CN" mean? A distinguished name can have several different attributes, and the most common are the following:
O : Organization
OU : Organizational Unit
CN : Common Name (generally, the user's name)
C : Country
We mentioned earlier that your 'trusted CA list' includes the certificates of all the CAs you decided to trust. At that point, you might have asked yourself: And who signs the CA's certificate? The answer is very simple: Another CA! This allows for hierarchies of CAs to be created, in such a way that although you might not explicitly trust a CA (because it's not in your list), you might trust the higher-level CA that signed its certificate (which makes the lower-level CA trustworthy)
The following illustration might make things a bit clearer:
In the illustration, my certificate is signed by Certificate Authority FOO. Certificate Authority FOO's certificate is, in turn, signed by Certificate Authority BAR. Finally, BAR's certificate is signed by itself (we'll get to this in a second).
If you receive my certificate, and don't explicitly trust CA FOO (the issuer of my certificate), this doesn't automatically mean my certificate isn't trustworthy. You might check to see if CA FOO's certificate was issued by a CA you do trust. If it turns out that CA BAR is in your 'trusted list', then that means that my certificate is trustworthy.
However, notice that the higher-level CA (BAR) has signed its own certificate. This is not uncommon, and is called a self-signed certificate. A CA with a self-signed certificate is called a root CA, because there's 'no one above it'. To trust a certificate signed by this CA, it must necessarily be in your 'trusted CA list'.