How Certificate Authorities Work

Certificate Authorities (CA) are fairly straightforward server applications that basically take in certificate requests, reformat and sign them, and then make the resulting certificate available for retrieval by the requester. The function of a CA is actually a bit more involved than just that; otherwise it would be easy for people to set themselves up as their own CA. The biggest requirement that a CA needs to meet is one of trust. People and applications that receive a certificate issued by a particular CA need to be able to trust that the CA verified that the owner of the certificate is who he or she claims to be. They also need to trust that the CA is who it claims to be.

Certificate Authority Hierarchies

The identity of a CA is established by the CA making its own certificate available to the public. This certificate is the certificate that the CA uses for signing all the certificates that it issues. The CA can issue itself its own certificate, signing it with itself, or the CA can have its certificate issued and signed by another CA. This results in a hierarchy of CAs, most likely culminating in a single CA that is very widely known and trusted, as shown in Figure 15.1.

If the root of the CA hierarchy is a company such as Verisign (http://www.verisign.com), whose certificate is distributed preinstalled as a root certificate in most Web browsers today, then when someone receives a certificate issued by a lower-level CA, by tracing the hierarchy to Verisign, a chain of trust can be established. If a corporate security department wants to set up its own CA and issue a self-signed certificate as the corporate root certificate, all the employees can choose (or more likely be required) to accept the certificate as a root certificate. When certificates can be traced to an accepted root certificate, that certificate is automatically trusted.

If a CA revokes a certificate issued to another CA, then all the certificates issued by the second CA are now suspect. However, unless users and applications are diligent in checking against updated Certificate Revocation Lists (CRL) issued by the CAs in the hierarchy, the suspect certificates may go unnoticed.

Requesting and Issuing Certificates

You have already seen the process of requesting and being issued a certificate in Chapter 5, "Requesting and Receiving Certificates." In that chapter, you learned that the process is basically a matter of the client requesting the certificate, generating a public/private key pair, packaging the public key in a certificate request, and sending that request to a CA. The CA then makes the decision of whether to issue the certificate or to reject the request. After the CA has issued the certificate, the client retrieves the certificate from the CA, as shown in Figure 15.2.

What you didn't learn is how the CA makes the decision on whether to issue or reject a particular certificate request. Each certificate request passes through a series of rules and policies that sometimes can automatically decide to issue or reject the certificate. There are times, however, that a certificate request requires human intervention to make the decision.

Depending on the type of certificate that you are requesting, the CA has to perform various degrees of verification of your identity. These range from a simple validation that the email address you provide for inclusion in the certificate is a valid email address, to requiring that you appear in person at a notary public with various forms of identification. For corporations, the requirements are just as wide ranging.

With Microsoft's Certificate Server, you have the ability to define your own rules governing how and when certificates are issued. You even have the ability to build plug-ins in Visual Basic for extending the policy functionality (although this is not covered in this book). Building your own plug-in modules involves using the Certificate Services COM objects, two of which you used in Chapters 5 and 7.