Windows validating certificate
In general, three main areas of a certificate are checked during validation: In many cases, certificates are designed to provide identification of the computer or person holding the corresponding private key.
For example, when a user provides their Windows Live credentials to log on to a website the computer will validate that the certificate being used by the web server is authorized for the URL the user is accessing.
Key usage can be specified in either the "Key Usage" or "Extended Key Usage" attribute based on the validation requirements of the application.
The "Key Usage" field offers generic purpose validation based on the way an asymmetric key pair may be used as part of a PKI.
Certificate validation is implemented differently based on the application validating the certificate, the type of identity being validated (i.e.
validating a certificate from a web server will differ from validating a signed e-mail), and configuration of the Windows computer performing the validation.
By default, an Active Directory Certificate Services (ADCS) enterprise CA will publish its certificate to the Active Directory configuration partition which is automatically replicated to all domain controllers in the forest.
This provides site awareness and resiliency, however this path is best suited for internal use only since its path is likely inaccessible to external clients and can reveal information about your forest.
As mentioned in my previous blog entry on the X.509 certificate, this is a throw back to the roots and original intent for PKI: directory services.Later, when version 3 of the X.509 standard was passed, the "Subject Alternative Name" (sometimes referred to as a "SAN" field) was added allowing the issuer additional flexibility in specifying the identity of the authenticating entity.Out-of-the-box this provided options to identify the certificate owner in any of the following ways (ref: For a certificate to be considered valid the last CA in the chain must be installed in this container.Like the Sub CA store, the Root CA store can be populated locally, through Group Policy, or through Active Directory configuration.