Validating a Certificate


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.  In general, three main areas of a certificate are checked during validation:

  • Does one of the asserted identification attributes match the identity of the principal supplying the certificate?
  • Is the certificate being used in an authorized capacity?
  • Does the certificate chain to a certificate listed in the "Trusted Root Certification Authorities" certificate store?
  • Is the certificate revoked?

Validating the Identity of the Certificate Owner

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.  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).

In the initial two versions of the X.509 standard the only way to assert an identity was to use the "Subject" field of the certificate.  This field contains the X.500 address (also referred to as the LDAP distinguished name) of the object whose identity is being asserted.  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: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=%2Fcom.ibm.help.domino.admin.doc%2FDOC%2FH_KEY_USAGE_EXTENSIONS_FOR_INTERNET_CERTIFICATES_1521_OVER.html):

  • RFC 822 Name
    Another name for rfc822Name is the subject's e-mail address
  • DNS Name
    A DNS name meeting specifications outlined in RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt)
  • X.400 Address
    The X.400 standard governs message handling and look similar to the X.500 directory services standard, however addressing elements such as the country name, organization name, given name, surname, initials, etc.)
  • Directory Name
    This is the distinguished name of the subject
  • Electronic Data Identifier (EDI) Party Name
    The ediPartyName attribute allows the certificate to specify an alternative authority (referred to as a nameAssigner) that has assigned a name to the subject.  An example of where this might be of use is in federation whereby another directory service is asserting the name of a certified entity.
  • Uniform Resource Identifier (URI)
    This field contains a uniform resource identifier, or URI, conforming to RFC 3986 (http://www.ietf.org/rfc/rfc3986.txt).  URIs usually look similar to a uniform resource locator (URL), however they are used to provide a hierarchical association of an attribute.  URIs are commonly used in XML to uniquely identify a schema and are commonly confused with URLs due to their similarity, however a URI does not need to be a reachable networked location.
  • IP Address
    IP address of the certified entity
  • Registered ID
    An object identifier (OID) that can be used to identify the certified entity
  • Other Name
    Yet another reference to extend the naming capability, use of this allows specification of anything available in the OTHER-NAME information object class

Certificate (Key) Usage Validation

In addition to validating the identity of the certificate holder an application may validate the purpose that the certificate is authorized for to ensure it is valid for its current use.  This validation is what prevents any non-CA certificate from acting as a certification authority and issuing certificates.  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.  This is a multivariate field that may consist of zero or more of the following uses:

  • DigitalSignature
    The public key may be used to verify digital signatures for integrity purposes
  • Non-Repudiation (later named contentCommitment)
    The public key may be used to verify digital signatures to prevent false denial of an action (i.e. to identify falsehood in a claim that an action did not occur).  The key difference between this use and the "Digital Signature" use is the validation of other signed elements (ex: time or other identifying elements that may not be listed in the certificate).  An example of this would be using S\MIME to digitally sign an e-mail
  • Key Encipherment
    The public key may be used to encrypt keys or other security information.  An example of this would be SSL session key negotiation where the public key on the certificate from a Web server is used to encrypt a symmetric key to be shared to establish a secure channel between a computer and the server (the symmetric key is encrypted with the public key which can then only be decrypted by the matching private key held by the server)
  • Data Encipherment
    The public key may be used to encrypt information that does not fall into the category of keys or security information.
  • Key Agreement
    The public key may be used to negotiate a key without encrypting the key itself.  An example of this would be if a series of keys were pre-populated and the application encrypted information to allow the distant end to choose which key to use.
  • Certificate Signing (keyCertSign)
    The public key may be used to validate certificate signatures (only valid on CA certificates)
  • CRLSigning
    The public key may be used to verify a CA’s signature on a certificate revocation list (CRL)
  • Encipher Only
    The public key may only be used to encrypt data to be sent to another system.  This key usage is only valid when the Key Agreement usage is set.
  • Decipher Only
    The public key may only be used to decrypt data sent from another system.  This key usage is only valid when the Key Agreement usage is set.

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).  Values for the EKU field are defined in a number of different RFCs.  Some examples of extended key usages include:

  • Smart card logon
  • OCSP signing certificates
  • E-mail digital signature
  • Certificate Revocation List (CRL) signing
  • Time stamping
  • Code signing
  • Transport Layer Security (TLS) clients or servers

Certificate Chaining and Trust Validation

Another important part of validating a certificate is ensuring that it chains to a trusted root CA.  As discussed in my post on the X.509 certificate, any version 3 certificate signed by a certification authority should have at least one entry under the "Authority Information Access" pointing clients towards a location where they can obtain the certificate of the signing CA to validate the relationship.  This path should be available to all clients that may need to validate certificates issued by or chaining to the CA.  This concept is important to note when renewing the key pair on a CA since this is commonly done at around 50% of the CA's validity period meaning that certificates will need to access this path after key renewal occurs.  When a key pair is renewed on a CA the new certificate should not use the same path as the original certificate unless the private key for the CA and the authority key identifier (AKI) are not changed as part of the renewal.

Authority Key Identifier \ Subject Key Identifier Matching

Validity of a certificate chain is confirmed by retrieving the issuer's certificate (by default from the certificate's AIA path) and comparing the issuing certificate's subject key identifier (SKI) entry with the issued certificate's AKI entry.  As discussed in part 2 of this series, the SKI is populated with one of three values: the serial number of the certificate, a unique ID assigned by the signing CA, or any manner of identification listed as part of the GeneralName data type.  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.

Retrieving the Signing Certificate

To validate a certificate chain, the validating client must have access to every certificate up to and including the root CA.  By default, the client will try to use the certificate's AIA path unless the issuer's certificate is published to the client's intermediate certification authorities (SubCA) store.  Windows and Active Directory provide a number of ways to publish these certificates which will be discussed below.

The Authority Information Access Field

Once a certificate is issued the AIA path cannot be changed without reissue, therefore the location used to publish these certificates must be thoroughly thought out.  The AIA field allows for either HTTP or LDAP paths to provide flexibility in publishing locations.  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.

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.

 

Some important considerations when deciding on the number and location of AIA paths include:

  • Ensure the path is accessible to all clients in all reasonable situations
    Lack of a signing certificate will break the validating client's ability to chain to a trusted root CA and therefore will likely result in failed validation
  • Be cautious about exposing internal configurations
    Although LDAP is a great option for providing availability and distribution, understand that listing an Active Directory path as the AIA path for a certificate will result in that path being hard-coded into every certificate signed by a CA
  • Order AIA paths based on accessibility to validating clients
    Clients will try AIA paths in order, therefore it is ideal to list these paths in the order that provides the fastest access to clients

The Intermediate Certification Authorities Store

To reduce the number of connections to an AIA publishing point and increase resiliency of certificate validation it is sometimes ideal to install CA certificates to the Intermediate Certification Authorities (SubCA) store of validating clients.  Use of the SubCA store ensures that certificate validation continues without error when the AIA path written to the certificate becomes inaccessible.  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.

The Trusted Root Certification Authorities Store

 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. issuer, AKI, CDP, AIA).  Because of this, to establish trust with a root CA it must be installed in the trusted root certification authorities container (RootCA).  For a certificate to be considered valid the last CA in the chain must be installed in this container.  Like the SubCA store, the RootCA store can be populated locally, through Group Policy, or through Active Directory configuration.

Checking for Certificate Revocation

Issues with revocation checking services is probably one of the most common causes of PKI failure.  Since PKI is a security service many authentication applications will treat a lack of valid revocation information the same as if the certificate were revoked.  Since certificates are commonly issued for multiple years, the risk of compromise is significantly higher than a Kerberos ticket (5 minutes) or even a ticket granting ticket (10 hours).  As such, it is important to provide reliable revocation services for these credentials.  Since these revocation methods were covered thoroughly in a previous blog entry, this post will focus solely on client interactions with respect to revocation checking.

A few things to consider when designing revocation services:

  • A client will accept the first valid response from a revocation provider
    It is ideal to order revocation providers based on locality and service performance.  Also, an expired Certificate Revocation List (CRL) counts as a valid response and commonly results in the certificate being treated as revoked.
  • OCSP is significantly faster and more efficient than CRL checking
    Whenever possible, leverage OCSP services rather than CRL for PKI deployments of scale.
  • Provide a valid CRL publishing location even if you are running Windows Vista+
    Not every application supports OCSP and the revocation check is not always performed by Windows (i.e Java applications).  Also, Windows XP and prior operating systems do not support OCSP.  Because of this, it is important to provide a CRL download point to support these situations.

Online Certificate Status Protocol (OCSP)

Since Windows Vista and Certificate API: Next Generation (CAPI-NG), Online Certificate Status Protocol (OCSP) has been the preferred method to determine the revocation status when available.  In addition to supporting OCSP addresses listed in the certificate's AIA, Windows Vista and later also provide the ability to specify alternate OCSP servers through Group Policy or the certificates MMC snap-in.  When configured, these addresses are attempted in order prior to trying any addresses listed in the certificate and can be use to provide locality-based services and additional redundancy.  On the same tab with the OCSP responders is the option to disable CRL checking altogether; this is not recommended as it may result in denial of service should OCSP services be unavailable.  If OCSP addresses are not configured, Windows will try the OCSP address listed in the certificate's AIA field if one exists.

Certificate Revocation Lists (CRL)

In the event that OCSP services are not available, if a non-OCSP aware software package is validating revocation status, or Windows XP or prior is in use, revocation  the operating system will begin trying paths listed in the CDP field of the certificate in the order provided from top to bottom.  The order of CRL distribution points is an important consideration when configuring a CA because clients may experience performance issues or denial of service due to inaccessible CDP paths.  In addition, be cautious when using internal addresses on publically available certificates as it may expose internal design information.

A major concern when using CRLs pertains to their potential size.  When large amounts of certificate revocations occur on a CA a CRL can grow very large if not partitioned and may result in clients experiencing timeouts when reading these large files.  Additionally, a larger CRL will take more resources to validate a certificate.  Please note the upcoming section on URL retrieval timeouts when considering the design of your revocation strategy.

Another important consideration when designing a CRL revocation check strategy is ensuring the freshness of the published CRL.  In some applications (such as smart card logon), inability to retrieve a valid CRL causes the certificate to be treated as if it were revoked.

Final Notes 

URL Retrieval Timeouts

An important note when considering AIA and CDP paths is the client's URL retrieval timeout limits.  In Windows XP (and I am assuming this hasn't changed) clients are allowed a 15 second period to download the certificate from an AIA path or a CRL from a CDP.  Within these 15 seconds, the first 10 seconds are allotted to the first path with every subsequent path being allowed 50% of the remaining time of its predecessor (ref: http://social.technet.microsoft.com/wiki/contents/articles/4954.windows-xp-certificate-status-and-revocation-checking.aspx#CRL_Retrieval_Timeout_Thresholds).  This means that if a client may take more than 10 seconds to download the content they will be unable to perform the revocation check on any path.

For internal clients with large CRLs or slow links this setting is manageable through registry modification:

  • URL Retrieval Timeout
    Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config 
    Type: REG_DWORD
    Name: ChainUrlRetrievalTimeoutMilliseconds
    Default: Not set, effective setting is 15000 (15 seconds)
    Range: 1 - 65535
    Purpose: Configures the total amount of time (in milliseconds) that a client will allot for retrieving a single certificate's AIA or CDP path
  • Aggregate URL Retrieval Timeout
    Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
    Type: REG_DWORD
    Name: ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds
    Default: Not set, effective setting is 20000 (20 seconds)
    Range: 1-65535
    Purpose: Defines the maximum amount of time allotted to all URL downloads of a type.
  • Maximum AIA URL Count
    Registry Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
    Type: REG_DWORD
    Name: MaxAIAUrlCountInCert
    Default: Not set, effective setting is 5
    Range: 1-65535
    Purpose: Defines the maximum number of AIA paths retrieved when validating a certificate chain

Custom CAPI Revocation Providers

This entry covers the way that Windows performs certificate validation, however some environments use custom revocation providers which may modify this behavior.  If this software is in use, please refer to their documentation for information on the certificate validation process.

Comments (0)

Skip to main content