authority’s self-signed certificate will have a purpose to create certificates for other entities, usually subordinate certificate authorities. It may be of help to go back to our driver’s license example to explain certificate purposes. A driver’s license purpose is to clearly identify the person it has been issued to and to show that that person has the right to drive in a given state. Because a driver’s license also lists the date of birth, it is often used to determine age and whether the holder is able to purchase various products that have age limitations. This purpose is actually above and beyond the original purpose of a driver’s license. In the digital certificate world, this additional purpose would more than likely not be allowed.
So, can’t someone who is not a CA create a self-signed certificate with the ability to create other certificates for entities? Sure they can! Will this be trusted? Probably not. However, if an unethical hacker can somehow install a CA certificate of their own choosing into your trusted certificate store, you will be in for a lot of problems. They will now have the ability to fool the browser and other applications into connecting to malicious sites that are now “trusted” and the browser or other application will not be able to detect it. Keep that certificate store protected!
SSL/TLS Protocol Basics
Okay, now that we know something about SSL/TLS basics and a PKI, we can talk about how the SSL/TLS protocol goes about its business. While there are many interesting protocol specifics, we are only going to talk about common situations with HP Jetdirect and “normal” SSL/TLS protocol interactions. A basic breakdown of SSL/TLS protocol structures is shown in Figure 22:
Figure 22 - SSL/TLS Protocol Structures
(Note: In order to enhance understanding, this diagram was simplified. Please refer to the many excellent SSL/TLS references for a more complete and more accurate protocol description). SSL/TLS makes a strong distinction between a Client and a Server. Unlike a protocol like IPsec where each endpoint is a peer, SSL/TLS has specific roles for each endpoint. The endpoint initiating the SSL/TLS connection, like a web browser to a secure shopping site, is the client. The endpoint responding to the connection request is the server. There are two primary phases in an SSL/TLS connection: The handshake and then the data transfer. The handshake messages get everything started. We can see the start of them if Figure 23.
