Root and Identity Certificates
A digital certificate can be thought of as an electronic document that identifies a device or person. It includes information such as the name of a person or organization, their address, and the public key of that person or device. There are different types of certificates, including root certificates (which identify the CA), and identity certificates, which identify devices such as servers and other devices that want to participate in PKI.
Root Certificate
A root certificate contains the public key of the CA server and the other details about the CA server. Figure 5-2 shows an example of one.
The output in Figure 5-2 can be seen on most browsers, although the location might differ a bit depending on your browser vendor and version.
I recommend knowing the relevant parts of the certificate, including the following:
Serial number: Issued and tracked by the CA that issued the certificate.
Issuer: The CA that issued this certificate. (Even root certificates need to have their certificates issued from someone, perhaps even themselves.)
Validity dates: The time window during which the certificate may be considered valid. If a local computer believes the date to be off by a few years, that same PC may consider the certificate invalid due to its own error about the time. Using Network Time Protocol (NTP) is a good idea to avoid this problem.
Subject of the certificate: This includes the organizational unit (OU), organization (O), country (C), and other details commonly found in an X.500 structured directory (more on that later in the chapter). The subject of the root certificate is the CA itself. The subject for a client’s identity certificate is the client.
Public key: The contents of the public key and the length of the key are often both shown. After all, the public key is public.
Thumbprint algorithm and thumbprint: This is the hash for the certificate. On a new root certificate, you could use a phone to call and ask for the hash value and compare it to the hash value you see on the certificate. If it matches, you have just performed out-of-band (using the telephone) verification of the digital certificate.
Identity Certificate
An identity certificate is similar to a root certificate, but it describes the client and contains the public key of an individual host (the client). An example of a client is a web server that wants to support Secure Sockets Layer (SSL) or a router that wants to use digital signatures for authentication of a VPN tunnel. Figure 5-3 shows an example of an identity certificate.
Using the Digital Certificates to Get the Peer’s Public Key
In its basic components, any device that wants to verify a digital signature must have the public key of the sender. So, let’s use an example of you and me. If we want to authenticate each other, and we both trust a common CA and have previously requested and received digital certificates (identity certificates) from the CA server, we exchange our identity certificates, which contain our public keys. We both verify the CA’s signature on the digital certificate we just received from each other using the public key of the CA. In practice, this public key for the CA is built in to most of our browsers today for public CA servers. Once we verify each other’s certificates, we can then trust the contents of those certificates (and most important, the public key). Now that you and I both have each other’s public key, we can use those public keys to verify each other’s digital signatures.
X.500 and X.509v3 Certificates
X.500 is a series of standards focused on directory services and how those directories are organized. Many popular network operating systems have been based on X.500, including Microsoft Active Directory. This X.500 structure is the foundation from which you see common directory elements such as CN=Bob (Common Name = CN), OU=engineering (organizational unit = OU), O=cisco.com (organization = O), and so on in an “org-chart” way, shaped like a pyramid. X.509 Version 3 is a standard for digital certificates that is widely accepted and incorporates many of the same directory and naming standards. A common protocol that is used to do lookups from a directory is called Lightweight Directory Access Protocol (LDAP). A common use for this is having a digital certificate being used for authentication, and then based on the details of that certificate (for example, the OU=sales in the certificate itself), the user could be dynamically assigned the access rights that are associated with that group in Active Directory or some other LDAP accessible database. The concept is to define the rights in one place and then leverage that over and over again. An example is setting up Active Directory for the network and then using that to control what access is provided to each user after he or she authenticates.
As a review, most digital certificates contain the following information:
Serial number: Assigned by the CA and used to uniquely identify the certificate
Subject: The person or entity that is being identified
Signature algorithm: The specific algorithm that was used for signing the digital certificate
Signature: The digital signature from the certificate authority, which is used by devices that want to verify the authenticity of the certificate issued by that CA
Issuer: The entity or CA that created and issued the digital certificate
Valid from: The date the certificate became valid
Valid to: The expiration date of the certificate
Key usage: The functions for which the public key in the certificate may be used
Public key: The public portion of the public and private key pair generated by the host whose certificate is being looked at
Thumbprint algorithm: The hash algorithm used for data integrity
Certificate revocation list location: The URL that can be checked to see whether the serial number of any certificates issued by the CA have been revoked