To use certificates for security, the authenticity and validity of each certificate received must be verified. This verification depends upon the concept of trust and the delegation of trust (see Hierarchy of Trust).

Every certificate has a subject, that is, the individual or group that is identified by that certificate. Each certificate also lists an issuer. The issuer of a certificate is its certification authority (CA), the individual or group empowered to issue certificates that certify the identity of the certificate's subject.

The issuer of a certificate must also be the subject of a certificate. That certificate, issued by still another CA, verifies the issuer's identity and authority to issue certificates. Furthermore, the CA that issues a certificate to the CA that issues the end certificate must also be certified. Thus, each valid certificate received is backed by a chain of certificates that leads to a universally acknowledged, trusted CA. This most trusted CA issues not only certificates for others, but also issues a certificate for itself.

The process of verifying the authenticity and validity of a newly received certificate involves checking all of the certificates in the chain of certificates from the original, universally trusted CA, through any intermediate CAs, down to the certificate just received which is called the end certificate. A new certificate can only be trusted if each certificate in that certificate's chain is properly issued and valid.

Tracking all of the certificates that back a new end certificate can become cumbersome. Therefore, CryptoAPI 2.0 technology provides functions that automate creating the chain of certificates that back any given end certificate. These functions also check and report on the validity of each certificate in a chain.

The chain-building and checking functions of CryptoAPI 2.0 use a chain engine to create and verify chains of certificates. A chain engine defines a store namespace and cache partitioning for the Certificate Chaining Infrastructure. CryptoAPI 2.0 provides a default chain engine for any application process that only uses default system stores — for example, MY, Root, CA, and Trust — for chain building and caching. An application can define its own store namespace or have its own partitioned cache by creating its own chain engine. To achieve optimal caching behavior, it is advisable to create a single chain engine at application startup and use that chain engine throughout the lifetime of the application.

See Also