This post is an attempt to provide a simple introduction to security certificates, as used on the web – also known as PKI (public key infrastructure) and X.509 (a series of standards).
Acknowledgement: The title of this post is shamelessly stolen from a suggestion in a thread at the opensuse forums.
Security certificates are part of what we use when sending encrypted data to a server (web server, mail server, etc).
Introduction: We use encryption, when we want to protect information from being stolen. However, encryption by itself is insufficient. Suppose that you have some private information that you want to send to your bank. If you encrypt that information, but you mistakenly send the information to thieves and encrypt it in a way that the thieves can read it, then you have not protected the information at all. The certificate system is supposed to provide the basis for you to be able to trust that you are sending the data to the intended people (your bank, not the thieves), and that you have encrypted it in a way that only the intended recipients can read it.
Public key encryption: The system is built on the use of public key encryption. With public key encryption, there are two keys. One of those keys is made public and the other is kept private and known only to the owner of the key. In one typical use, a message is encrypted using the public key. Then only the owner of the private key can decrypt it. In an alternative use, a special message is encrypted with the private key, and can be decrypted with the public key. In this alternative use, the message is typically a signature, and the arrangement is intended to allow only the owner of the private key to create the signature while anybody can verify that the signature is correct (because the public key is made public so available to anybody).
The mathematical relationship between the public key and the private key is sufficiently complex that it would be very difficult to compute the private key from the known public key.
What’s in a certificate? A certificate is just a document (in this case, a digital document for use in computer networks). It contains the name of the owner (or alleged owner) of the certificate. That owner name could be a web site name, an email address, etc. There can be other identifying information. There is a begin date and an expiration date, and the certificate is only useful between those dates. And there is a list of constraints on the permissible uses of the certificate.
In addition to that information, there is a public key. The public key is digital information, mainly of use by software. The owner of the certificate should have the corresponding private key.
The certificate itself is signed, and the signature is part of the certificate. It is a digital signature, generated with a private key. The purpose of the signature is to certify the validity of the information in the certificate. That’s where the name “certificate” comes from. The certificate should not be trusted unless the signature has been verified. The verification step requires using the public key of the signer. The signature is generated is such a way that if any of the important information in the certificate has been tampered with, then the signature will not verify.
The CA or Certification Authority: A certificate is signed by a CA. When you trust a certificate, you are implicitly trusting the CA. What you can trust, and how trustworthy a CA is, has to be decided outside of the certificate system. In many cases, CAs have web sites where they state their certification policies. (More about this later).
Who appoints the CA? The CA appoints himself or herself or itself. Anybody can appoint himself a CA. For example, I have appointed myself as a CA, though my CA certificate has now expired.
This might sound scary, but it isn’t. Although I have appointed myself as a CA, and have signed some server certificates, the chances are that you will never come across those certificates. If, by some chance, you were to come across such a certificate (browsing a web site using a certificate I have signed), your browser would give you a certificate warning saying that it did not know how to verify the CA signature that I had created to sign that certificate.
If I were running a private web site, then I might distribute my CA certificate to members of that private group. They could then add that to their browser certificate store so that they could use my private site without seeing certificate warnings. Anybody else would see a warning.
The fact that CAs appoint themselves is not an actual problem.
The hierarchy: The certificate system is one of hierarchical trust. There are several parallel hierarchies. At the top of the hierarchies, are the root CAs. The root CAs are the ones that are self-appointed. The root CA has a certicate that is used for certifying other certificates. The root CA certificate is itself signed (thus certified). It is self-signed. Roughly speaking, that the root CA certificate is self-signed indicates that the CA has certified itself. That may sound silly, but is actually important. Since a certificate will not verify if there has been tampering, the signature on the root CA certificate is a protection against tampering.
In a simple case, the root CA can directly sign a server certificate. Verification of the server certificate then requires access to the CA certificate. In a more complex case, the root CA can sign a secondary CA certificate, and that secondary CA can then sign a server certificate. There can be several levels.
The constraints that are part of a certificate are what indicate whether the certificate is allowed to be used as a secondary CA certificate.
The certificate chain: In order to verify a certificate, you (or your software) needs access to the chain of certificates. That would include the root CA certificate, the certificate of a secondary CA signed by the root, and so on, down to the server certificate that you are trying to verify.
If you access a well run web server, that server will provide the server certificate and the certificate chain (except for the root CA certificate). It will normally also provide the root CA certificate, but your browser won’t use that in normal use.
How does trust work: Typically your software vendor (operating system vendor of browser vendor, for example) will provide a bundle of root CA certificates with the software that the vendor supplies. The root CA bundle might also contain some secondary CA certificates, depending on the practices of the software vendor.
Your software, by default, is set to trust any CA certificate in the bundle provided by the software vendor. Usually, the software allows you to tweak this. There is typically a provision where you can mark some of the provided certificates as untrusted, and where you can add some additional CA certificates which you decide for yourself that you want to trust.
When you visit a site that uses certificates, your client software (typically a browser or mail client) asks the server for its server certificate. The server should provide a chain of certificates, as needed. Your software starts by trusting the root store of certificates provide by your software vendor, though it should be verifying those signatures to protect against tampering. Then your client software should verify the signatures all the way down the chain to the server certificate. It should also check the dates on certificates (that they have not expired). And it should check the name on the server certificate to ensure that it matches the site that you are visiting. If some of those checks fail, the sofware should alert you.
Once your client software has verified the certificates, it use the public on the server certificate to establish an encrypted connection to the server. Since only the owner of that certificate has the associated private key, this ensures that only the certificate owner can read this encrypted connection.
What can you trust: If the verifications all succeed, then you can trust that the certificate was signed by a CA that you trust. Beyond that, how much you can trust depends on the CA policies. Most CAs do some checking of the identity of the server (the name of the certificate owner, as shown on the certificate). However, most do not check whether the server runs an honest business. Some CAs may do those extra checks, but their certificates will cost more (a cost paid by the server).
The record of CAs has been spotty. Some CAs have high standards and inspect business records before they will sign that they trust the identity of a server. Other CAs do only more skimpy checks. Even the most stringent of CAs can make mistakes and sign certificates that they should not have signed. And this all depends on your software vendor, and what root CA certificates that your software vendor chooses to include in the provided bundle.
As far as I know, the major software vendors are reasonably careful about which CA certificates they distribute. But being reasonably careful is not a guarantee that they never make mistakes.
The system mostly works as intended, in spite of its imperfections. But the final decision on what to trust is yours. Roughly speaking, that means that if something goes wrong, you probably won’t be able to sue the CA.
Final note: if you were looking for more technical detail than I have provided, there are sites for that. A good search engine should get you to such sites. This post was intended to give a basic introduction to the system.