|Web Server Management: Securing Access to Web Servers|
|Prev||Chapter 2. A crash course in cryptography||Next|
A careful reader will have noticed a "chicken and egg" problem with Public Key Certificates: to verify the trusted third party's digital signature we will need their public key. We could get this from a further certificate (indeed TLS has support for such "certificate chains"), but that is just putting off the moment of truth.
TLS, at least as applied to webserver access, takes a pragmatic approach to this problem. A number of organisations around the world have set themselves up as Certification Authorities (CAs) and they issue signed certificates on a commercial basis. To make this all work they have arranged for their own certificates to be distributed along with the common web browsers, and for the browsers to be configured to implicitly trust these certificates. When you install Internet Explorer, or Firefox, or Safari, you also install several tens of such "Root Certificates" and choose (whether you realise it or not) to implicitly trust the associated CAs. For example see "Edit -> Preferences -> Advanced -> Encryption View Certificates -> Authorities" in Firefox 2.
This is fairly worrying, though the widespread distribution and use of these certificates means that any blatent misuse is likely to be noticed. However it is the case that the keys coresponding to the certificates distributed with the major browsers have as a result become extreemly valuable and change hands from time to time. There are now a number of CAs who do not necessiarally check as carefully as they might that the details in certificates that they issue are reliable. The "Extended Validation" scheme (see Section 5.3) now being promoted by some of the larger CAs is to some extent an attempt to address this.
A system for issuing and revoking certificates, distributing root certificates, etc., to make the widespread use of public key cryptography possible is sometimes called a "Public Key Infrastructure" (PKI).