Digital certificates verify a sender’s identity. They are issued to a subject (also called an entity). The certificates are issued by a Certificate Authority (CA). The certificate includes a public key for encryption. The Certificate Authority runs a certificate server. The server contains all public key issued by the CA. The server dispenses the certificates, which are themselves digitally signed by the CA’s private key.In addition to the certificates that are granted and are valid, the CA maintains a certificate revocation list. It is, as the name implies, a list of revoked certificates. Clients access this list to determine whether a certificate is still valid.
The Crypto API uses certificates as defined in X509. The Crypto API implements a certificate store as a linked list. The list can be in memory, on disk, or in the registry. The store is further broken down into logical and physical stores. The logical stores aggregates multiple physical stores, making them look like one big store.
There is also a system certificate store. The system certificate store is a collection of physical stores. In the Crypto API, there are predefined store names such as MY, Root, Trust, and CA. The Crypto API maintains a certificate trust list. It lists the entities that are trusted. An authority certifies other authorities in a hierarchical fashion.
Microsoft’s Crypto API covers a lot of territory. Certificates are just a small part of the supported functionality. In the future I plan to continue discussion on this beast of a topic. I might also write more about X.509, which is a standard for topics related to certificates.
