The Role of a Certificate Authority (CA) in PKI

In Part 1 of this series on Public Key Infrastructure (PKI), I explained the basics of how Public-Private Key pairs are used to secure data. Also integral to this process is ensuring that the data originator and the data recipient can verify that the Public-Private Key pairs used to encrypt/sign data are authentic and not forged. If you remember from PKI Part 1, I introduced the basic PKI rule of ‘I sign with my Private Key, I encrypt with your Public Key’. By knowing this basic rule, you can readily understand the following that illustrates the importance of authenticating Public–Private Key Pairs.

Let’s say you are searching the Internet one day for an exotic gift for your significant other and you come across an online ad for BRASILIAEXPORTS.COM, a website selling rare wood figurines from Brazil. You click on the link, peruse the site and decide to place an order. The order form states that the only accepted method of payment is by credit card.

Wait a minute you think to yourself, how is my credit card going to be securely exchanged across the Internet? You know from previous ecommerce sites that a secure site should have a URL that is prefixed with https:// but this one reflects http:// instead. That makes you nervous, so you alter the URL to https:// and press enter.  An error message then pops up stating ‘Could not verify this certificate up to a trusted root CA. Would you like to continue?’

Ignoring the error, you decide to continue anyway. The URL bar turns red but the lock icon appears next to it indicating a secure session. Whew! That was close. Now you can type in your credit card and be confident that it is encrypted while traversing the Internet.

OK, reality check. What just happened was the equivalent of a thief mailing you a lockable box that is currently unlocked with a note asking you to put your valuables inside, lock the box and send it to the address on the box. The box is delivered to the thief who is the only one with the key that can unlock the box. Sure no one else could open it in transit back to the thief, but that is the least of your problems.

When you can’t verify the SSL certificate of a website up to a trusted ROOT CA, what that really means is that you have not verified the identity of who is truly behind that website. In my previous example, you don’t know if you are dealing with the legitimate BRASILIAEXPORTS.COM or some hacker site impersonating BRASILIAEXPORTS.COM. Since there are so many websites claiming to be legitimate Ecommerce sites on the Internet, you need an arbitrator that can vouch for the identities of these websites. The CA plays this role of arbitrator.

From the Ecommerce site’s perspective, what validates who you are as a customer is your credit card, as you need to know some of its essential parameters like number, expiration date, security code, billing address, etc. to place an order. These essential parameters should be known only to the credit card owner and by you providing them and the website verifying those parameters through a merchant system; your identity has been established.

 But how do you as the consumer know that you are providing this information to a trusted site? PKI uses the CA to act as this point of trust performing a role very similar to the US Passport system.

To get issued a US passport, you have to march down to the local passport office and prove your identity and citizenship to the U.S. Government before your photo is laminated inside of a US passport. When you travel overseas, the foreign immigration officer doesn’t know you from Adam, but if your passport says you are Joe American, they trust that is who you are because the U.S. Government is vouching for your identity. Similarly, when an ecommerce site requests an SSL certificate from a commercial CA like Verisign or Thawte, they first have to prove their identity to the CA before the CA will issue them the certificate. If you trust the CA has done their job properly, then you will trust a website which bears a certificate issued by that CA. How does this circle of trust work? Let me explain in detail.

Normally, a Certification Authority like Verisign has implemented a hierarchy of CAs, where the CA at the top is called the ROOT and there are single, dual or more tiers of additional CAs that are subordinate to the ROOT. You can examine this hierarchy readily when you are visiting an ecommerce site.

Let’s look at WINDOWSITPRO.COM as an example- say I need to renew my subscription to the magazine and I am at the checkout page. Notice how the secure URL shows as green indicating a trusted certificate.

When I click on the lock icon I am presented with the following.

 The commercial CA, Entrust made it a precondition before issuing this certificate that the Penton Business Media Corporation first prove its identity as a valid legally operated company. This was done ‘offline’ by providing the contact information for corporate officers, a business phone number that could be verified through a third party, and by legal documentation filed with the state of incorporation. Once Entrust was satisfied they were receiving a request from THE Penton Business Media and not some imposter, Entrust created and digitally signed this certificate and issued it to Penton.

 If I click ‘View certificates’, I am presented with the following:

 Note how the certificate was issued to www.windowsitpro.com which needs to match the URL of the website and Penton Media must be verified as the owner of this domain name.

If I click on the ‘Details’ tab, I see the following:

 Now here is where things get interesting. The Issuer field shows that the CA is Entrust, but how does your computer know that this certificate was indeed issued by Entrust and was not itself forged? This is guaranteed by a process called Certificate Chain Verification (CCV) which to understand requires us to examine the ‘Certification Path’ tab.

Here we can see the hierarchy of CAs that Entrust has implemented. The one at the top is considered the ROOT even though the one immediately below states it is ROOT. Regardless of the naming, the key thing to remember here is that this is a ‘family’ of CAs, with the top one the Grandfather, the next CA below it the Father, and the one below that the Son. There could be further ‘generations’ but the deeper the hierarchy, the more complex it is to administer.

Each of the CAs has its own Public-Private Key Pair, with the Public Key embedded inside of a Certificate that was issued by the Parent bearing the Parent’s signature. In this example, the website’s   www.windowsitpro.com certificate was issued and signed by CA Entrust Certification Authority-L1E, whose certificate was in turn issued and signed by its parent, CA Entrust Root Certification Authority, whose certificate was issued and signed by its parent, CA Entrust.

To verify that the website’s certificate is valid, your computer needs to verify that signature (made by the CA that issued it) as well as the signature of each of the CA certificates. This bottom to top signature checking process of CCV will be explained in greater detail in Part 3 of this series as it is fairly complex. For now, it is important that you know that CCV will fail if the ROOT CA’s certificate is not preinstalled on the client computer that is performing the verification, resulting in the ‘Could not verify up to a trusted root CA’ error message encountered earlier. In other words, the ROOT CAs that are acting as points of trust for PKI have to be ‘pre-trusted’ by adding their certificates to each client computers ‘Trusted ROOT CA’ list. Microsoft preinstalls a number of the commercial CAs in this list but you can add additional ROOT CAs as you see fit, as long as you trust them.

Trusted ROOT CAs can be seen by navigating in Internet Explorer to Internet Options | Content | Certificates and examining the Trusted Root Certification Authorities tab.

In summary, because no direct trust exists between a data originator and a data recipient, PKI relies on a third party point of trust system where the CA plays the role of trust arbitrator. The CA first establishes the identity of a Public-Private Key owner beyond doubt, then vouches for the owner’s identity by embedding the owner’s Public Key inside of a certificate bearing the CA’s signature. Anyone that trusts this CA can verify the CA’s signature and thereby the identity of the certificate owner.