Description of Digital Certificates

ID: Q195724

The information in this article applies to:

SUMMARY

This article contains a description of digital certificates.


MORE INFORMATION

General Information

The main purpose of the digital certificate is to ensure that the public key contained in the certificate belongs to the entity to which the certificate was issued.

Encryption techniques using public and private keys require a public-key infrastructure (PKI) to support the distribution and identification of public keys. Digital certificates package public keys, information about the algorithms used, owner or subject data, the digital signature of a Certificate Authority that has verified the subject data, and a date range during which the certificate can be considered valid.

Without certificates, it would be possible to create a new key pair and distribute the public key, claiming that it is the public key for almost anyone. You could send data encrypted with the private key and the public key would be used to decrypt the data, but there would be no assurance that the data was originated by anyone in particular. All the receiver would know is that a valid key pair was used.

Certificate Authorities

Certificates are signed by the Certificate Authority (CA) that issues them. In essence, a CA is a commonly trusted third party that is relied upon to verify the matching of public keys to identity, e-mail name, or other such information.

The benefits of certificates and CAs occur when two entities both trust the same CA. This allows them to learn each other's public key by exchanging certificates signed by that CA. Once they know each other's public key, they can use them to encrypt data and send it to one another, or to verify the signatures on documents.

A certificate shows that a public key stored in the certificate belongs to the subject of that certificate. A CA is responsible for verifying the identity of a requesting entity before issuing a certificate. The CA then signs the certificate using its private key, which is used to verify the certificate. A CA's public keys are distributed in software packages such as Web browsers and operating systems, or they can also be added manually by the user.

Software that is designed to take advantage of the PKI maintains a list of CAs that it trusts.

To view the list of CAs that Internet Explorer trusts, use the appropriate method:

Internet Explorer 3.x

On the View menu, click Options, click the Security tab, and then click Publishers.

Internet Explorer 4.x

On the View menu, click Internet Options, click the Content tab, and then click Publishers.

Internet Explorer 5

On the Tools menu, click Internet Options, click the Content tab, and then click Certificates.

A list of CAs that are included in Microsoft products is available at the following Microsoft Web site:

http://www.microsoft.com/security

Certificate Types

There are four kinds of digital certificates used on the Internet:

Personal Certificates:

These certificates identify individuals. They may be used to authenticate users with a server, or to enable secure e-mail using S-Mime. Microsoft recommends exporting your personal certificates to a safe location as a form of backup in case your certificates are damaged. If a password list file (.pwl) becomes damaged or missing, the certificate is not available for use, and you may receive an error message when you try to send e-mail. For more information about this issue see the following articles in the Microsoft Knowledge Base:
Q190296 Unable to Use Personal Certificates in Outlook Express
Q132807 Enhanced Encryption for Windows 95 Password Cache

Server Certificates:

Server certificates identify servers that participate in secure communications with other computers using communication protocols such as SSL. These certificates allow a server to verify its identity to clients. Server certificates follow the X.509 certificate format that is defined by the Public-Key Cryptography Standards (PKCS).

Software Publisher Certificates:

Microsoft Authenticode does not guarantee that signed code is safe to run, but rather informs the user whether or not the publisher is participating in the infrastructure of trusted publishers and CAs. These certificates are used to sign software to be distributed over the Internet.

Authenticode requires a software publisher certificate to sign Microsoft ActiveX and other compiled code. Internet Explorer is also capable of trusting software that is signed with a publisher's certificate.

To view a list of trusted software publishers in Internet Explorer, click Internet Options on the Tools menu, click the Content tab, and then click Publishers. You can also remove trusted publishers by clicking Remove in this screen.

Certificate Authority Certificates:

Internet Explorer 5 divides CAs into two categories, Root Certification Authorities and Intermediate Certification Authorities. Root certificates are self-signed, meaning that the subject of the certificate is also the signer of the certificate. Root Certification Authorities have the ability to assign certificates for Intermediate Certification Authorities. An Intermediate Certification Authority has the ability to issue server certificates, personal certificates, publisher certificates, or certificates for other Intermediate Certification Authorities.

For example, if you click Certificates on the Content tab in the Internet Explorer Properties dialog box, a list of certificates that are installed on your computer is displayed. There is a trusted Root Authority listed as "Class 1 Public Primary Certification Authority" (which is run by VeriSign). This certificate is issued and signed by the Class 1 Public Primary Certificate Authority, and is therefore a root certificate. On the Intermediate Certification Authorities tab, there are several certificates listed as "VeriSign Class 1 CA." The root certificate mentioned above issued these certificates. These Intermediate Certificate Authorities were created for the purpose of issuing and validating personal digital certificates, so if a person has obtained a Class 1 personal digital certificate from VeriSign, it will be issued by one of these Intermediate CAs. This creates what is known as a verification chain. In this case, there are only three certificates in the verification chain for a personal certificate. However, verification chains can contain a large number of certificates depending upon the number of Intermediate Certification Authorities in the chain.

The verification chain for a certificate can be viewed by double-clicking the certificate and then clicking the Certification Path tab.

How a Certificate Is Issued

  1. Key Generation: The individual requesting certification (the applicant, not the CA) generates key pairs of public and private keys.


  2. Matching of Policy Information: The applicant packages the additional information necessary for the CA to issue the certificate (such as proof of identity, tax ID number, e-mail address, and so on). The precise definition of this information is up to the CA.


  3. Sending of Public Keys and Information: The applicant sends the public keys and information (often encrypted using the CA's public key) to the CA.


  4. Verification of Information: The CA applies whatever policy rules it requires in order to verify that the applicant should receive a certificate.


  5. Certificate Creation: The CA creates a digital document with the appropriate information (public keys, expiration date, and other data) and signs it using the CA's private key.


  6. Sending/Posting of Certificate: The CA may send the certificate to the applicant, or post it publicly as appropriate.


  7. The certificate is loaded onto an individual's computer.


Certificate Revocation

CAs publish certificate revocation lists (CRLs) containing certificates that have been revoked by the CA. The certificate holder's private key may have been compromised, or false information may have been used to apply for the certificate. CRLs provide a way of withdrawing a certificate after it has been issued. CRLs are made available for downloading or online viewing by client programs.

To verify a certificate, all that is necessary is the public key of the CA and a check against the CRL published by that CA. Certificates and CAs reduce the public-key distribution problem of verifying and trusting one (or more) public keys per individual. Instead, only the CA's public key must be trusted and verified, and then that can be relied on to allow verification of other certificates. Internet Explorer 5 can be set to check for the validity of certificates on the Advanced tab in the Internet Explorer Properties dialog box.

Additional query words: 


Keywords          : msiew95 msient msiew98 
Version           : WINDOWS:3.0,3.01,3.02,4.0,4.01,4.01 Service Pack 1,5
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: August 8, 1999