Understanding digital-certificate infrastructure

In this tip, we take a look under the hood of the digital-certificate infrastructure and provide you with the knowledge you need to assess the adequacy of the technology.

As a security professional, you've undoubtedly encountered the use of digital certificates to provide assurance about the identity of a system or user. Have you ever taken a moment to understand how the underlying technology provides this assurance? In this tip, we take a look under the hood of the digital-certificate infrastructure and provide you with the knowledge you need to assess the adequacy of the technology.

Digital certificates are based upon the public key infrastructure's (PKI's) ability to facilitate communication among large groups of individuals previously unknown to each other. Servers or users seeking to obtain a digital certificate contact one of the well-known Certificate Authorities (CAs), such as VeriSign or Thawte. The CA then requires the applicant to prove his identity using a procedure that varies according to the level of trust assigned to the certificate.

Once the CA is satisfied that the user is authentic (and the appropriate fee has been paid!), the CA issues a digital certificate. This certificate is structured according to the X.509 standard and contains the name of the CA, the name of the certificate's owner, the certificate's effective and expiration dates, details of the algorithm used by the CA to sign the certificate and, most importantly, the subject's public key. The CA then signs the certificate using its private key and provides the signed certificate to the certificate subject.


  • For an overview of how organizations utilize certificates, see the tip It's a matter of trust: Digital certificates and e-signatures.
  • Read this Network Security Tip, Which key is which?.

For details on the digital signature process, see A lesson in digital signatures

The subject may then use the certificate to prove his identity before entering secure communications with another user or system. The subject merely sends the certificate to the other party who then uses the CA's public key to validate the signature made with the CA's private key. If this validation process is successful, the certificate recipient may be certain that the subject's public key contained within the certificate is authentic. The recipient may then use that public key to initiate a secure communications session with the certificate subject.

The recipient may be confident in the security of the process due to the nature of public key encryption. There is nothing secret about a subject's digital certificate, and it may be distributed freely. If an imposter attempted to use the certificate to impersonate the certificate's true subject, he wouldn't be able to participate in the communications session initiated with the subject's public key, because he wouldn't have access to the subject's private key.

Note that the subject's private key isn't used for authentication, but it is required to participate in the communication initiated with the public key contained within the subject's certificate. Therefore, anyone may initiate a communications session using the subject's certificate (and the subject's public key it contains) but only the subject may complete the communication because only the subject has access to his private key, which is necessary to decrypt the initiation message.

Let's look at the use of digital certificates step-by-step. In our example, we'll assume that Bob wishes to communicate with the XYZ Web server in a secure fashion. Here's how the process works:

  1. XYZ obtains a digital certificate from a CA. This certificate contains XYZ's public key and is signed by the CA using the CA's private key. (Note that this step is performed once by XYZ, not for each communications session. The resulting certificate may be used until it expires a year or two down the road.)
  2. Bob requests XYZ's digital certificate from XYZ.
  3. XYZ forwards its certificate to Bob.
  4. Bob uses the CA's public key (which is freely available) to verify the CA's signature on the certificate.
  5. After verifying the certificate, Bob extracts XYZ's public key from the certificate.
  6. Bob sends a message to XYZ containing a secret key to be used for the remainder of the communication. He encrypts this message using XYZ's public key.
  7. XYZ receives the message and decrypts it using XYZ's private key (which only XYZ possesses).
  8. XYZ extracts the secret key from the message and uses it for the remainder of the communications session.

Note that Bob and XYZ switched from asymmetric (public key) to symmetric (secret key) encryption once Bob was satisfied with XYZ's identity. This is due to the fact that symmetric encryption is much faster than asymmetric encryption.

That's a digital certificate in a nutshell. Now that you understand the technology underlying these certificates, you're better prepared to determine appropriate scenarios for their use!

About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.

This was last published in April 2004

Dig Deeper on PKI and digital certificates