Where we last left off, we had made clear the purpose of digital certificates – to send others a public key, with identity information attached, with that identity information verified by a certificate authority (CA). The entire system is known as a Public Key Infrastructure, or PKI. The most widely used PKI is the X.509 system, specified by the ITU-T. X.509 specifies a file format that is used for digital certificates. Inside a digital certificate file are a number of fields including the “distinguished name”, an alternate name (often an email address), a serial number, a validity date, an expiration date, information about the encryption algorithms used to generate the keys, and other information. The digital certificate file also contains your public key, typically generated using the RSA or DSA algorithm. The certificate authority generates this entire file, then digitally signs the file using a private key.
The CA’s private key has a corresponding public key. Any user in the PKI must have the CA’s public key ahead of time in order to validate a digital certificate generated by that CA. How do we get that public key? Easy: another digital certificate, which contains the CA’s public key and is also signed by the CA. This type of certificate is known as a self-signed certificate, because it is signed with the same public key that is contained within the certificate. Users in a PKI must choose to trust a CA’s self-signed certificate before it can be used to validate other certificates generated by the CA. In some cases, network administrators will take care of establishing trust for a particular CA. In the case of large public Internet CAs such as VeriSign or Thawte, operating system manufacturers and software developers have taken care of this for us. Microsoft Windows users can view the installed CA certificates, for example, by opening Internet Explorer and navigating to Tools->Internet Options->Content->Certificates. Microsoft’s term for these CAs is “Trusted Root Certification Authorities”.
If you double-click one of these CAs, you can view the certificate details. Because these are self-signed root certificate authorities, you will see that the certificate “Issued to” and “Issued by” fields are the same.
If you further navigate to “Certification Path”, you can view the certificate issuance chain. A root CA certificate will contain one and only one entry, because it is self-signed.
Compare this to an Intermediate Certification Authority. An Intermediate CA is a CA server that can issue trusted digital certificates, but only on the authority of a higher level CA server. If the root CA certificate is revoked or expires, the intermediate CA is also no longer trusted. Below, we see the certification path for an intermediate CA. Note that we must already have a certificate for “Equifax Secure eBusiness CA-1” in our certificate store in order to trust this intermediate CA.
We’ve covered certificate authorities and PKI – next time we’ll look at how an end user gets a certificate – this is the process of requesting and issuing certificates.