| Create | Jack’s Public Key | |
| Key Pair | |
| Jack | | |
| | Jack’s Private Key | |
| Identity Info + | Jack’s Private Key |
| (Stays Private) |
| | |
| Jack | | |
| Jack’s Public Key | |
| | | Identity Info + |
| | | Jack’s Public Key |
| | | Preliminary Certificate |
| Identity Info + | One-Way Function/Hash Function |
| |
| Jack’s Public Key | Encryption |
| Digital Signature | |
| Jack’s self-signed | |
| Certificate | |
Figure 21 - Self-Signed Certificate
Basically, Jack’s private key does the signing on his public key certificate. A root (top of the chain) certificate authority is going to go through the same process. So why is it okay for a Root CA to have a self-signed certificate but no one else to have one? Well, it is all about trust. There is no “higher” level of trust then the top level certificate authority. Therefore, in our previous examples, John and Jack must choose a particular certificate authority that they both trust. In most cases, there is a hierarchy of certificate authorities at customer sites. This forms what is known as a certificate chain and there is a top level CA or Root CA where the ultimate trust resides.
Also, we should take care to point out that there is usually a difference between Internet trust using certificates and Intranet trust using certificates. Internet trust will involve well-known certificate authorities like Verisign and Entrust. However, Intranet models usually revolve around Microsoft’s certificate authority that comes with Windows 2003 server. Each company establishes their own Public Key Infrastructure (PKI) that includes an entire policy around certificates.
There is one other important thing to cover about certificates. Each certificate has a one or more “certificate purposes” that the certificate can be used for. For example, a Jetdirect self-signed certificate will have two purposes: client authentication and server authentication. A root certificate
19
