This is a multivariate field that may consist of zero or more of the following uses: In some cases these basic key usages may not be enough to identify a very specific or important use of the public key.
To address this need, the X.509 standard provides an additional field called Extended Key Usage (EKU).
Another example of this is when you receive a digitally signed e-mail; the e-mail signature is only valid if the sender's e-mail matches the e-mail address listed on the certificate (under RFC822 Name).
The alternative is to present the AIA path using HTTP, a more common and Internet-friendly means of distribution.When using HTTP ensure that the web servers publishing the AIA path are highly available and scalable to handle requests from every client that may need to validate a certificate issued by the CA.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.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.When a CA issues a certificate the signing certificate's SKI is imprinted as the issued certificate's AKI prior to being signed thus asserting the relationship.To validate a certificate chain, the validating client must have access to every certificate up to and including the root CA.As a side benefit, certificates published to clients provide additional configuration options to include configuration of cross-signing certificates, OCSP server address, extended validation options, and purpose limitation through the certificates snap-in or through Group Policy.Since root CAs do not have an issuer their certificate will not have all of the information available used to validate other types of certificates (i.e. Because of this, to establish trust with a root CA it must be installed in the trusted root certification authorities container (Root CA).Certificate validation is implemented differently based on the application validating the certificate, the type of identity being validated (i.e.