Over a period of time, certificates will accumulate on a user's computer. Tools are required to manage these certificates. CryptoAPI provides those tools as API functions to store, retrieve, delete, list (enumerate), and verify certificates. CryptoAPI also provides the means to attach certificates to messages.

This section discusses using CryptoAPI functions to manage certificates. Two main categories of functions are available: functions that manage certificate stores, and those that work with the certificates within those stores. The functions that manage certificate stores include functions for working with logical or virtual stores, remote stores, external stores, and relocatable stores.

Certificates can be kept and maintained in certificate stores. They can be retrieved from a store where they have been persisted for use in authentication processes. Throughout this section, references to certificates, unless otherwise noted, include certificates.

The certificate store is central to all certificate functionality. The certificates are managed in the store using functions with a Cert prefix. The following illustration shows a typical certificate store as a linked list of certificates.

This illustration shows:

• Each certificate store has a pointer to the first certificate block in that store.
  
  
• A certificate block includes a pointer to that certificate's data and a next pointer to the next certificate block in the store.
  
  
• The next pointer in the last certificate block is set to NULL.
  
  
• The data block of a certificate contains the read-only certificate context and any extended properties of the certificate.
  
  
• The data block of each certificate contains a reference count that keeps track of the number of pointers to the certificate that exist.
  
  

Certificates in a certificate store are normally kept in some kind of permanent storage such as a disk file or the system registry. Certificate stores can also be created and opened strictly in memory. A memory store provides temporary certificate storage for working with certificates that do not need to be kept.

Additional store locations allow stores to be kept and searched in various parts of a local computer's registry or, with proper permissions set, in the registry on a remote computer.

Each user has a personal MY store where that user's certificates are stored. The MY store can be at any one of many physical locations, including the registry on a local or remote computer, a disk file, a data base, directory service, a smart card, or another location. While any certificate can be stored in the MY store, this store should be reserved for a user's personal certificates, those certificates used for signing and decrypting that user's messages.

Using certificates for authentication depends on having certificates issued by some trusted certificate issuer. Certificates for trusted certificate issuers are typically kept in the ROOT store, which is currently persisted to a registry sub-key. In the CryptoAPI context, the ROOT store is protected and special user interface (UI) dialogues remind the user to place only trusted certificates into that store. In enterprise network situations, certificates might be pushed (copied) by a system administrator from the domain controller computer to the ROOT stores on client computers. This process provides all members of a domain with similar trust lists.

Other certificates can be stored in the CA system store or to user-created, file-based stores.

See Also