The manner in which certificates are used and issues is a tad more complex. Before actually obtaining a certificate, a user must first generate a pair of keys – these are what are commonly referred to as the private and public key. People always seem to be confused about how these keys are used, so I’ll spend a little time on that now. Basically, if you want to be part of a PKI, you will need a private and public key pair, and a valid certificate. The way in which this happens differs slightly between systems, but the gist of things is usually the same – I’ll follow the Windows 2000 way. The first step is creating the key pair, which is done by something called the Cryptographic Service Provided (CSP), basically a program running on your system, which is accessed by a programming interface called the CryptoAPI. This will result in a key pair being created, made up of both a public and private key. The private key is not meant to be shared (as I’ll soon explain) and is secured by the operating system. The public key is free to go to anyone, and will need to be accessed by those looking to securely communicate with you. After the key pair has been generated, the next step is requesting a certificate, from some predefined Certificate Authority. This might be a server in your internal organization, or it might be a public CA such as Verisign. Whatever the case, you must submit a request, and that request includes information such as your name, email address, contact information, and so forth (what you need to provide depends on the CA and type of certificate). The request also includes a copy of your public key. Based on rules that have been set up by the CA, a certificate may or may not be issued to you. If it is, the file that is created contains the information that you have submitted, as well as the digital signature of the CA – proof that they choose to verify your identity. Of course, this proof is only as good as your (and other people’s) trust in the CA. This is another important fact that we’ll look at shortly.
The manner is which these keys and certificate are used vary by the services you wish them to provide, but the easiest example is always email. Imagine that two users, Sally and Bob, wish to send each other email. A standard email message is not encrypted and can potentially be read by others as is moves across the network or Internet. Not only that, but another user could send email to Sally pretending to be Bob, and so things get even more complex. Certificates help with this, but we need to understand a little more about private and public keys. Lets begin by taking a look at sending an encrypted message. Imagine that Bob wants to send an encrypted email to Sally. In order to do so, Bob needs a copy of Sally’s public key. How he can obtain this is via email from Sally, via a download from a directory service or website, and so forth. This shouldn’t be a problem, because Sally’s public key has a rather limited use – the messages that it encrypts can only be decrypted by Sally’s private key. In other words, Sally’s public key is used by others to send encrypted messages to Sally only. Unless Sally’s private key is stolen somehow, people will be unable to read encrypted messages sent to her. Getting back to our example, lets say that Sally sends Bob her public key, the next question becomes how can Bob be sure that this message is really from Sally and not someone pretended to be Sally? This too can be handled via the user certificate. When Bob receives a message digitally signed by Sally, he can verify her identity according to the CA signature on her certificate. Bob can only read this signature by the CA if he has a copy of the CA’s public key. Just to know, your web browser and email client software automatically include public keys for many certificate authorities. If the CA signature checks out, and the certificate contains all of Sally’s information, then you can be reasonably sure that the request did, in fact, some from Sally.